Claude 开发
概述
拥有 Claude Code 中任务全局的开发序列：实现请求的更改，运行其检查，然后在交付前（若请求）获取独立的 Codex 审查。适用于纯语言请求以及通过其他技能开始的工作。这是基于指令的编排；自动技能选择和完成并非宿主强制保证。
使用方式
使用 /claude-development <task> 或将其应用于授权的 Claude 开发请求，例如：
修复此 bug 并交付已验证的更改。 包含声明式配置更改，即使它们不需要 TDD。规划、解释和审查单独不能授权实现。
实现请求授权为达成请求结果所需的本地修正，包括在该范围内对已展现缺陷的有界 Codex 修正。保留更严格的用户限制。提交、推送、PR 发布、审批和合并保留其现有的授权要求。其他技能拥有各自的专业步骤；本技能定义开发何时结束。
步骤
- 确定任务和先决条件。 阅读仓库说明、当前 Git 状态、相关源码和 ADR。识别需求、允许的文件、现有更改和验证边界。仅用
requirements-clarification解决实质性的未知项。验证所需检查是否可用。若请求了独立 Codex 审查，请在该阶段前验证code-review-fix及其声明的运行时。保持自动停止审查门禁用；缺少可选审查工具不会阻止实现或常规交付。 - 尊重外层工作流。 对于 Linear 任务，让
linear-start和linear-workflow负责资格、分支、跟踪器和 PR 状态。其他专业工作流保留其自身的权威和边界。当此任务修复一个开放的 PR 时，使用授权的pr-fix工作流进行修复和独立审查；不要启动并行的本地修复循环。即使没有调用其他技能，普通的本地实现仍在此处。 - 实现已确定的结果。 保留无关的工作。对拥有的可执行行为应用
tdd，对声明式更改应用原生或现有的验证。使用相关的领域技能，但不要将每个测试、工具调用或子任务变成单独的交付阶段。记录完整的任务差异以及任何有意排除的更改。 - 运行相关检查。 在格式化、lint 和类型检查之前索引预期的新文件。运行适合实际更改的仓库障碍，包含命名的环境和限制。失败的检查是未完成的开发，不是削弱断言的许可。仅修复授权的失败，并保持缺失的必要证据明确。
- 运行一次请求的独立审查。 Codex 审查是可选的；仅实现请求不需要它。当用户请求审查和有界修正时，在完整的本地差异上激活
code-review-fix，包含需求、候选身份和原始检查证据。在授权的工作流运行时暂停 Claude 的写入。仅审查请求不授权任何修正，并使用code-review。不要在委托的修正内部重新启动任一序列。如果pr-fix拥有修复和审查，请保留其范围，而不是创建第二个循环。 - 交付观察到的结果。 报告最终的候选、更改的行为、发现的处理方式、实际的检查、环境以及剩余的限制。缺失、过时或不完整的请求审查仍然是一个明确的限制；未请求的审查不是交付的先决条件。不要仅仅因为代码已编写、检查通过、子任务返回或任务被标记为完成就认为开发已结束。保留外层工作流中任何现有的发布和审批检查点。
陷阱
- 普通的请求绕过专业技能 — 验证可能消失；此工作流适用于 Claude 开发，无论任务如何启动。
- TDD 成为外部工作流 — 一个通过的测试就过早结束交付；在实现和检查完成后验证整个任务并执行任何请求的审查。
- 每个子任务都会启动结束序列 — 审查会递归且通过计数器重置；只有外部的开发所有者调用最终阶段。
- 配置编辑跳过 TDD — 跳过值测试也可能错误地跳过审查；使用原生验证，并在请求时执行独立审查。
- 现有 PR 修复获得第二个循环 — 竞争的作者和结论会产生分歧；保留
pr-fix所有者及其最终的独立审查。
约束
- 从来不得从规划或仅审查请求开始实现、修复或发布。
- 从来不得将未执行的审查报告为已完成，也不得要求未请求的 Codex 审查。
- 从来不得覆盖用户限制或超出请求的结果和确认的修正范围。
- 从来不得在委托的修正内部复制
code-review-fix或pr-fix循环。 - 从来不得启用停止审查门，或将自动技能选择呈现为技术强制。
- 从来不得安装缺少的运行时，或用看似成功的结果替换缺失的证据。