grill-me系列解析,从想法到施工的流水线

grill-me 系列 Skill：从想法到施工的流水线

来源：Matt Pocock 的 skills 仓库（mattpocock/skills）。核心思想：在任务开始前先把想法逼问清楚（访谈），再沉淀领域语言与决策（文档），再签合同（spec），最后拆工单（tickets）并行施工。

0. 整体架构：入口 + 原语

仓库里的 skill 分三层：

• 路由器：ask-matt（回答"我该用哪个 skill"）
• 入口：grill-me、grill-with-docs、to-spec、to-tickets 等
• 原语（被复用的核心）：grilling（面试算法）、domain-modeling（领域模型/ADR）、codebase-design（深模块词汇）

入口只做两件事：选择原语组合 + 决定是否留下产物。

1. grill-me：无状态访谈入口

我的理解：甲方（我）抛出想法，乙方（agent）通过轮番提问逼出所有隐含决策。它不写任何文件、不留档，聊完就散。适用任何话题（代码、商业决策、写作）。

核心源码（grill-me/SKILL.md 全文，逻辑全部委托给 grilling）：

—
name: grill-me
description: A relentless interview to sharpen a plan or design.
disable-model-invocation: true
—

Call the Skill tool with "grilling".

disable-model-invocation: true 表示只能由用户手动触发（输入 /grill-me），模型不会自己调用它。

2. grilling：访谈原语（设计树 + 轮次 + frontier）

我的理解：

核心源码（grilling/SKILL.md）：

Interview the user relentlessly until you reach a shared understanding.
Map this as a **design tree**: every decision branches into the decisions
that hang off it.

Work the tree in **rounds**. The **frontier** is every decision whose
prerequisites are already settled: the questions you can ask _now_ without
guessing at answers you haven't heard yet. Ask the whole frontier in one
round: number each question and give your recommended answer. Then wait for
the user's answers before the next round.

Finding _facts_ is your job, never the user's. When a frontier question
needs a fact from the environment (filesystem, tools, etc.), dispatch a
sub-agent to find it; don't ask the user for anything you could look up
yourself. … The _decisions_ are the user's: put each to them and wait.

The session is done when the frontier is empty: every branch of the design
tree visited, nothing left silently assumed. Do not act on it until the
user confirms you have reached a shared understanding.

提问格式模板：Q1 – 标题: 问题内容 + 推荐答案。

给我的启示：grilling 是"乙方"，但决策权永远在甲方；乙方负责查事实、给推荐，甲方负责拍板。

3. grill-with-docs：有状态版访谈

我的理解：和 grill-me 跑同一个访谈，但有状态——边聊边把结果沉淀成项目文档：CONTEXT.md（术语表）+ ADR（决策记录）。适合在真实的代码仓库里用，访谈同时留下"会议纪要"。

核心源码（grill-with-docs/SKILL.md 全文）：

—
name: grill-with-docs
description: A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.
disable-model-invocation: true
—

Call the Skill tool twice, for "grilling" and "domain-modeling".

关键差异 = 多调了一个 domain-modeling 原语，这就是"留下文档"的来源。

4. domain-modeling：领域建模（统一语言 + 记录决策）

我的理解：

• CONTEXT.md = 项目术语表：只定义"词怎么说、指什么"，不写实现细节（例如 account 是指的是 admin 还是 user）
• ADR = 架构决策记录：写"当初为什么这么定"，但不是所有决定都值得写
• 两者都是边聊边生成，术语一敲定就立刻写入，不批量补

核心源码（domain-modeling/SKILL.md 的 ADR 三条件——只有同时满足才写）：

Only offer to create an ADR when all three are true:

1. **Hard to reverse**: the cost of changing your mind later is meaningful
2. **Surprising without context**: a future reader will wonder "why did they do it this way?"
3. **The result of a real trade-off**: there were genuine alternatives and you picked one for specific reasons

If any of the three is missing, skip the ADR.

`CONTEXT.md` should be totally devoid of implementation details.
Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for
implementation decisions. It is a glossary and nothing else.

给我的启示：多数"决定"不用写 ADR（按钮放哪、变量叫啥）；只有难逆转 + 无上下文会困惑 + 有真实权衡的才写。

5. to-spec：把对话合成"合同"

我的理解：grill 完之后，把它（对话 + 代码库理解）综合成一份正式规格书并发布到 issue tracker，打 ready-for-agent 标签。它不采访，需要决策的信息在grill 阶段已经问完了，这里只做"整理成文"。其中的方法论重点是测试接缝（seams）：在哪一层测、尽量用现有 seam、能高则高、目标只有一个。

核心源码（to-spec/SKILL.md）：

This skill takes the current conversation context and codebase understanding
and produces a spec. Do NOT interview the user; just synthesize what you
already know.

2. Sketch out the seams at which you're going to test the feature. Existing
seams should be preferred to new ones. Use the highest seam possible. If new
seams are needed, propose them at the highest point you can. The fewer seams
across the codebase, the better – the ideal number is one.

Check with the user that these seams match their expectations.

规格书模板包含：Problem Statement → Solution → 长篇 User Stories → Implementation Decisions → Testing Decisions → Out of Scope → Further Notes。

给我的启示：to-spec 才是"合同"本体（技术总监/产品经理的交付物），不是 grill 的自动产物，需要手动触发。

6. to-tickets：把合同拆成施工工单

我的理解：把 spec/对话拆成一组 tracer-bullet 垂直切片工单：

• 每张票切一条 COMPLETE 路径（schema + API + UI + 测试），单独可验证/可 demo
• 每张票声明 blocking edges（被谁阻塞），无阻塞的票可立即开工
• 发布方式取决于 tracker 配置：本地 → .scratch/<feature>/issues/NN-*.md；真实 tracker → 原生 blocking 关系
• 特殊规则：宽重构（一个机械改动波及全代码库）用 expand–contract 序列，不硬塞垂直切片

核心源码（to-tickets/SKILL.md）：

<vertical-slice-rules>
– Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests): vertical, NOT a horizontal slice of one layer
– A completed slice is demoable or verifiable on its own
– Each slice is sized to fit in a single fresh context window
– Any prefactoring should be done first
</vertical-slice-rules>

Work the **frontier**: any ticket whose blockers are all done.
For a purely linear chain that means top to bottom.

Do NOT close or modify any parent issue.

给我的启示：并行开发 = 按 frontier 推进，不是无脑并发；依赖图由 blocking edges 显式给出。

7. 流程串起来（甲方乙方类比）

graph LR
A[甲方: 我<br/>抛出一个想法] –> B[grill-me / grill-with-docs<br/>乙方逼问 逼出所有决策]
B –>|边聊边记| C[CONTEXT.md + ADR<br/>术语表 / 决策记录]
B –> D[to-spec<br/>综合成正式合同 发布 tracker]
C –> D
D –> E[to-tickets<br/>拆成带依赖的施工工单]
E –> F[agent 按 frontier 并行施工]

• grill-me = 乙方（无状态访谈，不留档）
• grill-with-docs = 乙方 + 会议纪要（写 CONTEXT.md / ADR）
• to-spec = 把纪要整理成正式合同（产品/技术负责人视角）
• to-tickets = 把合同拆成带依赖的工单，agent 可并行认领

8. 安装建议

• 官方插件（Claude Code）：

• claude plugins install mattpocock-skills
  整包安装、自动更新，无法只挑几个

• 最小自洽集（只想访谈）：

• npx skills@latest add mattpocock/skills
  建议安装grilling + domain-modeling + grill-me + grill-with-docs （ setup-matt-pocock-skills 只在走 spec/tickets/tracker 流程时才需要）