mattpocock/skills 使用流程（官方标准工作流）
来源：https://github.com/mattpocock/skills 仓库
skills/目录原始定义
一、两类触发方式（理解流程的前提）
- User-invoked（手动触发）：你输入
/xxx才跑，负责编排主流程。 - Model-invoked（自动触发）：任务匹配时 agent 自动调用，承载可复用规范。
- 规则：user-invoked 可以调用 model-invoked，但不能调用另一个 user-invoked。
所以下面的"主流程"全是你手动驱动的；查 bug、code review 这类规范会在合适时机自动介入。
二、标准主流程（最核心）
/grill-with-docs → /to-prd → /to-issues → /tdd (或 /implement)| 步骤 | skill | 官方定义的作用 | 这一步在解决什么 |
|---|---|---|---|
| 1 | /grill-with-docs | 盘问会话，同时构建项目领域模型：锐化术语、内联更新CONTEXT.md和 ADR | 对齐需求、和 agent"达成共识"，把模糊需求逼清楚 |
| 2 | /to-prd | 把当前对话直接合成 PRD发布到 issue tracker（不访谈，只综合已讨论内容） | 把共识固化为文档，避免对话散掉、后续遗忘 |
| 3 | /to-issues | 把计划/规格/PRD按垂直切片拆成可独立认领的 issues | 端到端拆分任务（一个 issue 跑通一个需求从后端到前端），而非层间横切 |
| 4 | /tdd（或/implement） | TDD 红-绿-重构循环，一次一个垂直切片；或 implement 实现 | 动手写代码，每切片可独立验证 |
经验参考点（已回归官方）：
to-prd和to-issues常成对出现，但明确的小需求可跳过 PRD 直接to-issues——官方本就将它们设计为两个独立 skill，拆分有道理。
三、常见变体与分支流程
变体 A：从架构体检出发
/improve-codebase-architecture → (prototype) → /to-prd → /to-issues → /tdd/improve-codebase-architecture：扫描代码库找深化机会，生成可视化 HTML 报告，再陪你盘问选定项。适合项目变"泥球"后重构，建议定期（每几天）跑一次。
变体 B：修 bug
/diagnosing-bugs → /tdd/diagnosing-bugs：纪律化诊断循环reproduce → minimise → hypothesise → instrument → fix → regression-test。修好后用/tdd补回归测试。- ⚠️ 注意：官方
diagnosing-bugs本身就包含 fix 和 regression-test，不要像某些魔改版那样把它砍成"只报原因"——那会丢失官方闭环。
变体 C：视觉/交互对齐（可选）
/prototype (通常新开 session)/prototype：构建可丢弃原型回答设计问题。UI 类需求 → 一条路由下多个可切换的激进变体；状态/逻辑类 → 可跑的终端程序。原型不合适就扔掉，用来低成本测想法。- 经验参考：复杂视觉交互需求可先用
/prototype对齐再进主流程；prototype 一般新开 session，用/handoff交接上下文。
四、自动介入的规范类 skill（model-invoked，无需手动排程）
这些在任务匹配时由 agent 自动触发，是主流程质量的"兜底"：
/tdd的规范由 model 在写代码时遵循红-绿-重构/code-review：对固定基准点后的 diff 做双轴审查——Standards（遵循仓库规范 + Fowler 坏味道基线？）与 Spec（是否忠实实现来源 issue/PRD？），并行子 agent 互不污染/domain-modeling：主动构建/锐化领域模型，对照术语表挑刺，更新 CONTEXT.md/ADR/codebase-design：设计深模块的共同规范（小接口后藏大量行为）/research：针对高可信一手来源调研，结果写成带引用 Markdown（可后台运行）
五、辅助与交接类（可按需用）
/handoff：把当前对话压缩成交接文档，交给另一个 agent/session 继续（如 claude↔codex 互换、prototype session 转主流程）/ask-matt：不确定该用哪个 skill 时，让它路由到合适的 user-invoked skill/grill-me：同grill-with-docs但不写文档，纯盘问对齐（非代码场景也适用）/teach、/writing-great-skills：教学 / 编写 skill 参考，非日常开发流
六、完整标准工作流一图
新需求 │ ├─ (可选) /prototype 测想法 / 对齐视觉 │ ▼ /grill-with-docs ──共识──▶ /to-prd ──▶ /to-issues │ (定期) /improve-codebase-architecture │ ▼ /tdd 或 /implement │ bug? ──▶ /diagnosing-bugs ──▶ /tdd │ ▼ /code-review (自动双轴) │ (换 session/agent) ──▶ /handoff