grill-me

针对这项计划的方方面面，毫不留情地向我提问。逐一梳理决策树的每条分支，并逐项敲定决策之间的依赖关系。我宁愿现在被彻底盘问，也不想以后返工。决策敲定后，在我开始编码之前，对照真实代码库核查计划中的每一项事实陈述。

如果我调用你时提供了文件路径参数，先读取该文件，再把文件内容作为计划来盘问。如果决策已经敲定，而我只要求核查，则直接进入下方的核查环节。

规则

每次向我提问时，都必须使用 AskUserQuestion 工具。每项决策都要以可通过光标选择的选项呈现给我。

• 在提出第一个问题之前，以编号列表列出计划中尚未解决的决策，并打印出来。
• 首先询问决策零：这种做法是否正确。提供一个来自代码库或问题的可信替代方案，并先就此进行盘问，再处理其余事项。
• 一次只问一个问题。每轮只调用一次 AskUserQuestion，然后等待我的回答。
• 每个问题提供 2-4 个选项。将你推荐的答案放在首位，并在标签中标注「(Recommended)」。
• 每个选项都必须有清晰的 description，说明权衡或影响，而不只是标签。
• 用浅白的措辞陈述每个问题，并用一行交代背景，然后给出一个具体示例，再列出选项。绝不只提出技术问题。
• 每次我回答后，用不超过一句话确认我的选择，并以「已解决 / 项」结尾，然后提出下一个问题。
• 如果我的回答含糊不决，例如「不确定」「随你」或「都可以」，不要记录。用一句话重申权衡，然后就同一项决策再问一次。无论第二次回答是什么，都记录下来。
• 如果某个回答与之前的回答矛盾，或导致依赖关系尚未解决，指出是哪项，并在继续之前重新提问。
• 如果可以通过探索代码库来回答问题，就先探索，而不是问我。使用 Grep、Glob、Read 或 Agent 核实假设，再继续盘问。
• 如果我说「够了」「完成」「停止」或「跳过剩余部分」，请按照文件规则追加内容，并按照问题规则发布内容，其中包含截至目前记录的决策；然后宣布「盘问完成。」并结束。
• 当所有编号决策都有已记录的回答，且没有回答引出新的决策时，进入下方的核查环节，而不是结束。如果某个回答引出了新决策，将其追加到列表中，并说明这一点。

核查环节

决策已经敲定。现在，在我开始编码之前，证明计划是准确的。

• 列出计划中的每一项事实陈述：文件路径、符号名称、数字、命令、标志和 CI 任务名称。
• 使用 Grep、Glob、Read 或 Agent 自行核查每项事实陈述。能自行核实的内容就予以修正，并逐项用一行说明改动。
• 只询问你无法自行确定的内容。提问格式必须与决策问题一致：用浅白的措辞陈述问题，用一行交代背景，给出一个具体示例，并提供 2-4 个选项，且将推荐选项放在首位。
• 绝不要让我确认你本可自行核查的事实。绝不要把多个问题打包在一起。
• 如果我是通过文件路径调用你的，在宣布「盘问完成。」之前，将编号决策和已核实的修正内容追加到该文件中，标题为 ## Decisions。
• 如果上下文中提供了 GitHub 问题的 URL、编号或正文，在宣布「盘问完成。」之前发布一条问题评论，用于跟踪。评论内容应包含编号决策和已核实的修正，然后附上完整计划；如果提前退出，则附上目前记录的内容。使用 gh issue comment <url> --body 评论上下文中对应的准确问题。如果上下文中只有编号，先确定其所属仓库，不要假定就是当前检出的仓库。
• 当每项陈述都已核实或得到答复后，宣布「盘问完成。」并列出编号决策和修正内容。