Create a Markdown questionnaire for someone who has information you need. Clarify the recipient and required decisions, then produce prioritized questions with context and answer spaces for asynchronous replies or a meeting.
把你无法完整回答的 decision 转成一份交给他人填写的 questionnaire。
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
把用户无法独自回答的事情转成一份 questionnaire：一份交给某个人异步填写，或在会议中一起填写的 Markdown document。Recipient 掌握用户缺少的知识；questionnaire 要把这些知识提取出来。
Grill the send, not the subject。 只围绕用户始终能够回答的 send 进行访谈：发送给谁，以及需要对方返回什么。Document 中的问题再针对 recipient 所知与用户所需之间的 gap。
发送给谁？ 在一次交流中询问 recipient 的 role、expertise 和与用户的关系。这会确定 questionnaire 的语气，以及需要携带多少 context。知道 recipient 是谁，以及对方掌握哪些用户不掌握的知识后，这一步完成。
需要返回什么？ 在一次交流中询问用户无法独自解决、需要此人提供的具体 decisions 或 facts。当你得到一份具体清单，明确用户最终必须能做什么或决定什么时，这一步完成。
编写 questionnaire。 根据步骤 1–2 的 gap 起草问题，并遵循下面的 Document structure。把文件写到当前目录的 to-questionnaire-<slug>.md（slug 来自主题），然后报告路径。当文件存在，且步骤 2 中用户列出的每项内容都有问题覆盖时完成。
把 document 定位为 discovery questionnaire：用户缺少 context，而 recipient 掌握它。按重要程度降序排列问题，异步沟通可能只有一次机会；问题超过少量时，按主题放在 ## headings 下。使用以下 template。
Purpose: <这份 questionnaire 为什么存在，以及它关系到哪项 decision>
From: <用户>, To: <recipient>, How your answers will be used: <答案将用于哪里>
用一个 paragraph 帮助不了解用户思路的 recipient 建立 context。内容足以让对方认真回答，但不要写满一页。
说明 deadline 和大致所需时间。部分回答和“我不知道”也有价值；不确定时请标记出来，而不是直接跳过。
每个 theme 使用一个 ## section，问题按重要性降序排列。每个问题只包含一个 idea，绝不要组合多个问题；在正下方放 answer stub。只有问题可能被误解或得到敷衍回答时，才添加一行 why this matters。
Why this matters: 这决定我们现在就为突发流量预留资源，还是推迟处理。
</question-example>
最后提供一个兜底问题：还有哪些我们没问、但应该知道的内容？
</questionnaire-template>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.