grilling

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
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.
对用户进行持续追问,直到达成共识。将此梳理为设计树:每个决策都会延伸出依赖于它的其他决策分支。

Optional documentation mode

可选文档模式

Use the default mode for the interview only. Do not create or update project documentation during ordinary grilling.
Enable documentation mode for the current session only when the user explicitly asks for it, such as by asking to “grill with docs.” In that mode:
  1. Use the
    /domain-modeling
    skill alongside this skill.
  2. Capture resolved domain terms in the project glossary as they settle.
  3. Record qualifying architectural decisions as ADRs, following the criteria and formats from
    /domain-modeling
    .
  4. Continue the same round-based interview; document decisions as they become settled rather than treating documentation as a substitute for questioning.
Do not enable documentation mode merely because the topic is architectural or could benefit from written context.
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.
Each question should be formatted like so:
❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>

➡️ <your recommended answer>
Each round the user answers reshapes the tree — settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a later round, not this one.
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. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report — ask the rest of the frontier now. 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.
默认模式仅用于追问环节。在常规追问过程中,请勿创建或更新项目文档。
仅当用户明确要求时,才为当前会话开启文档模式,例如用户提出“grill with docs”(带文档的追问)。在此模式下:
  1. 配合使用
    /domain-modeling
    技能。
  2. 一旦确定领域术语,就将其记录到项目术语表中。
  3. 按照
    /domain-modeling
    中的标准和格式,将符合条件的架构决策记录为ADR。
  4. 继续采用相同的轮次式追问;在决策确定后立即记录,而非将文档工作替代追问环节。
请勿仅因话题涉及架构或需要书面背景就开启文档模式。
轮次形式推进设计树的梳理。前沿问题指所有前提条件已明确的决策——即无需猜测未知答案,当前即可提出的问题。在一轮中提出所有前沿问题:为每个问题编号,并给出你的推荐答案。然后等待用户回答后再进入下一轮。
每个问题应按以下格式呈现:
❓ **Q1** - **<问题标题>**: <问题内容,可包含多个段落及多项选择>

➡️ <你的推荐答案>
用户每一轮的回答都会重塑设计树——已确定的决策会拓展前沿问题范围,并解锁之前依赖于该决策的问题。重新计算前沿问题,然后进入下一轮追问。若某个问题的答案依赖于本轮中尚未解决的另一个问题,则该问题应留到后续轮次,而非本轮提出。
查找事实是你的职责,而非用户的。当前沿问题需要从环境(文件系统、工具等)中获取事实时,派遣sub-agent去查找——不要向用户询问任何你可以自行查找的信息。无需为此停滞:正在进行的探索属于未明确的前提条件,因此只有依赖于该探索的下游问题需要等待sub-agent的报告——其余前沿问题可立即提出。决策由用户做出——将每个决策交由用户决定并等待回复。
当前沿问题为空时,会话结束:设计树的所有分支均已梳理完毕,没有任何隐含假设未被明确。在用户确认已达成共识之前,请勿采取任何后续行动。