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`