SKILL.md
<SUBAGENT-STOP> 如果你是作为 subagent 被派遣来执行某个特定任务，请跳过这个 skill。 </SUBAGENT-STOP>
auto-using-skills
核心规则
在任何回复、澄清、读文件、写代码或运行命令之前，先检查 skill。只要某个 skill 有 1% 的可能适用，就必须调用 Skill 工具读取它。
用户指令始终最高优先级；skill 决定的是怎么做，不覆盖用户明确说的做什么。如果调用后发现某个 skill 不适用，说明原因并继续检查其他 skill。
路由
按顺序判断：
- 用户点名 skill：先调用被点名的 skill。
- 仅限手动触发：
review-spec和review-code只能通过第 1 条进入。只有$review-spec、/review-spec、$review-code、/review-code，或明确说“使用 review-spec/review-code skill”才算点名；普通的“review”“审查”“audit”请求不算。没有点名时继续执行后续路由，不要因意图或 description 相似而自动选择它们。 - 执行已确认范围或修复：用户已批准 spec、scope 已取得对话内实施契约确认，或 debug 已提交证据充分的修复契约且用户明确批准时，调用
implement。bug 使用source_kind: approved-fix；此项优先于通用 bug 路由，即使确认消息再次提到“bug”“失败”或“修复”。 - 新的 bug / failure：用户报告坏了、报错、测试失败、build 失败、flaky、变慢、性能退化或行为不符合预期，且还没有获批修复契约时，调用
debug。不要先走scope。 - 项目知识 / wiki：用户要沉淀、查找、整理或迁移项目长期知识，维护
docs/wiki，调用wiki。 - 未定需求：用户要加 feature、设计行为、改交互、新建系统、重构、规划或 review，且范围还没钉清，调用
scope。 - Git 工作流：纯只读调查、对话内需求澄清和不落盘的计划不调用
git-workflow。首次持久化写入前必须已有prepare；已验证的独立工作单元按需调用checkpoint；任务结束或外部 handoff 前必须调用finalize。同一任务在 Skill 间转交时，gitstate: prepared继承现有 Git 生命周期，gitstate: unprepared才执行prepare。调用时必须写明阶段，不能只说“参考 Git 偏好”。 - 即将写生产代码：如果下一步会实现新行为、重构或改现有行为，统一由
implement按内置测试先行契约执行。bug 修复必须先由 debug 形成并获批approved-fix，再交给 implement；不要从 debug 或“确认”消息直接开始修改生产代码。 - 其他匹配 skill：任何 skill 的 description 命中当前任务，就调用它，但不得绕过第 2 条的手动触发限制。
调用后
调用 skill 后：
- 告诉用户：
Using [skill] to [purpose]。 - 如果 skill 有 checklist，把每项登记为 todo。
- 严格按 skill 内容执行，再回复用户。
警示信号
出现这些想法时，停下来重新检查 skill：
- "先问个澄清问题再说"：澄清前也要检查 skill。
- "先看文件 / 跑命令"：行动前也要检查 skill。
- "这很简单"：简单任务也可能有适用 skill。
- "我记得这个 skill"：读取当前版本，不凭记忆执行。
- "用户说了修 bug，所以直接修"：用户说的是目标，不是允许跳过 debug。
- "已经 scoped / debug 过了，可以直接写代码"：先把已确认契约交给 implement，由它建立 Git 所有权并执行测试先行流程。
- "用户确认了 bug 方案，直接开始修"：先把
approved-fix交给 implement，不在 debug 内实施。 - "开始时已经调用过 Git skill，结束时不用再调"：prepare 不能替代 finalize。
- "写一句未提交就可以结束"：如果偏好要求自动提交或推送，必须完成动作或给出明确 blocker。