菜单
在 Shape 已经形成候选方向，或用户带着现有计划、设计、提案和决定，要求拷问、挑战、压力测试、补齐隐含决定或确认是否足以继续时使用。把对象展开成有依赖关系的决策树，按当前前沿分轮提出多个问题，让用户对推荐选项作出裁决。开放探索和生成方向由 shape 负责；所有者缺席时对成文产物做独立检查由 review 负责。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
在用户需要真正理解任何非平凡对象时使用，包括需求、计划、设计、代码、diff、分支、评审结论、测试结果、故障、进行中的方向或已完成成果。读取对象本身和必要上下文，为没有读过当前对象的读者写成连续、自包含、能检查证据并继续判断的 Walkthrough；它可以发生在工作前、中、后任何位置，不用摘要、文件清单或术语堆叠冒充理解。
在用户明确要求实现功能、修改代码、修复缺陷、落实已确认的评审问题，或执行范围明确的重构与迁移时使用。进入真实代码，沿行为或错误路径追到局部根因，用贴近变化的证据确认结果，交付可审查的代码变化。方向或关键结构还没定、用户只要求诊断，或根因会改变任务承诺、公共契约、数据所有权或关键系统形态时交给 shape；独立 review、完整测试或单纯解释不由本 Skill 承担。
在非平凡任务自然收尾时判断是否存在可复用经验，或在 Skill、提示词与长期规则出现可重放的触发、执行、边界或成本偏差时使用。沿真实轨迹决定经验是否值得改变未来，以及应进入哪个最窄作用域；行为性 Skill 变化需要证据和用户批准，没有经验时不制造产物。
仅在用户显式调用 `$prompt` 时使用。结合真实任务、输出和用户反馈，帮助用户看清表达与上下文怎样影响了结果。先调查再提纯；如果真正需要改变的是方向、时间线或长期能力，转入 shape、rewind 或 evolution，不把所有问题都改写成提示词。
对需求、设计、计划、代码、diff、MR 或交付物做独立冷读，从当前 Task Context 锁定 scope、Git baseline 与 Task Operating Envelope，检查行为风险、变更纪律、架构维护，以及决定授权、专业产物、实现和 Task Runtime 状态是否一致，并在报告前独立证伪每个 finding。用于实现 Phase 完成后的轻量审查、最终综合审查、用户要求 review、判断 MR/方案能否前进、检查修复是否优雅而非 hack、寻找隐藏风险，或重要产物需要在测试、合并或交付前接受独立压力时。用户明确要求直接实现或修复、没有可审查对象、只需解释现状，或为了"更严格"给小改动制造评审团时不要触发。
在长程、多轮和多分支任务中主动检查当前对话与任务状态是否还可信。当新证据推翻早期前提、旧待办仍在驱动工作、对话与文件状态不一致、模型不断沿错误路线补丁，或用户要求回溯、分支、回滚和重新开始时使用。需要恢复时说明错误影响到哪里、应回到什么状态、保留什么，并给出可直接粘贴的新提示词。
基于 SOC 职业分类
| name | grill |
| description | 在 Shape 已经形成候选方向，或用户带着现有计划、设计、提案和决定，要求拷问、挑战、压力测试、补齐隐含决定或确认是否足以继续时使用。把对象展开成有依赖关系的决策树，按当前前沿分轮提出多个问题，让用户对推荐选项作出裁决。开放探索和生成方向由 shape 负责；所有者缺席时对成文产物做独立检查由 review 负责。 |
把已经成形的方向放到用户面前经受压力。Grill 不替用户发明目标，也不审批方案；它让尚未说出口的决定、假设和代价显形，直到双方对准备继续的对象有共同理解。
输入必须是一个已经能描述的方向、计划、设计、提案或决定。只有模糊意图、还没有候选形状时，先交给 shape；有成文产物但所有者不参与回答时，交给 review。
先读取相关代码、文档、运行证据和当前 Active Task。能够自行查到的事实先查，不把项目功课问回用户。Grill 只向用户追问价值、偏好、风险接受、授权和其他必须由责任人裁决的事项。
在内部把对象展开成决策树：一个决定下面只挂真正依赖它的后续决定。只纳入会改变目标、范围、可观察行为、完成证据、不可逆代价或重要取舍的分支，不为理论上的所有可能制造问卷。
当前前沿是所有前提已经确定、现在可以在不猜测其他答案的情况下裁决的节点。事实调查尚未完成时，只有依赖该事实的分支等待；其他已经成熟的前沿问题继续推进。
每一轮提出当前前沿中能够一起回答的问题，而不是机械地一次一问，也不是把整棵树一次倒完。问题很多时按同一父决定拆成容易回答的组；互相依赖的问题绝不放在同一轮。
每个问题都要：
等用户回答后，把答案折回决策树，说明它确定了什么、暴露了什么，再重新计算下一轮前沿。用户只回答一部分时先吸收已回答项，其余保持开放，不把推荐当成默认同意。
用户提出问题或表示没看懂时先解释；问题本身不是答案，只有明确选择才折回决策树。
区分回答和决定。用户明确选择、且该选择会约束后续价值、范围、风险或取舍时，把它记为 UD candidate；普通反馈、追问和暂时倾向不升级。候选与当前 Active Task 的 UD-* 冲突时，单独指出“保留旧决定”和“用新决定替换”的后果，明确询问是否 supersede，不能用新回答默默覆盖旧决定。
压力应落在当前最薄弱的地方，例如：目标是否真实、成功怎样观察、哪个相邻问题明确不做、哪个事实为假会推翻方向、有没有更小的办法、失败是否可撤销、依赖和验证是否成立。不要为了显得严谨把这些角度全部问一遍。
“我不知道”是一条有效发现。把它变成有名字的未知，并给出取得证据、做低成本实验、接受显式假设或返回 Shape 的具体路径。
当前沿为空、剩余问题不再改变承诺，或用户要求停止时，交回一份简洁结论：
UD candidate 应交给 shape 写入 Task Context，以及它们是否替换现有 UD-*；shape 修订方向或 Task Context。Grill 默认只交付对话和这份结论，不另建平行状态文件。已有 Active Task 时，UD candidate、范围或承诺变化仍由 shape 在用户同意后通过 longrein task context --decision 写入 Runtime；Grill 不分配正式 UD-*，不直接编辑 task.md，也不能自行增加 scope_revision。用户确认达到共同理解前，不依据被拷问的对象开始实现。
Shape 让可能的方向显形；Grill 让一个已有方向经受所有者当场裁决；Review 在不依赖作者回答的情况下独立检查产物。Grill 不是每个任务的固定阶段，也不能用一场顺利访谈代替设计、评审、测试或批准。