grill-me-auto

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Grill Me Auto

Grill Me Auto

Batch-mode fork of
grill-me
: same relentless stress test, but every question is written into one markdown grill document so the user can read, collapse/expand, and answer in one shot.
Use this skill for
/grill-me-auto
,
/Grill Me Auto
,
/grill me auto
, "auto grill", or requests for all grill questions at once. If the user wants a live one-question-at-a-time interview, redirect to
/grill-me
. If they want engineering-only grilling against
CONTEXT.md
/ ADRs, redirect to
/domain-grill
.
grill-me
技能(详见
../grill-me/SKILL.md
)的批量模式分支:同样是严苛的压力测试,但所有问题都会写入一个Markdown grill文档,用户可以一次性阅读、折叠/展开并作答。
当用户使用
/grill-me-auto
/Grill Me Auto
/grill me auto
命令,或是请求“auto grill”、“一次性获取所有 grill 问题”时,使用本技能。如果用户需要实时的一对一问答形式的访谈,请引导至
/grill-me
。如果用户需要针对
CONTEXT.md
或ADRs的纯工程类 grill 测试,请引导至
/domain-grill

Step 0 — choose depth first

步骤0 — 先选择测试深度

If the invocation includes a recognized depth (see the table in
REFERENCE.md
for accepted values and aliases), echo it in one line and proceed. Otherwise, ask exactly this and stop:
Grill depth? (default: deep)
  • deep — every branch, edge case, contradiction, code/doc cross-check, and invented boundary scenario. Typically 20–40+ questions.
  • standard — critical assumptions plus main edge cases and obvious cross-checks. Typically 15–25 questions.
  • quick — only highest-leverage deal-breakers and dead-on-arrival risks. Typically 5–10 questions.
Reply with
deep
/
standard
/
quick
(or hit return for deep). Pre-select next time with
/grill-me-auto deep|standard|quick
.
如果调用指令中包含已识别的深度值(可查看
REFERENCE.md
中的表格获取可接受的值及别名),则在一行中回显该值并继续操作。否则,严格按照以下内容询问用户并停止后续操作:
测试深度?(默认:deep
  • deep — 覆盖所有分支、边缘情况、矛盾点、代码/文档交叉校验,以及预设的边界场景。通常包含20–40+个问题。
  • standard — 聚焦关键假设、主要边缘情况及明显的交叉校验点。通常包含15–25个问题。
  • quick — 仅覆盖最高优先级的致命问题及直接否决的风险点。通常包含5–10个问题。
回复
deep
/
standard
/
quick
(或直接回车选择deep)。下次可通过
/grill-me-auto deep|standard|quick
直接指定深度。

Step 1 — gather context silently

步骤1 — 静默收集上下文

Inspect the prompt, linked artifacts, touched files, repo instructions,
CONTEXT.md
, ADRs, docs, and recent commits before writing questions. Do not ask the user anything the agent can read. Mention blockers only if needed.
在编写问题前,检查提示信息、关联工件、涉及文件、仓库说明、
CONTEXT.md
、ADRs、文档及最近的提交记录。不要询问任何Agent可以自行读取到的信息。仅在必要时提及存在的障碍。

Step 2 — write the grill document

步骤2 — 编写grill文档

Resolve the project root with
git rev-parse --show-toplevel
, falling back to an ancestor with
.git
/
.claude
, then
pwd
. Create the document atomically (
.tmp
then rename) at the path defined in
REFERENCE.md
§ File contract
. Create
.grills/
if missing; if it is not gitignored, append
/.grills/
to
.gitignore
and stage that one-line change (do not commit).
Follow
REFERENCE.md
for every format contract — file path, frontmatter, question block, answer key, reply parsing.
templates/grill-doc.template.md
is the only filled example; do not inline another one here or in
README.md
.
通过
git rev-parse --show-toplevel
确定项目根目录,若失败则查找包含
.git
/
.claude
的父目录,最后使用
pwd
获取当前目录。按照
REFERENCE.md
中定义的路径,以原子方式创建文档(先创建
.tmp
临时文件再重命名)。如果
.grills/
目录不存在则创建;若该目录未被git忽略,则在
.gitignore
中添加
/.grills/
并暂存这一行更改(无需提交)。
严格遵循
REFERENCE.md
中的所有格式约定——文件路径、前置信息、问题块、答案密钥、回复解析规则。
templates/grill-doc.template.md
是唯一可用的填充示例,请勿在本文档或
README.md
中嵌入其他示例。

Precision pass — apply before writing

精准度校验 — 编写前执行

Before serializing the document to disk, internally apply
precision-mode
to every authored string: question text, Why it matters lines, option labels, recommendation reasons, and alt reasons. The grill doc is the only deliverable, so density of the prose inside it is the deliverable.
Implicit invocation rules:
  • If
    precision-mode
    is listed in the environment's available skills, invoke it before drafting question prose; if not, apply the same rules inline from memory (lead with the answer, no filler, no echo, no trailing summary, fragments over sentences when unambiguous, quantify don't qualify, prefer structure over prose).
  • Apply precision only to the authored content of questions, options, recommendations, and alt reasons. Do not strip the literal markdown scaffolding the format contract requires:
    <details>
    /
    <summary>
    tags, the
    **Why it matters:**
    /
    **Options:**
    /
    **Recommendation:**
    /
    **Alt:**
    labels, the
    ## Questions
    TOC heading, the
    ## Answer key
    heading, frontmatter keys, or the three reply-path code blocks. Those are contract, not prose.
  • Caps that override the precision instinct to compress further:
    Why it matters
    stays ≤1 sentence (≤20 words); option labels stay ≤15 words; recommendation and alt reasons stay ≤25 words. If a reason genuinely needs more, split into two sentences — do not drop the why to hit the cap.
  • Preserve correctness and critical caveats. Precision must not strip a security warning, breaking-change flag, data-loss risk, or a specific code/ADR reference that gives the recommendation its grip.
  • Never let precision delete the alt recommendation to "lead with the answer". The dual recommendation + alt structure is contract.
Briefly mention in the hand-off message (Step 3) that the doc was written under precision mode, so the user knows scannability is intentional and reasons are not truncated by accident.
在将文档序列化到磁盘前,对所有编写的内容(问题文本、Why it matters行、选项标签、推荐理由及备选理由)内部应用
precision-mode
。grill文档是唯一交付物,因此文档内的文字密度至关重要。
隐式调用规则:
  • 如果环境的可用技能列表中包含
    precision-mode
    ,则在起草问题文本前调用该技能;若未包含,则从内存中直接应用相同规则(先给出答案,无冗余内容,无重复表述,无结尾总结,在语义明确时优先使用短句而非完整句子,用量化描述替代定性描述,优先结构化而非散文式表达)。
  • 仅对问题、选项、推荐及备选理由的原创内容应用精准度规则。请勿删除格式约定要求的Markdown框架字面内容:
    <details>
    /
    <summary>
    标签、
    **Why it matters:**
    /
    **Options:**
    /
    **Recommendation:**
    /
    **Alt:**
    标签、
    ## Questions
    目录标题、
    ## Answer key
    标题、前置信息键,以及三个回复路径代码块。这些属于约定内容,而非散文文本。
  • 以下限制优先于进一步压缩的精准度本能:
    Why it matters
    部分不超过1句话(≤20个单词);选项标签不超过15个单词;推荐及备选理由不超过25个单词。若某个理由确实需要更多内容,可拆分为两句话——不要为了满足字数限制而删除原因说明。
  • 保留正确性及关键警告信息。精准度处理不得删除安全警告、破坏性变更标记、数据丢失风险,或是赋予推荐可靠性的特定代码/ADR引用。
  • 切勿为了“先给出答案”而删除备选推荐内容。推荐+备选的双重结构是约定要求。
在步骤3的交接消息中简要提及文档是在精准模式下编写的,让用户知道内容的易扫描性是有意设计的,理由并非被随意截断。

Step 3 — hand off and stop

步骤3 — 交接并停止操作

After writing the file, reply only with:
Grill written to
.grills/<filename>
<N> questions at depth <depth>, written under precision mode (terse on purpose; reasons capped, not truncated). Open it in a markdown previewer, then paste one of:
accept all my recommendations
,
accept all my alt recommendations
, or the filled answer-key block. I'll apply your answers in one pass when you reply.
Do not summarize the questions in chat. The document is the deliverable.
文件编写完成后,仅回复以下内容:
Grill文档已写入
.grills/<filename>
— 共**<N>个问题,测试深度为<depth>**,文档在精准模式下编写(刻意精简;理由已限制字数,未被截断)。请在Markdown预览器中打开文档,然后粘贴以下内容之一:
accept all my recommendations
accept all my alt recommendations
,或填写完整的答案密钥块。当您回复后,我将一次性应用您的答案。
请勿在聊天中总结问题。文档是唯一交付物。

Step 4 — when the user replies

步骤4 — 用户回复时的处理

Parse the shortcut or answer-key block in one pass. If malformed, ask one targeted fix-up question, not a new grill.
After parsing:
  1. Update the grill document frontmatter to
    status: answered
    , append
    answered_at
    , and add
    ## Resolved answers
    at the bottom.
  2. Summarize the resolved plan in ≤10 bullets, flagging any answer that changed direction from the original prompt with
    (changed:)
    .
  3. Ask before starting the next step; do not implement automatically.

Forked from
grill-me
, itself a fork of Matt Pocock's
grill-me
. Matt's relentless-interview core remains; this fork adds batch document delivery.
一次性解析快捷指令或答案密钥块。若格式有误,仅询问一个针对性的修正问题,而非重新生成grill文档。
解析完成后:
  1. 将grill文档的前置信息更新为
    status: answered
    ,添加
    answered_at
    字段,并在文档底部新增
    ## Resolved answers
    章节。
  2. 用不超过10条要点总结已确定的方案,对任何与原始提示方向不同的答案标记
    (changed:)
  3. 在开始下一步操作前询问用户;请勿自动执行。

基于
grill-me
分支开发,而
grill-me
本身是Matt Pocock的
grill-me
的分支。Matt提出的严苛访谈核心功能得以保留;本分支新增了批量文档交付功能。