メニュー
TDD 跨语言通用纪律——强制 Red-Green-Refactor：写失败测试→最小实现通过→测试保护下重构；新增/修改/删除三类变更均先动测试再动实现。触发：新增/修改/删除业务逻辑源文件（.go/.py/.ts/.tsx/.vue/.js/.rs/.java/.kt）、用户提到 TDD/写测试。跳过：纯 struct/interface/常量定义、生成代码、纯文档、纯配置、vendor/node_modules。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
本地 ultrareview——多代理、对抗验证、只读的 PR 级 review；默认 base=main；并发 5 个 finder（质量/安全/简洁/鲁棒性/文档同步），每条 🔴/🟡 发现交 3 个独立怀疑视角对抗验证、多数决去留；可选追加本次 review 重点，注入每个 finder 优先关注（不替代其他维度）。触发：/review、给当前分支做深度审查、PR 前 ultrareview。跳过：不在 git 仓库、当前分支=base。
产出修订（诊断→定向修正→回归验证）——对 spec→plan→exec 偏差做根因归类：spec-defect / impl-defect / requirement-change；先诊断再修正、改代码必先 Red 测试、最小影响只改必须改的层；已完成 plan 是历史审计快照禁止回改；启动先 worktree 感知定位修复现场（主仓库停在 main 时自动定位到进行中的 worktree）。触发：/revise、有 bug、结果不对、和预期不符、产出需要优化、review 发现违规需修复。跳过：纯新增需求（→/spec→/plan）、还没有 spec/plan/代码可对照。
本地 ultrareview——跨模型、多代理、对抗验证、只读的 PR 级 review（依赖 Workflow 工具，Claude Code ≥2.1.154）；默认 base=main；并发 6 个 finder（质量/安全/简洁/鲁棒性/文档同步/Codex 跨模型），每条 🔴/🟡 发现交 3 个独立怀疑视角对抗验证、多数决去留；可选追加本次 review 重点，注入每个 finder 优先关注（不替代其他维度）。触发：/review、给当前分支做深度审查、PR 前 ultrareview。跳过：无 Workflow 工具、不在 git 仓库、当前分支=base。
产出修订（诊断→定向修正→回归验证）——对 spec→plan→exec 偏差做根因归类：spec-defect / impl-defect / requirement-change；先诊断再修正、改代码必先 Red 测试、最小影响只改必须改的层；已完成 plan 是历史审计快照禁止回改；启动先 worktree 感知定位修复现场（主仓库停在 main 时自动定位到进行中的 worktree）。触发：/revise、有 bug、结果不对、和预期不符、产出需要优化、review 发现违规需修复。跳过：纯新增需求（→/spec→/plan）、还没有 spec/plan/代码可对照。
Git 开发流程纪律——禁 main 直接提交；新任务前扫工作区根，有 workspace 标记走多 repo 工作区，否则 `question` 工具 询问 worktree（默认）或切分支；worktree 一律落 `~/.bb-spec/worktrees/` 下、禁嵌套当前 repo / 禁放 sibling 目录；本地 commit 不立即 push、整功能验证完才推；合并后清理本地+远程。触发：开始改代码、提到开分支、要求 commit/push/开 PR、PR 合并后清理。跳过：纯咨询/阅读、极小打字纠错。
前端技术栈强制约束——默认 Vue 3 + TS + Vite + Tailwind；bun 是默认包管理器（新项目强制），既有项目跟随 lockfile 不迁移。触发：新建前端项目；编辑 package.json/vite.config/tailwind.config/.vue/.ts/.tsx；用户提到前端/vue/vite/tailwind。跳过：纯后端/CLI/工具项目；用户明确说用 React/Nuxt/Svelte 等。
| name | tdd-workflow |
| description | TDD 跨语言通用纪律——强制 Red-Green-Refactor：写失败测试→最小实现通过→测试保护下重构；新增/修改/删除三类变更均先动测试再动实现。触发：新增/修改/删除业务逻辑源文件（.go/.py/.ts/.tsx/.vue/.js/.rs/.java/.kt）、用户提到 TDD/写测试。跳过：纯 struct/interface/常量定义、生成代码、纯文档、纯配置、vendor/node_modules。 |
适用于：所有语言、所有业务逻辑代码的新增 / 修改 / 删除变更。
核心：测试是设计工具，不是验证工具。 先写测试迫使你以调用方视角想清楚行为契约。
TRIGGER：新增/修改/删除业务逻辑源文件（.go/.py/.ts/.tsx/.vue/.js/.rs/.java/.kt 等）；用户提到 TDD/写测试/test-first。
SKIP：纯 struct/interface/enum/常量定义、生成代码、纯文档、纯配置、vendor/node_modules。
RED → 写一个失败测试，明确行为预期 → 跑测试确认 FAIL
GREEN → 写最小实现让测试通过 → 跑测试确认 PASS
REFACTOR → 测试保护下重构 → 跑测试确认仍 PASS
RED 要点：真的失败（断言不通过，不是编译错误）；一次只引入一个最小行为预期。 GREEN 要点：最小实现（允许傻瓜实现）；不提前写未覆盖的代码。 REFACTOR 要点：不新增行为；每次小改动后跑测试。
RED（写失败测试）→ GREEN（最小实现）→ REFACTOR → 下一个行为。禁止先写实现再补测试。
RED（先改/增测试反映新预期）→ 确认 FAIL → GREEN（改实现）→ 确认全 PASS。禁止先改实现再调测试。
检查无依赖 → 先删测试 → 再删实现 → 跑完整测试套件。禁止先删实现导致编译失败再被动删测试。
整体期望 80%+（期望而非硬拦截，显著下降需在 PR 说明中解释）。
优先级：业务逻辑层 > 关键纯函数 > 错误分支 > 边界条件 > 集成边界。 不强求：纯定义文件、框架样板、一次性脚本。
本 skill = "做不做、按什么顺序做"（通用纪律）。golang-testing 等 = "具体怎么写"（语言惯用法）。