cc-task-state

# 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`