spec-driven-tdd

spec-driven-tdd

在 OpenSpec 中规划和跟踪。按照 Superpowers 规范实施。一次只处理一个变更，一次只处理一个任务。

核心原则： OpenSpec 负责做什么和进度；执行技能负责如何做。只有审查通过后，任务才算完成——测试通过还不够。

依赖项

需要安装 OpenSpec CLI 和 Superpowers。如果引用的技能或命令不可用，请说明情况，并按照 docs/dependencies.md 中的说明回退——绝不可悄悄跳过某个步骤。/code-review 是仅适用于 Claude Code 的可选增强功能。

生命周期

1. 规划（OpenSpec）

可选——可行性探测（按风险决定）。 如果工作涉及尚未验证的技术风险（未经测试的方法、外部 API，或“这是否可行”尚无定论），请在提出变更之前调用 spike 技能。如果可行性已经明确，则跳过。根据其结论采取行动：VALIDATED → 继续提出变更；PARTIAL → 将范围缩小到可行的子集，然后提出变更；INVALIDATED → 停止，不要创建变更（告知用户原因）。探测代码是一次性的，绝不能进入变更的工作树。

如果这项工作还没有变更，请运行 /opsx:propose（它会使用 brainstorming 确定范围，然后编写提案、设计和任务）。OpenSpec 是范围和任务列表的唯一事实来源。不要在其中之外自行添加任务。

2. 隔离（工作树）

在接触代码之前，调用 using-git-worktrees 为该变更创建隔离的工作树，以保持主工作区干净。（最后会配合使用 finishing-a-development-branch。）

3. 实施——逐任务循环

通过 /opsx:apply 获取任务列表和上下文（读取每个 contextFiles 路径）。然后，对每个待处理任务执行以下微循环：

1. RED — 调用 test-driven-development：先编写一个失败的测试。没有失败的测试，不得编写生产代码。
2. GREEN — 编写能通过测试的最少代码。如果测试意外失败，先调用 systematic-debugging，再进行猜测。
3. REFACTOR — 在测试通过的情况下，进行单元范围内的清理。
4. simplify — 调用此工具包的 simplify 技能，对整个差异进行质量检查；该技能会应用修改。
5. 重新运行测试 — simplify 之后，测试仍必须通过。
6. 审查 — 对任务的差异调用 requesting-code-review；使用 receiving-code-review 处理审查意见。在 Claude Code 上，还可以额外运行 /code-review。继续之前，先修复所有 Critical 和 Important 问题。
7. 标记完成 — 只有现在，才能在 OpenSpec 任务文件中将任务从 - [ ] 改为 - [x]。

可选模式——大型变更： 只有当任务列表确实很大且任务彼此独立时，才委派给 subagent-driven-development——不要将其用于少数几个可以直接完成的任务。它会将每项任务分派给全新的子 Agent，并逐任务审查。仅对没有共享状态的任务使用 dispatching-parallel-agents，并限制并发子 Agent 的数量。

如果任务含糊不清，或实施过程中发现设计问题，请暂停并询问（然后建议更新 OpenSpec 工件）。

4. 完成

当所有任务都标记为 [x] 后：

1. verification-before-completion — 确认变更确实有效。
2. finishing-a-development-branch — 合并工作树中的分支。
3. /opsx:archive 然后 /opsx:sync — 结束跟踪并更新主规范。

检查清单

• 在 OpenSpec 中选择或创建变更
• 已创建工作树
• 每项任务在标记 [x] 前都经过 RED→GREEN→REFACTOR→simplify→review
• 所有任务都标记为 [x]
• 已验证、完成分支，并归档和同步变更