用途
Phase Kickoff 用于在开始一个新的开发阶段或冲刺时，把三项准备工作作为一次原子操作完成：创建分支、生成 TDD 测试骨架、写入路线图条目。其核心目的是强制一条不变量——实现工作绝不能在分支和验证骨架存在之前开始。
主要能力
- 解析参数中的阶段编号与标题（例如 "3 - User Authentication" 或 "4 Real-time Notifications"）。
- 向路线图追加阶段条目，包含目标、任务清单和验证字段。
- 创建分支，命名格式为 feature/phase{N}-{kebab-case-title}。
- 生成 TDD 测试骨架，describe 块与路线图任务一一对应，使用 it.todo("should ...") 占位。
- 打印摘要：阶段编号、分支、测试文件路径、任务数量。
使用方式
通过脚本调用：
bash scripts/scaffold-phase.sh "3 - User Authentication"
输出内容包括：分支名称、测试文件路径、路线图存根。
执行步骤：
- 解析 $ARGUMENTS：提取阶段编号和标题。
- 追加路线图条目，格式为：
## Phase {N}: {Title}
**Goal**: {one-sentence goal}
- [ ] {N}.1 {task}
**Verify**: {runnable command or unambiguous outcome}
- 创建分支：
git checkout -b feature/phase{N}-{kebab-case-title} - 创建 TDD 测试骨架，describe 块匹配路线图任务：
describe("Phase {N}: {Title}", () => {
describe("{N}.1 - {task}", () => {
it.todo("should ...");
});
});
- 打印摘要：阶段编号、分支、测试文件路径、任务数量。
参数：$ARGUMENTS 为阶段编号和标题，例如 "3 - User Authentication" 或 "4 Real-time Notifications"。
适用场景
- 启动需要同时完成分支创建、TDD 测试骨架和路线图条目的新开发阶段或冲刺。
限制与不适用场景
以下情况不应加载该技能：
- 阶段已存在，现在需要的是执行而非搭建。
- 任务是一次性修复，没有路线图或分支骨架需求。
- 用户只需要规划，不需要修改仓库。
强制规则
- 绝不在分支和测试骨架存在之前开始实现。事后补建骨架意味着测试骨架描述的是已存在的代码，而非驱动其设计；TDD 骨架的价值在于迫使你在编写行为之前先命名行为。
- 绝不创建没有具体目标和验证标准的阶段条目。模糊的路线图条目（如 "improve auth"）会变得无法合并，因为没人能就 "完成" 达成一致。验证字段必须是可运行的命令或无歧义的可观察结果。
- 绝不把无关的清理工作混入 kickoff 提交。kickoff 提交是该阶段的参照点，混杂的关注点会让 git bisect 和阶段差异比对不可靠。
- 绝不使用像 feature/phase3 这样的通用分支名，应包含标题 slug，使 git branch -a 无需交叉参照路线图即可读懂。
专家决策点
何时拆分还是扩展阶段：如果不确定工作属于新阶段还是扩展当前阶段，可问：是否有不同的主要交付物？是否有不同的部署风险？能否被独立评审？两个答案为 "是" 则新建阶段，否则扩展。
测试骨架结构决定阶段质量：测试骨架中的 describe 层级就是该阶段的规格说明。应在路线图任务之前编写，而非之后。如果无法为某个任务写出有意义的 it.todo("should...")，说明该任务定义得不够清晰，不足以开始。
路线图验证字段：验证字段是质量门。可接受形式包括：
npx vitest run src/auth—— 可运行的测试命令curl -s localhost:3000/health | jq '.status == "ok"'—— 可观察结果pnpm build && npx tsc --noEmit—— 构建门
不可接受："auth works"、"tests pass"、"looks good"。