企业官网建设流程全解析

LifeOS grill-me 命令解析：用查问式发现访谈把半成型想法打磨成可验证的 ISA

【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS

grill-me是 LifeOS（意图工程平台，LifeOS 系统由 install 目录 下的技能、命令、钩子与工具共同构成）内置的一条 Claude Code 斜杠命令（slash command），它将一个尚未成型、只有模糊轮廓的想法，通过"一次一问"的查问式发现访谈（discovery interview）逐步逼出其真实形状，最终生成一份结构完整、可直接交底的 ISA（Ideal State Artifact）草案。读完本文，你将掌握 grill-me 的调用方式、Grill 工作流的完整执行流程（含每轮 checkpoint 机制、pre-mortem→ISC 转换与 Scaffold 交接），以及它和 Interview 工作流的本质区别。

命令本体：一条极简的路由器

命令的完整定义位于仓库的 LifeOS/install/commands/grill-me.md。和tm、lu、cs等命令一样，它是一个带 YAML frontmatter 的 Markdown 文件，frontmatter 携带命令的元数据：

--- name: grill-me description: Relentless checkpointed discovery interview that interrogates a half-formed idea until its shape is clear, then hands off to ISA Scaffold. Routes to the ISA skill's Grill workflow. USE WHEN /grill-me, grill me, discovery interview, figure out the shape, brainstorm before scaffolding an ISA. NOT FOR filling an existing ISA's thin sections (use ISA Interview). argument-hint: <topic> [slug] ---

逐字段解读：

• name：命令名，安装后在对话中通过/grill-me触发；
• description：命令的语义边界，明确声明USE WHEN（何时用）与NOT FOR（何时不用）——它专门用于"scaffold 之前的头脑风暴"，绝不用于填充已有 ISA 的薄弱章节；
• argument-hint：参数格式<topic> [slug]——topic是要被拷问的想法/计划/决策，slug可选，用于指定写入的 WORK 目录。

命令体本身是一个极简路由器：把$ARGUMENTS原样交给 ISA 技能的 Grill 工作流，并在参数为空时先询问用户想拷问什么想法：

Skill("ISA", "grill me on $ARGUMENTS")

如果$ARGUMENTS为空，先询问要拷问的想法/计划/决策，再继续。

这种"命令文件 → 技能工作流"的委托模式是 LifeOS 命令家族的通用设计（可对比 tm.md 将$ARGUMENTS委托给 Teach 技能的 Teach 工作流）：命令层保持薄，真正的流程逻辑沉淀在技能的Workflows/目录，便于跨会话复用与单独演进。

为什么需要 Grill：从"雾"到可验证的"形状"

要理解 Grill，必须先理解 ISA 的定位。在 LifeOS 中，ISA 是描述"任何事物（项目、应用、库、基础设施、工作会话、艺术创作、战略决策）的 done 状态"的单一文档，同时承担五种身份：理想状态表述、测试装置、构建验证、完成条件、系统记录（system of record）。但 ISA 的前提是——你得先知道自己在追求什么。

绝大多数工作的真实起点并不是清晰的规格，而是一团"fog"（雾）：在范围内的、你尚无法精确陈述的问题。ISA 技能对这种状态有一条明确的"毕业测试"（graduation test，v2.14.0）：

• 现在就能精确陈述问题、并指出可命名的证伪者 → 可以直接写成 ISC（即使暂时被阻塞）；
• 可陈述但尚不可探测 → 留在雾中（## Not yet specified）；
• 超出愿景 → 划入 Out of Scope。

Grill 正是处理"雾"的机制：它不急于把雾变成 ISC，而是通过结构化提问把雾逼成一个可被 Scaffold 接管的、hard-to-vary（难以变动）的提示词。正如 Grill.md 开篇所定义：

Relentless, checkpointed discovery interview that interrogates a half-formed idea until its shape is clear, then hands off to Scaffold to build the ISA. Where Interview FILLS a known ISA structure, Grill DISCOVERS a structure that doesn't exist yet. Human-invoked and exploratory; never Algorithm-automatic.

一句话概括两者分工：Interview 填充已知结构，Grill 发现尚不存在的结构。

何时调用 Grill

Grill 是人类主动调用的工作流，永远不会被 Algorithm 自动触发。典型场景：

• 用户直接发起：Skill("ISA", "grill me on <topic>")或/grill-me <topic>；
• 在 Scaffold 之前，当想法过于未成形、不足以直接 scaffold 出强 ISA 时；
• 刷新规格："grill me again on <slug>, here's new findings."——带着新发现重新拷问已有 slug。

明确不适用的场景是填充已有 ISA 的薄弱章节——那是 Interview 的职责（详见下文对比）。

输入参数

注意slug的语义：它决定 Gril 的 checkpoint 文件写入哪个 WORK 目录，也与后续 Scaffold 写出的 ISA 文件位置保持一致，从而保证"拷问 → 脚手架"两阶段落盘在同一目录。

完整执行流程（8 步）

Grill 工作流在 LifeOS/install/skills/ISA/Workflows/Grill.md 中完整定义。与 ISA 技能下的其他工作流（Scaffold、Interview、CheckCompleteness、Reconcile、Seed、Append）一样，它由八个可复现的步骤构成。

Step 1 — 语音通知

所有 ISA 技能工作流的第一步都是强制语音通知（SKILL.md中标注 "This is not optional"），通过本地 notify 端点异步发送：

curl -s -X POST http://localhost:31337/notify \ -H "Content-Type: application/json" \ -d '{"message": "Running the Grill workflow in the ISA skill"}' \ > /dev/null 2>&1 &

同时在对话中输出文本通知："Running theGrillworkflow in theISAskill to ..."。这一机制让用户在语音/桌面通知层面感知到工作流已启动。

Step 2 — 确立 WORK 目录

Grill 的落盘路径是绝对路径~/.claude/LIFEOS/MEMORY/WORK/{slug}/，而不是项目相对路径。工作流明确警告了两个常见错误：

• 它不是项目相对路径——即使从其他仓库的 cwd 发起/grill-me，也要写到 LIFEOS 的固定位置；
• 它不是~/.claude/MEMORY/WORK/（少了LIFEOS/树）这类裸路径。

选择这个路径的根本原因：它是 Scaffold 写出 ISA 的同一目录（Scaffold 无项目时写MEMORY/WORK/{slug}/ISA.md），交接因此天然共址。在该目录创建grill.md，包含三个小节：Shape & Key Decisions、Q&A Log、Open Flags。该文件是每轮 checkpoint 的目标，绝不是项目根目录下的临时brainstorms/文件夹。

Step 3 — Shape check（仅在类别含糊时）

如果还不清楚这是"哪一种东西"（skill / hook / CLI / 文档……），先提出 2–3 个候选形态，用判别性问题在开走设计树之前先剪枝到一个。形状显而易见时跳过此步。

Step 4 — 走设计树

这是流程的核心。Grill 按依赖顺序解决决策——绝不先于其父节点处理叶子节点。每一轮决策遵循四条纪律：

1. 一次只问一个问题：通过AskUserQuestion提问，一次调用只问一个问题，绝不批量。每个问题把你的推荐答案作为第一个选项（标记(Recommended)），旁边放真实备选，用户一次确认或推翻；也可以选 "Other" 重定向。只有答案空间真正开放、无法收敛为选项时才退化为自由文本问题。
2. 绝不做裸开放提问：永远先亮出你会怎么落、为什么。
3. 能查代码就不问：答案可从代码库中发现时，先用 Grep/Read 探索代码，只有代码回答不了才提问。
4. 低置信或高风险的决策：在用户回答前，附一行你对自己推荐的"最强反对意见"（strongest objection）。

Step 5 — 每轮之后立即 checkpoint

每轮问答结束，立即写grill.md：把问答对追加进 Q&A Log，把已定案的决策提升进 Shape & Key Decisions，把"需要外部输入"的项目记入 Open Flags。checkpoint 的意义在长会话中尤其重要——它保证即使上下文窗口退化，工作产物也完整落在磁盘上。

Step 6 — Pre-mortem → 草拟 ISC

收尾之前强制跑一轮失败模式审查："假设这个东西已经上线并失败了——哪里出了问题？"把每个失败模式转化为一条草稿级二元标准（ISC），写入 Shape & Key Decisions。这正是让最终 ISA "hard-to-vary"的关键机制：预先把"什么会让它失败"钉进标准里，而不是事后补救。

Step 7 — 停止条件

满足以下任一条件即结束：

• 形状已经清晰到足以 scaffold；
• 达到max_questions（默认 12）；
• 连续两个回答是低信号（"我不知道"/"跳过"）。

Step 8 — 交接（Handoff）

按顺序提供三个出口：

1. 交给 Scaffold：Skill("ISA", "scaffold from prompt: <Shape & Key Decisions + draft ISCs from grill.md>")，目标仍是同一个 WORK 目录；
2. 为每个 Open Flag 创建任务（TaskCreate）；
3. 通过 CreateSkill 同步本次会话触碰的相关技能/指南——注意，这是 Grill 的职责，不是 Interview 的。

grill.md 输出格式

Grill 的交付物grill.md有固定模板：

# Grill: <topic> ## Shape & Key Decisions - <settled decision> — <rationale> - ISC: <binary criterion from pre-mortem> ## Q&A Log ### Q1: <question> **Recommended:** <rec> **Answer:** <user answer> ## Open Flags - [ ] <unknown> — needs <who/what>

三个小节的职责边界清晰：Shape & Key Decisions记录已定案决策及其理由、以及 pre-mortem 产出的草稿 ISC；Q&A Log是完整问答流水，保留(Recommended)与用户实际选择的对照；Open Flags记录尚未解决、需要特定角色/信息输入的事项。这份文件既是过程审计轨迹，又是 Scaffold 的直接输入。

失败模式与处理

Grill 工作流预先定义了三个高发失败模式及其处理策略：

第三条尤其重要：Grill 的价值是发现，不是仪式。已成型的主题直接跳过拷问进入构建，是流程认可的正路。

与 Scaffold 的交接：为什么 prompt 即协议

Scaffold 没有专门的 grill 模式——交接物就是 grill.md 的内容本身。流程是：把 Shape & Key Decisions（连同 pre-mortem 草稿 ISC）作为Skill("ISA", "scaffold from prompt: …")的 prompt 传入。

从 Scaffold.md 的实现细节可以理解这一交接为何有效：

• 目标保留：Scaffold 的 Step 3 有专门的"principal-stated goal"保留机制——用四信号检测器（命名指标+阈值、显式结果断言、完成条件、结构/设计指令）从 prompt 中识别用户的字面目标，逐字节写进 frontmatter 的principal_stated_goal，并作为## Goal的首句引语原样保留，之后才派生其他内容；
• 派生结构：显式想要→Vision，显式不想要→Out of Scope，领域隐含约束→Constraints，TELOS 隐含原则→Principles；
• 草稿 ISC 落地：Grill 的 pre-mortem 草稿 ISC 会直接进入新 ISA 的 claims 区（新 ISA 是## Claims，旧版兼容## Criteria）；
• 共址落盘：Scaffold 无项目时同样写~/.claude/LIFEOS/MEMORY/WORK/{slug}/ISA.md，与grill.md同目录。

用 Grill.md 的话说：Grill 的价值在于把发现工作前置，让交给 Scaffold 的 prompt 一开始就难以变动（hard-to-vary）。之后 Scaffold 还会对产物运行 Splitting Test（每个 claim 必须对应单一二元工具探针）、anti-claim 检查、以及 substance 缩放的完整性门控（详见 CheckCompleteness.md），最终经 CheckCompleteness 打分通过后才返回路径。

Grill 与 Interview：发现 vs 填充

两者是 ISA 技能中极易混淆的一对，这里给出可直接引用的判别表（来源：SKILL.md 的 Workflow Routing 与两份工作流文档）：

从路由表可见，ISA 技能的七条工作流（Scaffold / Interview / Grill / CheckCompleteness / Reconcile / Seed / Append）各司其职：Scaffold 负责从 prompt 生成、Interview 深化、Grill 发现形状、CheckCompleteness 打分、Reconcile 确定性合并 ephemeral 特性文件、Seed 从既有仓库反向引导、Append 记录决策与学习条目。Grill 处于整条流水线的最前端——它是把"我不知道我要什么"变成"我知道 done 长什么样"的第一道工序。

值得注意的实现约束

从 Grill.md 与 ISA 技能整体可以提炼几条对使用者有实际影响的约束：

1. checkpoint 目标路径是硬编码约定：~/.claude/LIFEOS/MEMORY/WORK/{slug}/grill.md是唯一合法 checkpoint 目标，工作流明确禁止改用项目根目录的brainstorms/文件夹——这保证了跨仓库、跨会话的可恢复性；
2. 一次一问是硬规则：AskUserQuestion单次调用只问一个问题，批量提问违反流程；推荐答案必须作为首选项出现，让用户"确认或推翻"而非从零作答；
3. ISC 草稿必须是二元标准：pre-mortem 产出的每条 ISC 要能对应"单一二元工具探针"（与 Scaffold 的 Splitting Test 一致），这正是 ISA 体系中 ISC 的粒度铁律（CheckCompleteness.md 中 granularity 检查会审计这一点）；
4. 来自开源社区的血统：Grill 工作流改编自 Matt Pocock 的grilling/grill-me技能（MIT 协议），但做了两处独立实现：每轮 checkpoint 到MEMORY/WORK/{slug}/grill.md（而非项目根目录的brainstorms/文件夹），并在 Scaffold 交接前增加了 pre-mortem→ISC 转换环节。

深入阅读路径

• 命令定义：LifeOS/install/commands/grill-me.md
• Grill 工作流全文：LifeOS/install/skills/ISA/Workflows/Grill.md
• 接口对照：Interview 工作流 LifeOS/install/skills/ISA/Workflows/Interview.md、Scaffold 工作流 LifeOS/install/skills/ISA/Workflows/Scaffold.md、CheckCompleteness 工作流 LifeOS/install/skills/ISA/Workflows/CheckCompleteness.md
• ISA 技能总纲（十七节正文、完整门控、全部 gotchas）：LifeOS/install/skills/ISA/SKILL.md
• 参考范本（Scaffold 前必读）：LifeOS/install/skills/ISA/Examples/canonical-isa.md
• 系统架构与格式规范：LifeOS/install/LIFEOS/DOCUMENTATION/ISA/ISASystem.md 与 LifeOS/install/LIFEOS/DOCUMENTATION/ISA/ISAFormat.md

实际使用中，grill-me的价值在于把"头脑风暴"从无序聊天升级为有审计轨迹、有停止条件、有明确产物交接的工程化流程：每一次提问都有推荐答案、每一轮决策都落盘、每一个失败模式都提前转成可探测的 ISC，最终让 Scaffold 拿到的不是一段含糊的闲聊，而是一份已经难以上下变动的规格 prompt。

【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS