# Zc Sdd Tdd Workflow

> SDD+TDD 工作流

- Skill: `zmice/zc-sdd-tdd-workflow` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zmice/zc-sdd-tdd-workflow`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zmice/zc-sdd-tdd-workflow/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: zmice (https://skillmd.com/u/zmice)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zmice/zc-sdd-tdd-workflow

---


# SDD + TDD 开发工作流

## 角色定位

这是完整交付的编排 skill，不是每个阶段的详细教程。它负责把需求按阶段推进，并在进入具体阶段时再读取对应专项 skill。

渐进式披露规则：

- 当前只需要路由和门控时，只读取本文。
- 进入某个阶段时，再加载该阶段 skill。
- 不把所有阶段规则同时塞进上下文。
- 发现任务变成 bug、文档、发布或上下文问题时，切换到对应入口，不继续硬走完整流程。

## 快速路径

1. 判断任务是否需要完整交付；简单修复、文档或调查任务不要套完整流程。
2. 若需求模糊，先进入 `brainstorming-and-design` 或 `spec-driven-development`。
3. 若规格清楚，进入 `planning-and-task-breakdown`。
4. 计划可执行且实现已获授权时，进入 `incremental-implementation`；可测试的行为变更配合 `test-driven-development`。
5. 实现完成后，进入 `code-review-and-quality`。
6. 准备声明完成前，进入 `verification-before-completion`。
7. 需要提交时，进入 `git-workflow-and-versioning`；缺少提交授权才询问，已有授权不重复确认。
8. 周期结束或需要沉淀经验时，进入 `sprint-retrospective`。

## 阶段门控

| 阶段 | 默认入口 | 通过条件 |
|---|---|---|
| Brainstorm（可选） | `brainstorming-and-design` | 目标、约束、方案方向已收敛 |
| Specify | `spec-driven-development` | 规格可测试，假设已显式列出 |
| Plan | `planning-and-task-breakdown` | 任务有依赖、文件边界和验证方式 |
| Plan Review（可选） | `multi-perspective-review` | `GO / REVISE / NO-GO` 结论明确 |
| Build | `incremental-implementation`，行为变更配合 `test-driven-development` | 切片完成并通过与行为、风险及项目门禁相称的验证；纯文档等非行为切片使用相关 diff、lint 或内容检查 |
| Review | `code-review-and-quality` | Critical/Important 已处理或有明确延后理由 |
| Verify | `verification-before-completion` | 新鲜验证命令通过，输出已读 |
| Commit（可选） | `git-workflow-and-versioning` | 提交在用户授权范围内，内容与消息可审阅 |
| Retro（可选） | `sprint-retrospective` | 偏差、复盘和行动项已记录 |

## 构建模式选择

进入 Build 前先选择执行模式，而不是直接默认手动实现。复杂任务先评估 `Readonly Consult`，用低风险只读审查发现路线、测试、安全、性能或平台适配问题，再决定是否需要更重的写入型并行：

- **Manual**：简单任务、小修复或同一文件内紧耦合改动，主线程直接实现。
- **Readonly Consult**：复杂任务需要架构、测试、安全、性能、产品、上游吸收、Codex 适配、安装/更新或审查侧评；任务范围明确且 Codex host 可用时，通知后直接启动，不改文件。
- **Serial Subagent**：已有计划，任务彼此独立但有依赖顺序；使用 `subagent-driven-development` 串行委派。
- **Context Fan-Out**：任务可以按文件、模块或证据问题并行，且有清晰文件所有权和 fan-in gate；使用 `parallel-agent-dispatch`。低风险写入在实现已授权、所有权和验证清楚时可通知式启动；高风险缺少对应授权时才确认，边界不清时先收敛或降级串行。
- **Team Orchestration**：需要 tmux + git worktree 文件系统隔离、长时间多 worker 或 Codex / Qwen 多 CLI 协作；使用 `team-orchestration`，必须用户明确要求或确认。
- **Context Steward Sidecar**：长期项目事实确需更新，且写入授权与独立所有权清楚时，考虑派 `agent:context-steward` 维护上下文；普通实现授权不自动扩展为用户配置或跨会话记忆写入。权限遵循共享契约，fan-in 核对 context stewardship report 与写入证据；不满足条件时记录待刷新项并继续主任务。

Build 阶段消费计划中的 `agent_opportunity`；计划缺失时先按 `parallel-agent-dispatch` 的 agent opportunity contract 补判，再路由到对应执行 skill。此处只维护生命周期差异：

- 主线程负责目标、stop gate、fan-in 和最终验证，不抢占已分配任务。
- Manual 直接实现；Serial 按依赖顺序；Fan-Out 按互斥所有权执行；Team 仅在显式确认后进入。
- 执行模式不可用或边界失效时，按计划的 degraded path 缩小范围或降级串行。
- Review 和 Verify 继续消费 fan-in evidence；并行完成不能跳过集成验证。

## 审查与回归闭环

多 agent 任务必须遵循闭环所有权：

```text
producer owns fix
reviewer owns regression
controller owns fan-in
```

- 实现方或产生方负责优先修复自己引入的问题。
- 审查方或提出方负责给出复现条件、断言、期望行为、风险等级，并在修复后复验原 finding。
- 主线程负责判断 finding 是否成立、优先级是否阻塞、是否转派、是否接受结果。
- 实现方两次修不好时，主线程可以缩小问题后转给更合适的 agent 或自己接手。
- 审查方默认不直接修；机械小修或用户明确要求时，主线程可以把 finding 转成修复任务。

审查等级：

- `light review`：实现方自审 + 主线程检查。
- `standard review`：实现方自审 + 独立 reviewer + 提出方回归。
- `strict review`：规格审查 + 代码质量审查 + 测试 / 安全 / 性能按风险加入。

中等以上任务默认 `standard review`，高风险任务默认 `strict review`。

## 阶段切换纪律

- 进入新阶段前，说明当前阶段已满足的证据。
- 阶段门控检查证据，不默认要求人工逐阶段批准；已授权工作持续到完成相关验证、修复引入的失败和交付结果。
- 用户只要求研究、方案或评审时，在该范围完成；不得自行扩大为实现或发布。
- skill 指导与用户明确要求冲突时遵循用户要求。若某条指导确实要求暂停，指出具体文件、条款和缺失决策；不要把例行步骤解释为新授权门槛。
- 阶段中发现前提失真时，回退到上游阶段，不继续堆实现。
- 长会话变慢或内容开始混乱时，切到 `context-budget-audit` / `context-engineering`。
- 变更涉及浏览器体验时，在单元/API 测试之外补 `browser-qa-testing`。
- 涉及高风险命令、生产数据或敏感文件时，先切到 `safety-guardrails`。

## 停线条件

立即停止当前阶段并重新定位：

- 测试、构建或 lint 失败但原因未读清。
- 用户纠正使当前步骤与最新需求或安全边界冲突时，停止受影响步骤，保留仍有效的成果，调整计划后继续授权范围内的工作；普通补充要求或状态询问不重启整条流程。
- 计划要求修改的文件和实际代码结构明显不一致。
- 出现破坏性操作、凭据、生产数据或不可逆迁移风险。
- 需要并行但没有文件所有权、隔离策略和 fan-in 验证。
- review finding 未闭环，或提出方尚未完成回归确认。

## 输出契约

完整交付过程中的关键结论都要使用可审查的推荐格式：

```text
Recommendation: <下一步动作> because <具体证据、取舍和被放弃的替代方案>。
```

有真实方案取舍时说明原因和验证方式；例行阶段推进只需说明结果与下一步，不为填格式虚构替代方案。

## 验证

声明完成前至少给出：

- 实际运行的验证命令
- 退出结果
- 与本次任务相关的关键输出
- 未运行的验证及原因

不能用历史结果、主观判断或“应该没问题”替代验证证据。