菜单
Use when 用户要实现新功能、修复 bug，或明确要求使用 TDD 方式开发、先写测试时。触发场景：tdd、测试驱动、测试驱动开发、先写测试、红绿重构、单元测试、test driven、TDD开发、用TDD写、测试先行、我要开始开发新功能。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
超压缩通信模式。通过去掉废话、冠词和客套语，在保持完整技术准确性的同时削减约 75% token 用量。 当用户说"caveman 模式"、"简洁模式"、"少废话"、"省 token"、"简短点"或调用 /caveman 时触发。
对用户的计划或设计进行不留情面的深度追问，直到达成共同理解，逐一解决决策树的每个分支。当用户想要压力测试计划、检验设计时触发。触发词：追问我、grill me、逐一问我、挑战我的方案、深度追问、质疑设计、设计评审追问。
将当前对话压缩为交接文档，供下一个 Agent 会话接续工作。触发词：交接、handoff、下一个会话、会话摘要、接续工作、传给下一个 agent。
在代码库中发现架构"深化"机会——将浅模块变成深模块的重构，提升可测试性和 AI 可导航性。与 architecture-advisor 互补：architecture-advisor 设计新架构，本技能改善现有代码库结构。触发词：改进代码库架构、架构深化、找重构机会、模块耦合太紧、难以测试、代码难以理解、架构改进、improve architecture、refactor opportunities。
快速验证设计的一次性原型。区分两条分支——逻辑/状态模型用终端交互 App，UI 布局用多变体路由切换。当用户想原型验证、检验数据模型或状态机、探索多种 UI 方案时触发。触发词：原型、prototype、验证方案、快速试验、让我玩一玩、试几个设计。
Use when 已有书面实施计划、任务相对独立，且在本会话内通过子代理逐任务落实时。触发场景：执行实施计划、子代理开发、按计划实现、Task 派发实现、两阶段代码审查、plan execution。
| name | tdd-master |
| description | Use when 用户要实现新功能、修复 bug，或明确要求使用 TDD 方式开发、先写测试时。触发场景：tdd、测试驱动、测试驱动开发、先写测试、红绿重构、单元测试、test driven、TDD开发、用TDD写、测试先行、我要开始开发新功能。 |
铁律：没有失败的测试，不写一行生产代码。 先写代码再补测试的，必须删掉先写的代码重来。
禁止在以下情况下编写任何生产代码： 1. 还没有一个因"正确原因"而失败的测试（RED 阶段未完成） 2. 用户还没有确认接口设计和行为清单（阶段一未完成） 这两条无一例外，"简单功能"也不例外。反模式（横向切片）：先把所有测试写完，再一口气写所有实现
正确做法（竖向 tracer bullet 切片）：每次选一个最小可验证行为，完成 RED→GREEN→REFACTOR 完整循环
# 错误：测试内部实现（脆弱，重构即失效）
def test_calls_validate_method():
service = UserService()
with patch.object(service, '_validate') as mock:
service.create_user(data)
mock.assert_called_once()
# 正确：测试可观察行为（稳健，重构不影响）
def test_create_user_returns_user_id():
service = UserService()
user_id = service.create_user({"name": "Alice", "email": "a@example.com"})
assert isinstance(user_id, int)
assert user_id > 0
先设计公共接口，不暴露内部实现细节：
询问用户：这个功能/模块需要提供什么公共接口？
输出：函数/方法签名 + 输入/输出类型 + 前置/后置条件
加载 references/testing-principles.md 检查接口设计原则。
将功能拆解为可测试的行为列表：
待实现的行为：
- [ ] 正常路径：[描述]
- [ ] 边界条件：[描述]
- [ ] 错误路径：[描述]
- [ ] 并发场景：[如适用]
每个行为必须是：独立可测试 + 有明确期望结果 + 最小粒度
评估设计是否可测试（加载 references/testing-principles.md）：
将设计展示给用户确认，批准后才开始实现。
每次选一个行为（从行为清单第一项开始）：
写最小的失败测试：
test_用户注册成功返回用户ID）强制验证 RED（不可跳过）：
pytest tests/test_user.py::test_用户注册成功返回用户ID -v
确认：测试因正确原因失败（功能未实现），而非因测试代码错误失败
写最小的实现：只写让当前测试通过所需的最少代码
return 42），只要测试通过强制验证 GREEN（不可跳过）：
pytest tests/test_user.py -v
确认：全部测试通过，包括之前的测试
GREEN 失败则停止：回到实现代码修复，不重构，不写新测试
只在全绿时重构，RED 状态下严禁重构。
加载 references/refactoring-guide.md 进行安全重构：
每次重构后立即运行全部测试：全绿则继续，失败则撤销上一步修改。
勾选清单，选下一个行为，重复循环。
所有行为实现完成后，加载 references/deep-modules.md：
加载 references/mocking-guide.md 获取详细指引。
何时使用 Mock：
datetime.now()、time.sleep()）何时不用 Mock：
| 反模式 | 识别特征 | 处理方式 |
|---|---|---|
| 横向切片 | "先把所有测试写完" | 立刻停止，改为逐行为切片 |
| 测试实现细节 | patch.object 内部方法 | 重写为测试行为 |
| 巨型测试 | 一个测试验证多个行为 | 拆分为多个测试 |
| 跳过 RED 验证 | "我知道测试会失败" | 必须执行，有时会有惊喜 |
| GREEN 阶段重构 | 测试刚过就大改 | 先让所有测试通过再重构 |
| 过度 Mock | Mock 了自己写的类 | 测试真实集成 |
| 无意义测试名 | test_it_works | 改为行为描述 |
遇到以下想法，立刻停下——这些是你即将违反铁律的信号：
| 借口 | 现实 |
|---|---|
| "这个功能太简单，不需要先写测试" | 简单功能的边界条件往往出错。TDD 的价值在设计接口，不只是测试。 |
| "先写代码，写完后补测试效果一样" | 补测试 = 测"代码做了什么"，不是测"代码应该做什么"。本质不同。 |
| "我已经在心里验证过了，测试只是形式" | 心理验证不算验证。必须运行命令并看到红色输出。 |
| "用户在等，没时间写测试" | 没有测试的代码往往需要返工。TDD 总体耗时更短。 |
| "这是修复 bug，不需要走 TDD" | 修 bug 时先写能复现 bug 的测试，是最重要的 TDD 应用场景之一。 |
| "我只是稍微改了一点现有代码" | "稍微改" 没有测试保护 = 引入回归 bug 的标准路径。 |
| "RED 阶段测试肯定会失败，没必要运行" | "肯定会失败"的测试有时不会失败——这意味着测试本身有问题。必须运行。 |
这些借口的本质都是同一件事：你在合理化绕过 TDD。删掉先写的代码，重来。
references/testing-principles.md — 测试原则与可测试性设计references/mocking-guide.md — Mock 使用指南references/refactoring-guide.md — 安全重构技术references/deep-modules.md — 深模块设计原则