Phase 3 / Ep 13: 配置 test-driven-development 技能流

为了让那头巨兽（大模型开发代码）套上锁链，我们需要在防备系统 .agents/skills/ 目录下创建一个针对性的技能说明书。利用 using-superpowers 的雷达效应，让 AI 每次写具体业务前，强制被引入这个工作流。

1. 建立 TDD 技能档案

在 .agents/skills/test-driven-development/SKILL.md 中写下这套纪律：

name: test-driven-development
description: 遇到任何实现 Feature 或 Fix Bug 指令时触发，在撰写业务逻辑文件前必须阅读本纲要。

# TDD 红绿转换铁律

**核心禁止线**：禁止“边猜边写业务代码然后再补测试”。必须严格遵循此步骤，不准跳步。

1. **写出红线 (Red)**:
   - 先创建或在现有的 `*.spec.ts` 文件中，写出关于你即将要实现的目标的测试用例（Test Case）。
   - 用命令运行跑它（一定是 Fail 抛出红字的，因为这个时候源业务文件还是个空壳）。
   - **读取 Error！**确认测试跑挂的原因确实是因为“功能没实现”而不是语法错误。

2. **化为绿灯 (Green)**:
   - 转头去 `src/` 目录下完成最小化可行性的业务代码（只求能跑通跑绿，先不要追求架构多精美）。
   - 反复运行终端测试。
   - 这是你**唯二**允许进入代码微调循环的阶段。

3. **重构提纯 (Refactor)**:
   - 当终端绿了 `PASS`，这时才是你发挥“架构师”水准的时候。
   - 提取业务里的公共方法、优化时间复杂度、增加代码可读性。
   - 放心大改，因为测试这把大锁已经挂好了。如果你重构坏了，它就会红！

2. 赋予工具集的终端自由

在使用像 Antigravity/Claude Code 这类具备高级终端沙箱的 Agent 时，我们必须确认系统底座已经安装好了 Vitest。

在终端或者任务版下达一个任务：

"请配置好项目的 Vitest 环境，配置好 package.json 的 script 为 test:unit。"

这个动作不是为了写业务代码，是为了让 Agent 未来可以通过运行普通的 Shell 命令（比如 npm run test:unit），把自己的代码验证交给客观的机器，而不是靠着你的眼睛或者它的幻觉。

测试基建铺排完毕。下一期，真正的残酷战役打响。我们将执行 task_plan.md 里的第一个代码动作，亲眼看看 Agent 是如何在测试红字的折磨下，冲出重围的！