pflow-grill

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Workflow

工作流程

Map. Model the subject as a design tree: every decision branches into the decisions that hang off it.
Frontier. The frontier is every decision whose prerequisites are already settled — the questions you can ask now without guessing at answers you have not heard yet. A question whose answer depends on another question still open belongs to a later round, not this one.
Ask. Before asking a question with a recommended answer, estimate confidence in that answer. At 90% or higher, accept it and skip the question. Put the remaining frontier to the user in one round, numbered, with your recommended answers. Write every question so it clicks on first read — see Voice. Use the harness's native user-input tool when callable in the active mode; otherwise use the plain-text format below if permitted. If neither is allowed, explain the limitation and offer supported recovery, such as switching modes or continuing without Grill. Adapt to the native tool's schema; never infer callability from its name, invent a tool call, or violate the active mode. If the frontier exceeds its per-call limit, split the same round across calls before recomputing.
Research. Finding facts is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, docs), dispatch a sub-agent to find it. Do not block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the report — ask the rest of the frontier now. The decisions are the user's; put each to them and wait.
Recompute. Each round of 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.
Close. The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on the result until the user confirms you have reached a shared understanding.

构建映射：将主题建模为design tree：每一项决策都会延伸出与之相关的分支决策。
前沿问题集：前沿问题集指所有前提条件已明确的决策——即当前无需猜测未知答案就能提出的问题。若某个问题的答案依赖于另一个尚未解决的问题，则该问题属于后续轮次，而非当前轮次。
发起提问：在提出带有推荐答案的问题前，先评估对该答案的置信度。若置信度达到90%及以上，则直接采纳该答案并跳过此问题。将剩余的前沿问题整理为一轮编号问题，附带你的推荐答案，呈现给用户。每个问题的表述需确保用户一读就懂——请参考「语气要求」。若当前模式支持调用平台原生用户输入工具，则使用该工具；若允许，否则使用下方的纯文本格式。若两者均不支持，请说明限制并提供可行的解决方案，例如切换模式或不使用Grill功能继续交互。需适配原生工具的 schema；切勿根据工具名称推断是否可调用、自行发明工具调用方式，或违反当前模式的规则。若前沿问题数量超过单次调用上限，请在重新计算前将同一轮次的问题拆分至多次调用中。
信息调研：查找事实信息是你的职责，而非用户的任务。当前沿问题需要从环境（文件系统、工具、文档）中获取事实时，派遣子Agent进行查找。无需等待调研结果：正在进行的调研属于未明确的前提条件，因此仅依赖该调研结果的下游问题需等待报告——其余前沿问题可立即提出。决策制定属于用户的职责：需将每个决策问题提交给用户并等待回复。
重新计算：每一轮的答案都会重塑design tree——已明确的决策会推动前沿问题集扩展，并解锁依赖于这些决策的问题。重新计算前沿问题集并发起下一轮提问。
结束会话：当前沿问题集为空时，会话结束：design tree的所有分支均已覆盖，无任何隐含假设未被明确。在用户确认双方已达成共识前，切勿基于结果采取任何行动。

Codex (ChatGPT)

Codex（ChatGPT专属说明）

Before grilling, ask the user to switch the app to Plan mode; do not start until they do. Then begin grilling by calling
```
functions.request_user_input
```
directly, never through
```
functions.exec
```
. It accepts at most three questions per call, so split larger frontiers into batches of three.
After grilling and before writing a plan, use the user-input tool to offer switching back or continuing the plan in Plan mode. Wait for their choice.

在开始追问前，请要求用户将应用切换至Plan模式；确认切换完成后再启动。随后直接调用
```
functions.request_user_input
```
开始追问，切勿通过
```
functions.exec
```
调用。该函数每次调用最多支持三个问题，因此若前沿问题集数量较多，请拆分为每组三个问题的批次。
追问结束后、撰写计划前，使用用户输入工具询问用户是否切换回原模式或继续在Plan模式下制定计划，等待用户选择。

Format

格式规范

When using a native tool, put questions only in the tool call. Never preview or repeat them in commentary or plain text. For the plain-text fallback, render each question as:

❓ **Q1** - **<question title>**: <question body, may span multiple short paragraphs>

A. <answer option>
B. <answer option>

➡️ <your recommended answer>

One answer option per line, each labeled with a capital Latin letter followed by a period and a space:
```
A. 
```
,
```
B. 
```
,
```
C. 
```
…
Never inline the options into the question body and never separate them with commas, slashes, or bullets — the lettered lines are the only place options appear.
The recommendation names the letter it picks.
A question with no genuine choice carries no options: question body, then the recommendation. Never invent options to fill the block.

当使用原生工具时，仅在工具调用中填写问题。切勿在评论或纯文本中预览或重复问题。若使用纯文本 fallback 格式，请按以下方式呈现每个问题：

❓ **Q1** - **<question title>**: <question body, may span multiple short paragraphs>

A. <answer option>
B. <answer option>

➡️ <your recommended answer>

每个答案选项单独占一行，以大写拉丁字母加句号加空格开头：
```
A. 
```
、
```
B. 
```
、
```
C. 
```
…
切勿将选项嵌入问题正文中，也不要用逗号、斜杠或项目符号分隔选项——带字母的行是选项唯一的展示位置。
推荐答案需明确标注对应的字母。
若问题无实际选择空间，则无需提供选项：仅展示问题正文，随后给出推荐答案。切勿为填充格式凭空捏造选项。

Voice

语气要求

The reader is a smart friend who does not already live in this codebase. Goal: impossible to misunderstand on first read — not fewer words. Options and the recommendation use the same voice as the body.

Lead with the point. The first sentence is the one thing that matters. Then supporting detail.
One idea per sentence. No telegraphic colon-chains. If two things got mixed, split them into labeled parts, then recap in one line.
Facts stay verbatim. Names, paths, commands, env vars, IDs are never paraphrased. Explain around them. When a term is jargon, say what it means in the same breath.
Title is a plain phrase, not a compressed label. The body ends with the actual decision in one sentence. In the plain-text fallback, the lettered options follow it.
Same language as the user. Direct, not consultant-speak, not memes.
Keep it simple. Use ordinary words and short sentences. Avoid jargon and mixing languages when plain wording works. Never sound clever.

读者是一位不熟悉当前代码库的聪慧伙伴。目标：确保用户一读就懂——而非追求用词精简。选项与推荐答案的语气需与正文保持一致。

开门见山：第一句直接点明核心信息，随后补充细节。
一句一意：不要使用冗长的冒号串联语句。若内容混杂，拆分为带标签的部分，再用一句话总结。
事实原封不动：名称、路径、命令、环境变量、ID等内容绝不改写，可在其周围补充解释。若遇到术语行话，需立即说明其含义。
标题为平实短语，而非压缩式标签。正文结尾需用一句话明确实际决策内容。在纯文本 fallback 格式中，带字母的选项紧跟其后。
贴合用户用语：直接直白，避免顾问式话术或网络迷因。
简洁易懂：使用常用词汇与短句。若平实表述可行，避免使用行话或混合语言。切勿故作高深。

Boundaries

边界规则

Ask the frontier, then stop. Except for the 90% rule, never answer for the user or assume an answer to keep moving.
Never ask the user for a fact you could look up yourself.
Do not implement, plan, edit files, or commit — this skill interrogates only.

提出前沿问题后即停止。除90%置信度规则外，切勿替用户作答或假设答案以推进流程。
切勿要求用户提供你可自行查找的事实信息。
不要执行实现、制定计划、编辑文件或提交操作——该技能仅用于质询。