Embed badge
Show
Style
[](https://versuz.dev/skills/doccker-cc-use-exp-codex-skills-cc-new-feature)Free SKILL.md scraped from GitHub. Clone the repo or copy the file directly into your Claude Code skills directory.
npx versuz@latest install doccker-cc-use-exp-codex-skills-cc-new-featuregit clone https://github.com/doccker/cc-use-exp.gitcp cc-use-exp/SKILL.MD ~/.claude/skills/doccker-cc-use-exp-codex-skills-cc-new-feature/SKILL.md--- name: cc-new-feature description: 结构化新功能交付工作流，适用于显式 new feature、从需求到实现的一站式功能开发或恢复未完成任务场景；通过项目内 .codex/tasks/ 持久化状态。 --- # New Feature > **流程主权声明**：本技能是用户显式调用的完整工作流，拥有从需求到实现的全流程控制权。 > 禁止在本流程执行期间调用 `superpowers:brainstorming`、`superpowers:writing-plans` 或任何会接管设计/实现流程的外部 skill。 > 设计文档必须写入 `.codex/tasks/`，不得写入 `docs/superpowers/` 或其他路径。 > 本声明依据 superpowers 自身的优先级规则：用户显式指令 > superpowers skills。 当用户明确要求开发新功能、完整推进一个 feature，或提到 `new-feature`、恢复未完成任务时，使用本技能。 若用户当前只想补记需求、登记进展、标记“还没开始 / 被打断 / 稍后继续”，而不要求立即进入实现，优先使用 `cc-task-state`。 不要用于： - 小范围 bug 修复 - 纯需求文档或纯设计文档 - 只做一次性代码评审 ## 核心方式 1. 运行开始必须先在**当前项目根目录**确保 `.codex/tasks/` 与 `.codex/tasks/archived/` 存在；即使目录已存在，也必须先确认项目根目录写入动作可执行，不能因为“看起来已有骨架”就跳过创建/移动尝试；若目录缺失，必须先执行 `mkdir -p .codex/tasks/archived` 创建后再继续，不要把“目录不存在”直接判成“不可写”。 2. 再检查 `.codex/tasks/` 根目录，发现状态已是“已完成”的任务文件时，直接移动到 `.codex/tasks/archived/`。 3. 再检查 `.codex/tasks/` 是否已有未完成任务，检查时忽略 `archived/`；需要恢复时，优先续做而不是重复开题。 4. 验证当前会话对项目内 `.codex/tasks/` 具有写权限时，先基于已创建完成的目录判断；若 `mkdir -p .codex/tasks/archived` 命中权限边界，必须优先走平台审批提示。只有项目目录在目录已创建后仍确实不可写，才说明约束，并明确是否回退到 `~/.codex/tasks/` 继续持久化；禁止在未尝试项目根目录初始化前，直接以文本提示替代写入授权流程。 5. 在开工前先判断任务状态：若用户明确表示“还没开始”“先记一下”“等当前主线收尾再做”，则只创建或更新任务文件，并将状态标记为 `需求中` 或 `待开始`，不要误写为 `进行中`。 6. 确认准备进入实现时，再做 3-5 个关键澄清问题，补齐边界、异常和依赖。 7. 再产出实现范围、关键决策和步骤计划；方向明显不止一种时必须先确认。 8. 一旦确认进入实际实现，必须把当前主任务状态更新为 `进行中`；不要让显式开工的任务长期停留在 `待开始`。 9. 使用 `templates/task.md` 持久化任务状态；必须优先写入项目内 `.codex/tasks/`。若项目根目录下 `.codex/tasks/` 尚不存在，先尝试 `mkdir -p .codex/tasks/archived`；若该写入触发平台审批，则必须让用户授权后继续。只有项目目录在完成初始化后仍确认不可写，才允许回退到 `~/.codex/tasks/`。默认情况下，不把 `~/.codex/tasks/` 作为首选落点。 10. 按步骤实现，每完成一步就更新状态、已改文件和验证结果。 11. 完成后做一次 quick review 视角的自查，更新任务状态为“已完成”，再将任务文件移动到对应 `tasks/archived/`。 ## 协作约束 - 需要需求深挖时，套用 `requirement` 的方式 - 需要技术设计时，套用 `design` 的方式 - 若当前只需沉淀任务状态、恢复入口或中断点，套用 `cc-task-state` - 涉及接口新增或调整、前后端联调、列表页、分页或筛选页时，套用 `cc-api-contract-safety` 的方式 - 完成前自审时，套用 `cc-review` 的优先级 - 语言和框架细节交给对应语言 skills ## 输出要求 - 明确区分需求澄清、设计决定、实现步骤和验证结果 - 若当前信息不足以安全开工，先问关键问题 - 若用户当前没有要求开工，而只是登记或澄清需求，任务状态应保持在 `需求中` 或 `待开始` - 若已经确认进入实现，必须把主任务状态切换为 `进行中` - 任务文件始终与当前进度保持一致 - 若发生任务目录回退，必须明确说明“项目目录不可写”还是“仅缺目录且已自动创建”；禁止把“目录不存在”直接表述成“不可写” - 若项目根目录下 `.codex/tasks/` / `.codex/tasks/archived/` 尚不存在，优先在项目根目录执行初始化；若当前会话没有该目录写权限，应让平台审批先接管，而不是直接文本化地回退到用户级目录 - 若当前项目已存在 `.codex/tasks/` 但任务文件仍无法写入，必须先确认是否真正执行了项目根目录写入动作；即使已有骨架，也不能跳过创建/移动步骤 - 同一时刻只应有一个主任务处于 `进行中`；若有其他候选功能，应保持在 `需求中`、`待开始` 或 `待恢复` - 若存在接口或联调工作，任务文件需记录接口契约确认和临时兼容退出条件 - 完成后说明残余风险和后续建议 ## 按需展开 - 恢复策略：`references/resume-policy.md` - 编排方式：`references/orchestration.md` - 任务模板：`templates/task.md`