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`