Examine a plan, decision, or idea through rounds of questions with recommended answers. Each response reveals the next decisions to discuss, helping clarify assumptions and build a shared understanding before taking action.
围绕计划、decision 或 idea 持续追问用户。适用于用户想对自己的思路做压力测试，或使用任何 “grill” 触发措辞时。
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
持续访谈用户，直到达成共同理解。把这件事映射成一棵 design tree：每个 decision 都分支到挂在它下面的那些 decisions。
按 rounds 逐轮处理这棵树。frontier 是那些 prerequisites 已经敲定的 decisions，也就是你现在就可以问、无需猜测还没听到的答案的那些问题。在一轮里问完整条 frontier：给每个问题编号并附上你的推荐答案。然后等用户回答，再进入下一轮。
每一轮的格式如下:
❓ **Q1** - **<问题标题>**：<问题正文，可能有多段，包括多个选项>
➡️ <你的推荐答案>
---
❓ **Q2** - **<问题标题>**：<问题正文，可能有多段，包括多个选项>
➡️ <你的推荐答案>
每一轮用户给出的回答都会重塑这棵树：敲定的 decisions 会把 frontier 向外推，并解锁依赖它们的问题。重新计算 frontier，然后问下一轮。其答案依赖本轮中另一个仍未解决的问题，属于 更晚的 一轮，而不是本轮。
寻找 facts 是你的工作，绝不是用户的。当一个 frontier 问题需要来自 environment（filesystem、tools 等）的 fact 时，派一个 sub-agent 去查，不要问用户任何你自己能查到的东西。不要被它阻塞：一次正在进行的探索是一个尚未敲定的 prerequisite，所以只有它下游的问题才需要等 sub-agent 回报，现在先问 frontier 的其余部分。decisions 属于用户：逐个交给他，并等待。
当 frontier 为空时，会话才算结束：design tree 的每个分支都访问过，没有留下任何被默默假设的东西。在用户确认我们已经达成共同理解之前，不要采取行动。
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Find the right skill and sequence for your current development task, from shaping an idea to implementation, debugging, and review. The guide also explains when to prototype, prepare specifications, or move work into a fresh session.
Summarize the current conversation and launch a fresh background agent to continue the work. The handoff includes references to existing artifacts and suggested skills, removes sensitive information, and can emphasize the next session’s intended focus.
Review changes from a chosen Git reference against both project coding standards and issue or specification requirements. Separate parallel reviews report rule violations, possible design problems, missing requirements, and changes beyond the intended scope.
Design modules that expose simple interfaces while hiding substantial behavior. Use shared terms and principles to assess interface complexity, decide where behavior can be swapped, and organize code so callers and tests use the same interface.
Diagnose difficult bugs and performance regressions by first building a repeatable check for the exact symptom. Minimize the reproduction, test ranked hypotheses, apply a fix, and verify the original scenario with regression tests where suitable.
Clarify project terminology and the relationships between business concepts. Check definitions against concrete scenarios and code, update GLOSSARY.md as terms are agreed, and record significant design decisions with their trade-offs when the stated criteria are met.