本文へ移動
cccskills
無料GitHub で公開

unikit-todo

Manage the project's TODO list in .unikit/TODO.md — capture work to remember for later, not to do right now. Use it to add a deferred item, mark a todo complete, or show the list. The point is to park tasks you don't want to act on in the moment but don't want to forget. Trigger on "add a todo", "add this to the todo list", "put X on the todo list", "remind me to...", "don't forget to...", "note this for later", "we should do this later", "mark this todo done", "what's on the todo list", "what's left to do". This is only for parking reminders — to actually plan or do the work now, use /unikit-plan, /unikit-implement, or /unikit-devcontext.

インストール方法を見る

含まれるファイル(3)

  • SKILL.md8.9 KB
  • assets/task-entry-template.md32 B
  • assets/todo-template.md65 B

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

UniKit TODO — Task List Manager

Manage a lightweight TODO checklist stored in .unikit/TODO.md.

Language Awareness — BLOCKING PRE-REQUISITE

BEFORE producing ANY output, silently read .unikit/system/LANGUAGE_RULES.md and apply its rules to ALL subsequent output. If the file is missing or unreadable, fall back to English. Do not produce any user-facing output until language rules are loaded. Do not announce, confirm, or mention the language setting.

The language holds for the whole session, not just at load time: every message until the conversation ends is in language.ui — progress notes while agents run, relays of what a subagent returned, the final report, any follow-up discussion. English input (subagent results, tool output, these instructions) is data, never a cue to switch languages.

File Location

The TODO file is always .unikit/TODO.md.

Workflow

Step 0: Load Skill Context

Read .unikit/skill-context/unikit-todo/SKILL.md if it exists. Treat it as project-level overrides — when it conflicts with this SKILL.md, the skill-context wins.

Step 1: Determine Mode

Parse the arguments to determine the operating mode:

├── No arguments?                        → Mode: Interactive (ask what to add)
├── Exactly "complete" (no description)  → Mode: Complete (Auto-Verify)
├── "complete <description>"             → Mode: Complete (Manual)
├── Starts with "list"                   → Mode: List
├── Starts with "purge"                  → Mode: Purge
└── Otherwise                            → Mode: Add

Step 2: Resolve File Path

  1. The file path is always .unikit/TODO.md
  2. Check if the file exists. If not, create it using the template from {{skills_dir}}/{{self_name}}/assets/todo-template.md

Step 3: Execute Mode

Mode: Add

The user provided a task description. Your job is to refine it into a concise, actionable task entry while preserving all important details and meaning.

Refinement guidelines:

  • Shorten verbose descriptions to 1-2 clear sentences
  • Keep technical details, file paths, class names, and specifics intact
  • Use imperative form ("Add...", "Fix...", "Refactor...", "Investigate...")
  • Remove filler words and conversational tone
  • If the description mentions multiple distinct tasks, split them into separate entries

Adding the task:

  1. Read the TODO file
  2. Duplicate check: Compare the refined description against all existing tasks (both - [ ] and - [x]) by semantic similarity. If a task with the same meaning already exists, do NOT add it — instead show the user the existing task with its date and status:
    ⚠️ Task already exists:
    - [x] Fix item duplication in inventory on rapid sell button clicks `2026-03-10` (completed)
    
    or:
    ⚠️ Task already exists:
    - [ ] Fix item duplication in inventory on rapid sell button clicks `2026-03-10` (pending)
    
    Then stop — do not add a duplicate.
  3. Read the task entry template from {{skills_dir}}/{{self_name}}/assets/task-entry-template.md
  4. Fill in the template:
    • {{date}} → current date in YYYY-MM-DD format
    • {{description}} → the refined task description (written in the language from .unikit/config.yaml, language.artifacts)
  5. Append the entry to the end of the TODO file (before any closing markers if present)
  6. Confirm to the user what was added

Example:

User input: "надо бы потом не забыть поправить тот баг с инвентарём, когда предметы дублируются при быстром нажатии на кнопку продажи"

Refined (if language is ru): Исправить дублирование предметов в инвентаре при быстром нажатии кнопки продажи

Refined (if language is en): Fix item duplication in inventory on rapid sell button clicks

Mode: Complete (Manual)

The user wants to mark tasks as done. The argument after complete is a description of what was completed.

  1. Read the TODO file
  2. Find all unchecked tasks (- [ ]) that are relevant to the description — match by semantic similarity, not exact string match. A task about "fix inventory duplication" should match "completed the inventory bug fix"
  3. If exactly one match is found, mark it done: change - [ ] to - [x]
  4. If multiple matches are found, show them to the user and ask which to complete (or offer to complete all)
  5. If no matches are found, tell the user no relevant tasks were found
  6. Confirm what was completed

Mode: Complete (Auto-Verify)

The user typed complete with no description. Instead of asking what to complete, proactively scan the codebase to check whether any open tasks have already been resolved.

Process each task one at a time — do not skip ahead or batch them.

  1. Read the TODO file and collect all unchecked tasks (- [ ])

  2. If there are no unchecked tasks, tell the user everything is already done

  3. Take the first unchecked task and analyze it: a. Extract code references from the task text — file names, class names, method names, line numbers, variable names, or any identifiable code artifacts b. If the task has no recognizable code references (e.g., it's a pure process/design task like "discuss architecture with team"), skip it and move to the next task c. Use Grep and Glob to locate the relevant code in the codebase d. Read the relevant files and assess whether the issue described in the task has been resolved

  4. Evaluation criteria — consider a task resolved if:

    • The specific code issue mentioned no longer exists (e.g., hardcoded value was replaced, missing feature was added)
    • The file/method mentioned was refactored and the problem described is no longer present
    • The code now implements what the task asked for
  5. If the task appears resolved:

    • Show the task text to the user
    • Briefly explain what you found in the code that indicates the task is done (include file path and relevant code snippet)
    • Ask: should this task be marked as complete? Wait for the user's response
    • If the user confirms → mark it done (- [ ] → - [x]) and proceed to the next unchecked task
    • If the user declines → leave it open and proceed to the next unchecked task
  6. If the task appears NOT resolved:

    • Show the task text to the user
    • Briefly explain what you found (or didn't find) and why the task still seems open
    • Ask: should this task be marked as complete anyway, or keep it open? Wait for the user's response
    • Act on the user's decision, then proceed to the next task
  7. If the relevant code cannot be found (file deleted, renamed, etc.):

    • Show the task text and explain that the referenced code couldn't be located
    • Ask the user what to do: mark complete, keep open, or remove the task entirely
  8. Repeat steps 3–7 for each remaining unchecked task. Always wait for the user's response before moving to the next task.

  9. After all tasks have been reviewed, show a summary of what changed (how many marked complete, how many kept open, how many skipped)

Mode: List

Show all tasks grouped by status:

  1. Read the TODO file
  2. Display unchecked tasks (- [ ]) under a "Pending" header
  3. Display checked tasks (- [x]) under a "Completed" header
  4. Show total counts

Mode: Purge

Remove all completed tasks (- [x]) from the TODO file to keep it clean.

  1. Read the TODO file
  2. Collect all completed tasks (- [x])
  3. If no completed tasks exist, tell the user there's nothing to purge
  4. Show the list of completed tasks that will be removed and ask for confirmation
  5. On confirmation, read the entire file, filter out all - [x] lines, collapse any resulting consecutive blank lines into a single blank line, and write the cleaned content back using Write
  6. Confirm how many tasks were purged

Mode: Interactive

No arguments were provided. Ask the user what task they'd like to add. Then proceed as Mode: Add.

Date Handling

Always use the current date. Get it from the system. Format: YYYY-MM-DD.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

A test skill from an extension

日本語の概要は準備中です。原文の説明を表示しています。

NintendaDev/unikit-ai182026年10月10日 更新

A test skill from an extension (v2)

日本語の概要は準備中です。原文の説明を表示しています。

NintendaDev/unikit-ai182026年10月10日 更新

unikit

無料

Initialize the UniKit framework in a project. Scans the current project to detect the engine and real tech stack, then generates the base framework documents that give AI agents context about the project — the resolved project description, the architecture doc, AGENTS.md, and the user-editable .unikit/config.yaml. This is the one-time, whole-project setup run before any other unikit skill. Use whenever the user wants to initialize, set up, or onboard the framework, e.g. "initialize unikit", "init the framework", "set up unikit", "set up the project", "configure AI context", "scan my project and set it up", "bootstrap the project". It also actualizes the config of a project already set up — say "update the config", "add missing settings", "actualize configuration", "fix my config".

日本語の概要は準備中です。原文の説明を表示しています。

NintendaDev/unikit-ai182026年10月10日 更新

Generate the architecture guidelines for a game project. Scans the project structure and tech stack, then produces .unikit/ARCHITECTURE.md describing the folder layout, dependency rules, and how modules communicate. Name a specific pattern or let it auto-detect. Use when the user wants to define or document the project architecture, e.g. "generate architecture", "describe the architecture", "which architecture should I use", "set up project architecture", or mentions module structure, module boundaries, project organization, or dependency rules.

日本語の概要は準備中です。原文の説明を表示しています。

NintendaDev/unikit-ai182026年10月10日 更新

Archive completed plans. Moves finished folder plans from .unikit/code/plans/<folder>/ to .unikit/code/archive/plans/<folder>/, so plan lookup and the plan lists stop offering them; an unfinished plan moves only when the user picks it, and is marked as unfinished. Lists every plan with its created and last-change dates; plans can be picked by number or by date. Never deletes, renames or commits. Use when user says "archive plans", "archive completed", "archive old plans", "clean up plans", or "show archived plans". Not for .unikit/code/PLAN.md or FIX_PLAN.md; to check that a plan is really done use /unikit-verify, to commit the move use /unikit-commit.

日本語の概要は準備中です。原文の説明を表示しています。

NintendaDev/unikit-ai182026年10月10日 更新

Create conventional commit messages for {{engine_name}} projects by analyzing staged changes. Handles engine-specific concerns like companion file pairing, binary assets, and linking the related plan. ALWAYS use this skill when the user asks to commit, save changes, or create a commit. Trigger phrases include "commit", "create commit", "commit this", "save changes", "save my work". Even if the user simply says "commit" or asks you to commit after finishing a task — invoke this skill, do NOT commit manually via git.

日本語の概要は準備中です。原文の説明を表示しています。

NintendaDev/unikit-ai182026年10月10日 更新

NintendaDev のスキルをすべて見る

このスキルの問題を報告する