grill-me

Grill Me

对请求进行压力测试，直到其中的重要决策在受影响的流程中彼此协调一致。调查事实，质疑站不住脚的回答，并将具体契约和坦诚说明的未解决问题带入执行上下文。

阅读时机

• 要确定受影响的用户流程或可见操作？在提出选项前，先打开 user-experience.md。根据预期结果和现有产品推断常规细节；只询问重要的权衡。纯后端工作可跳过此项。
• 准备推荐答案？打开 code-quality.md 和 code-structure.md。跳过它们，你就会推荐规则禁止的选项。
• 每次运行：打开 doctrine.md、execution context，以及 writing-style.md 中的 Asking the user 和 Plain language 部分。跳过它们，你就会把 Questions 和 Locked in 混在一起，或询问仓库中已有答案的问题。

流程

1. 根据需求以及重新发现的仓库、工单、PR 或差异信息，在聊天中建立或刷新精简的执行上下文。如果上级已经提供了结果、当前范围、非目标、所属领域以及工单/PR，就复用该简报。仅重新说明发生变化或尚未说明的事实或用户决定。在检验解决方案选项之前，用自己的话展示 doctrine 中的意图重述，每个要点用一条简短的英文项目符号。如果上级现有的重述已符合要求，就复用。
2. 根据 doctrine 的重要性标准，区分调研所得事实、已确定的决定、普通实现选择和尚未解决的重要权衡。调查事实空缺，并复用上级的决定。依据证据和适用的质量与结构规则推导普通实现细节；不要把它们变成访谈问题。
3. 如果上级是 /write-ticket，就聚焦于工单准备相关主题。提出会影响行为、数据、契约、交付边界、依赖项和权限的重要选择。上级会根据已确定的选择推导子项数量、顺序和文件分工。
4. 使用 doctrine 中的决策轮次梳理选择及其前置条件。如果仍有重要且由用户决定的选择，就发送一批仅包含问题的内容（不要加“已锁定”标题）。每个问题都要说明一个具体选择、相关证据或不确定性、现实可行的选项、带理由的建议以及实际影响。遵循决策依赖关系，并提出现在可以回答的独立问题。等待回复。
5. 将答案、理由、必须遵守的规则、修正内容以及调研确认的归属路径直接写入执行上下文。遇到答案不完整、前后矛盾或新出现的重要权衡时，再提出一批问题。遵循答案压力；提到某个主题或给出建议，并不意味着决定已确定。模板中缺少类别不构成再次访谈的理由。
6. 对受影响的流程执行就绪检查。遵循暂停、延期和停止，不要声称尚未解决的工作已就绪。重要问题都已解决后，在一条单独的、仅用于宣布的消息中宣布已锁定（如有错误请告诉我）。其中应包含有意义的非目标、推导出的拆分方案以及共同理解。逐行写出修正后的意图重述，保留当前决定及其理由，并删除已被取代的内容。如果上级现有的锁定内容已涵盖这些决定，就复用。
7. 仅在“已锁定”消息发出后，并且每条相关规则都有明确的执行负责人和验证负责人时，才制定计划。

在聊天中保留语言、选择、规则和进度。如果用户需要持久化文档，请在共享的可选持久化规则下询问或遵循获批的存放位置。

如果上级已负责下一步

遵循嵌套能力。仅向上级返回变更的决定、其理由以及仍然存在的重要空缺。下一步由上级负责；/write-ticket 负责完成工单，选定的执行技能继续当前生命周期。

如果这是用户的一次性请求

除非用户明确要求下一步，否则在达成共同理解后停止。对于获准的构建任务，使用 AGENTS.md 中的 Skills 表格：

• 需要梳理结构：先运行 /analyze，再运行选定的执行技能。
• 已准备好构建：默认使用 /task-with-tests；如果用户明确要求使用命令或不需要测试，则使用 /task。携带已确定的决定以及被拒绝的测试方案。