doccker CC Task State
当用户明确要求记录当前进展、补记需求、说明“还没开始/先记一下/被 fix 打断/稍后继续”、整理恢复入口，或需要把自然语言进展沉淀为项目任务状态时，使用本技能。
不要用于：
- 直接实现完整 feature
- 代替 bug 修复或 debug
- 只做配置状态诊断
核心方式
- 先确认当前项目根目录的
.codex/tasks/与.codex/tasks/archived/可用；目录缺失时优先初始化，不把“缺目录”直接当成“不可写”。 - 即使目录已存在，也必须先确认当前会话对项目根目录的写入动作可执行；不能因为“看起来已有骨架”就跳过项目内写入检查。
- 若项目内初始化或任务写入命中权限边界，优先走平台原生审批提示；只有项目目录在审批后仍确实不可写，才说明约束，并明确是否回退到
~/.codex/tasks/继续持久化。 - 识别用户消息中的任务主体；一段话里有多个任务时，必须拆成多条任务状态，而不是混写成一条。
- 对每个任务判断状态：
需求中、待开始、进行中、被打断、阻塞中、待恢复、已完成、已取消。 - 若当前已有主线任务，再出现短期插入的 fix 或调查，优先在主线任务的“中断记录”中补 checkpoint；只有范围独立、可能跨多轮的插入任务才单独建任务文件。
- 用户明确说“还没开始”“先别写代码”“等主线收尾再做”时，只能落为
需求中或待开始，不能误写成进行中。 - 更新任务文件时，至少补齐“当前结论”“未开始 / 被打断 / 阻塞原因”“恢复入口”“下一步”中的相关字段，避免只写一句状态。
- 若任务已结束，更新状态后移动到
.codex/tasks/archived/；不要让已完成或已取消任务长期留在根目录。
协作约束
- 需要完整实现 feature 时，转交
new-feature - 需要修 bug 或 debug 时，转交
fix - 需要查看任务盘点或配置状态时，转交
cc-status - 涉及接口新增、分页、筛选、详情或响应格式判断时，遵循
cc-api-contract-safety
输出要求
- 明确列出识别出的任务主体和对应状态
- 明确区分“当前主线”“候选任务”“插入任务”
- 若用户一句话包含多个任务，必须拆开说明，不合并成模糊总结
- 说明本次是“新建任务 / 更新任务 / 归档任务 / 只补 checkpoint”中的哪一种
- 若发生任务目录回退，必须明确说明是“目录缺失已初始化”“项目目录确实不可写”还是“当前会话受限导致写入被拦截”
- 若当前信息不足以判断状态，先说明缺口，不臆测已经开工
按需展开
- 状态模型：
references/state-model.md - 抽取规则：
references/capture-rules.md