cc-task-state

name	cc-task-state
description	任务状态沉淀与恢复工作流，适用于补记进展、记录未开始需求、标记被打断或阻塞、整理恢复入口与下一步场景；通过项目内 .codex/tasks/ 持久化任务状态。

CC Task State

当用户明确要求记录当前进展、补记需求、说明“还没开始/先记一下/被 fix 打断/稍后继续”、整理恢复入口，或需要把自然语言进展沉淀为项目任务状态时，使用本技能。

不要用于：

• 直接实现完整 feature
• 代替 bug 修复或 debug
• 只做配置状态诊断

核心方式

1. 先确认当前项目根目录的 .codex/tasks/ 与 .codex/tasks/archived/ 可用；目录缺失时优先初始化，不把“缺目录”直接当成“不可写”。
2. 即使目录已存在，也必须先确认当前会话对项目根目录的写入动作可执行；不能因为“看起来已有骨架”就跳过项目内写入检查。
3. 若项目内初始化或任务写入命中权限边界，优先走平台原生审批提示；只有项目目录在审批后仍确实不可写，才说明约束，并明确是否回退到 ~/.codex/tasks/ 继续持久化。
4. 识别用户消息中的任务主体；一段话里有多个任务时，必须拆成多条任务状态，而不是混写成一条。
5. 对每个任务判断状态：需求中、待开始、进行中、被打断、阻塞中、待恢复、已完成、已取消。
6. 若当前已有主线任务，再出现短期插入的 fix 或调查，优先在主线任务的“中断记录”中补 checkpoint；只有范围独立、可能跨多轮的插入任务才单独建任务文件。
7. 用户明确说“还没开始”“先别写代码”“等主线收尾再做”时，只能落为 需求中 或 待开始，不能误写成 进行中。
8. 更新任务文件时，至少补齐“当前结论”“未开始 / 被打断 / 阻塞原因”“恢复入口”“下一步”中的相关字段，避免只写一句状态。
9. 若任务已结束，更新状态后移动到 .codex/tasks/archived/；不要让已完成或已取消任务长期留在根目录。

协作约束

• 需要完整实现 feature 时，转交 new-feature
• 需要修 bug 或 debug 时，转交 fix
• 需要查看任务盘点或配置状态时，转交 cc-status
• 涉及接口新增、分页、筛选、详情或响应格式判断时，遵循 cc-api-contract-safety

输出要求

• 明确列出识别出的任务主体和对应状态
• 明确区分“当前主线”“候选任务”“插入任务”
• 若用户一句话包含多个任务，必须拆开说明，不合并成模糊总结
• 说明本次是“新建任务 / 更新任务 / 归档任务 / 只补 checkpoint”中的哪一种
• 若发生任务目录回退，必须明确说明是“目录缺失已初始化”“项目目录确实不可写”还是“当前会话受限导致写入被拦截”
• 若当前信息不足以判断状态，先说明缺口，不臆测已经开工

按需展开

• 状态模型：references/state-model.md
• 抽取规则：references/capture-rules.md