菜单
新功能、bug 修复、重构或行为变化需要测试先行时使用。强调先写失败测试、确认失败原因、最小实现和保持测试绿色。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Stress-test a plan, design, decision, or idea through a one-question-at-a-time interview. Use when the user invokes /grill, says grill me, asks to be challenged, 拷问, 压力测试, or wants a plan stress-tested; also use when progress is blocked by an unresolved user-owned decision whose alternatives materially change the outcome after high-risk classification is ruled out. Do not use merely because work is complex, high-risk, new, or spans multiple files.
Use when the user explicitly requests Brainstorming, a design spec, Spec Gate, or the full Superpowers workflow; also use automatically for costly-to-reverse high-risk work involving architecture or service boundaries, public-contract compatibility, authentication or authorization, persistent data/schema migration, or irreversible external side effects. Do not use for ordinary behavior changes or merely because work is new, complex, or spans multiple files.
Chinese workflow for surfacing systematic fact, evidence, context, and blind-spot gaps before, during, and after agentic work. Use when the user explicitly asks for a blind-spot scan, unknown unknowns, prototypes, reference mapping, implementation notes, explainers, or quizzes; when phrases like "I'll know it when I see it" or "teach me this domain" expose unstated assumptions; or when safe progress is blocked by evidence gaps that require multiple low-cost probes. Do not use merely because work is complex, high-risk, long-running, or spans multiple files.
Use when starting or routing a non-trivial task in this workflow harness, when the user references Superpowers, or when deciding which skill, command, rule, or agent should govern the work. Establishes skill invocation discipline: check relevant process skills before acting, follow user/project instructions first, and verify before completion.
Use when you have a spec or requirements for a multi-step task, before touching code
用于功能验收、回归验证、确认修复是否生效，以及需要用真实界面、视频或日志证据判断用户流程是否正常的任务。适用于“验收一下”“测一下”“确认修复”“给我可复核证据”等请求。
| name | test-driven-development |
| description | 新功能、bug 修复、重构或行为变化需要测试先行时使用。强调先写失败测试、确认失败原因、最小实现和保持测试绿色。 |
参考来源: https://github.com/obra/superpowers/tree/main/skills/test-driven-development
本 skill 是本仓库的精简版本，只保留适合 agent 执行的 TDD 规则，不复制外部 skill 全文。
例外情况需要先和用户确认，例如一次性原型、生成代码、纯配置整理或没有可测试行为的文档修改。
新功能、bug 修复、重构引起行为变化、公共 API 变化和用户流程变化，必须先写失败测试并运行确认失败原因正确，才能写行为实现代码。
如果当前任务确实没有可测试行为，先记录原因，并给出替代验证方式，例如脚本 smoke test、文档 diff 检查、人工验收步骤或 harness 验证命令。
