cc-task-state

CC Task State

Use this skill when the user explicitly asks to record current progress, backfill requirements, states "not started yet / just note it down / interrupted by a fix / continue later", organize recovery entry points, or needs to persist natural-language progress as project task state.

Do not use for:

• Directly implementing a complete feature
• Replacing bug fixes or debugging
• Doing only configuration state diagnostics

Core approach

1. First confirm that the current project root directory's .codex/tasks/ and .codex/tasks/archived/ are available; when the directory is missing, prefer initializing it, and do not treat "missing directory" directly as "not writable".
2. Even if the directory already exists, you must first confirm that the current session can execute write actions to the project root directory; do not skip the in-project write check just because "it looks like a skeleton already exists".
3. If in-project initialization or task writing hits a permission boundary, prefer the platform-native approval prompt; only when the project directory is still truly not writable after approval should you explain the constraint and clarify whether to fall back to ~/.codex/tasks/ to continue persisting.
4. Identify the task subjects in the user message; when there are multiple tasks in one passage, you must split them into multiple task states rather than mixing them into one.
5. Determine the state for each task:需求中、待开始、进行中、被打断、阻塞中、待恢复、已完成、已取消。
6. If there is already a mainline task and a short-term inserted fix or investigation appears, prefer adding a checkpoint under the mainline task's "interruption record"; only separately create a task file for inserted tasks whose scope is independent and may span multiple rounds.
7. When the user explicitly says "not started yet", "don't write code yet", or "wait until the mainline is wrapped up", it can only be recorded as 需求中 or 待开始, and must not be mistakenly written as 进行中。
8. When updating a task file, at minimum fill in the relevant fields among "current conclusion", "not started / interrupted / blocked reason", "recovery entry point", and "next steps", to avoid writing only a one-line status.
9. If the task has ended, after updating the state move it to .codex/tasks/archived/; do not let completed or canceled tasks remain in the root directory for a long time.

Collaboration constraints

• When a complete feature implementation is needed, hand it off to new-feature
• When a bug fix or debugging is needed, hand it off to fix
• When task inventory or configuration status needs to be checked, hand it off to cc-status
• When it involves interface additions, pagination, filtering, details, or response format decisions, follow cc-api-contract-safety

Output requirements

• Clearly list the identified task subjects and their corresponding states
• Clearly distinguish "current mainline", "candidate tasks", and "inserted tasks"
• If a single user sentence contains multiple tasks, you must explain them separately and not merge them into a vague summary
• Explain which of "create task / update task / archive task / only add checkpoint" this is
• If a task directory fallback occurs, you must clearly explain whether it is "directory was missing and has been initialized", "the project directory is truly not writable", or "the current session is restricted so writing was blocked"
• If the current information is insufficient to determine the state, first explain the gap and do not speculate that work has already started

Expand as needed

• State model:references/state-model.md
• Extraction rules:references/capture-rules.md