Requirements Discovery Quadrant Method Before executing, first find the real problem.
For the methodology summary, see README.md。
Core positioning
RDQ isthe prerequisite requirements layer for all execution-type skills. It does not produce a finished product itself; it produces a "requirements specification card", and only hands off after confirmation.
One-sentence principle:The cost of the interview must be lower than the rework cost it saves. Whenever this is violated, stop and just do it.
Four-quadrant operating rules (most important; violating this section is an execution error)
Each quadrant hasan exclusive verb, and boundaries must not be crossed. This is the only structural guarantee that RDQ will not degenerate into "a chatbot that asks a few more questions".
| Quadrant | English | Verb lock | Never |
|---|---|---|---|
| Ⅰ | Known Knowns | Only capture—echo what the user has already said | Do not ask questions here |
| Ⅱ | Known Unknowns | Only answer—answer what the user asks | Do not ask the user questions back |
| Ⅲ | Unknown Knowns | Only askwhat the user can answer on the spot | Do not ask what they cannot answer |
| Ⅳ | Unknown Unknowns | Only statesuggestions for them to check | Do not ask open-ended questions |
III / IV discrimination test
Before drafting any item, first ask yourself one question:
"Can the user answer this right now, on the spot?"
- Can answer → Quadrant III, useask(e.g., Is the classroom network stable? What is the students' level?)
- I need to provide information first before they can judge → Quadrant IV, usethe side of(e.g., Should we prepare a fallback for login failure?—they had not thought this could happen)
Asking the user "Is there anything you have not thought of?" is a logical error; never ask it.
Interaction budget (hard upper limit, hard-coded and not to be improvised)
| Mode | Applicable | III Interview | IV Menu | Confirmation | Total number of times the user is disturbed |
|---|---|---|---|---|---|
| Lite(default) | Single deliverable, can be completed within half a day | 1 round ≤3 questions | Merge into the same round, 1 question | 1 time | 2 times |
| Full | Multiple outputs, cross-day, publicly released, costs money, irreversible | ≤2 rounds, ≤4 questions per round | Separate 1 question | 1 time | 3 times |
- The mode is silently determined by you; do not ask the user whether they want Lite or Full(asking one more round just to ask "how many rounds should we ask" is self-contradictory).
- When unsure, default to Lite; just include one extra question for the uncertain dimension in the first round.
- Full's second roundis only sent when the first round's answers open a new branch; if there is no new branch, stop there.
AskUserQuestionWhen unavailable (headless/sub-agent environment): switch to asking with a numbered question list in plain text, with the same question limit.
Exit at any time (four stop conditions; if any one holds, converge on the spec card)
- Escape hatch: the last question of each round always includes a "That's enough, just start" option; if the user writes "stop asking/you decide/that's enough" in Other, it counts as selecting it.
- Escape phrase: if "just do it", "no need to ask", or "show me a first draft" appears at any time in the conversation → stop the interview immediately and produce the spec card with the information available.
- Zero-question collapse：even if the user explicitly says "use RDQ", if the necessary fields (goal/target/output format/hard constraints) are already complete, Quadrant III can bezero questions—skip straight to the spec card. Having RDQ does not mean you must ask.
- Fatigue convergence: if more than half the answers in one round are "doesn't matter/up to you" → do not send another round.
Skipped questionsare all converted into ❓ assumptions on the spec card, and will not block the process.
Red-yellow-green light: decide whether to ask, infer, or decide yourself
| Light | Criterion | Action |
|---|---|---|
| 🔴 Red light | Different answers willcause rework(affects target, architecture, cost, compliance, irreversible decisions) | Must ask, go to AskUserQuestion |
| 🟡 Yellow light | There is a reasonable default (style, detail preference, secondary format) | Do not ask, infer and write into the ❓ assumption list |
| 🟢 Green light | Anything goes | Decide yourself, without taking up the user's attention |
When red-light questions exceed the budget, the excess is automatically downgraded to yellow-light assumptions—better to let assumptions be corrected during the confirmation stage than to keep asking endlessly.
This rule is the systematized version of the global CLAUDE.md principle "confirm a sentence first for ambiguities that could go wrong; quietly let the obvious ones pass."
Execution flow
Phase 0｜Silent determination (not shown to the user)
- Determine mode: Lite or Full (see the interaction budget table).
- Determine domain: education workshop/teaching presentation/lesson preparation material/video content/software project/general → determines which section of
references/question-bank.mdto read later.When the question bank does not have this domain(law, healthcare, e-commerce, manufacturing, marketing…), see "When the question bank does not have your domain" at the end of Phase 3. - Determine whether to exit: if the task is too small or the requirements are already complete → directly say "This task already has enough information; I'll just do it" and then execute, without running RDQ.
Phase 1｜[Quadrant I] Capture confirmation (no questions asked)
Known-environment scan—Quadrant I not only captures what the user says, but also scans:
- Project
CLAUDE.md(Goals, progress, existing agreements) handoff.md(Progress of other Agents)- Files currently in the folder
- Old RDQ spec cards from the same project
List back both "what the user said" + "what I already know":
我聽到的是：
- 目標：…
- 對象：…
- 產出：…
- 已知限制：…
（我從專案 CLAUDE.md 讀到：…）
Voice error tolerance: Restored keywords (names, dates, numbers, filenames, paths) go hereClearly mark, so the user can correct errors. Correction is an order of magnitude cheaper than answering—this is also why Quadrant I doesn't take up any question count.
Don't stop, go straight to Phase 2.
Phase 2｜【Quadrant II】Answer clarification (no counter-questions)
Pick out from the user's messagethe questions he himself asked("Which tool is better?" "How much budget should I set?"), answer them on the spot; if verification is needed, do a WebSearch and then answer.
Don't leave these questions until after the interview—don't make the user answer your questions while carrying doubts。
In daily mode, if there are no such questions, skip this section directly (don't output a placeholder line like "No Quadrant II items this time"; that's something only demo mode does).
Don't stop, go straight to Phase 3.
Phase 3｜【Quadrant III】Interview follow-up questions ★Stop point
- Read
references/question-bank.mdthe corresponding domain section. - Filter questions with red/yellow/green lights, and sort red-light questions by the severity of "what happens if we don't ask".
- Never re-ask what's already known: what the user has said, what's in the project CLAUDE.md, what's in old spec cards → pre-fill and turn into "confirmation questions", or just don't ask.
AskUserQuestionAsk questions, obeying the interaction budget.
Option design rules(quality is experience):
- Options must beconcrete enough to be written directly into the spec: write "a 45-minute class period" not "shorter time"; write "teachers have never used AI at all" not "beginner".
- Cover both ends of the spectrum + "not sure", don't only list the direction you prefer (anti-anchoring）。
- The question stem must not carry suggestions—suggestions are Quadrant IV's job.
- The last question of each round includes an escape option: "Let's leave it here and just start".
- If the user answers "I don't know / either is fine" → record it as a ❓ assumption with your default value,don't repeatedly follow up。
When the question bank doesn't have your domain
question-bank.md The six sections are written for Taiwan's teaching settings. If the user's domain isn't among them (law, healthcare, e-commerce, manufacturing, marketing, nonprofit…),don't force-fit irrelevant domain sections, and don't just rely on the generic section to get it over with hastily—instead, generate questions on the spot using this document's rules:
- Use the generic section as a skeleton: audience / hard constraints / execution environment / deadline / budget / success criteria / one-time or recurring / starting point. These eight dimensions hold in any domain.
- Filter with red/yellow/green lights: in this domain, which things "if answered wrong will cause the whole thing to be redone"? Ask only those, and mark the rest as ❓ assumptions.
- Route with the Ⅲ／Ⅳ discrimination test: if the user can answer on the spot → ask it (Ⅲ); if you need to give information first before he can judge → make it a menu for him to check off (Ⅳ).
- Quadrant Ⅳ finds material from three places: this domain'sirreversible decisions、Compliance and Information Security Red Lines、The most common reasons this kind of thing fails。
- The options must likewise be specific enough to be written directly into a spec, and likewise include "uncertain" and escape options.
Existing sections that can be reused directly across domains：video(universal for video production),slides(presentations, only the teaching examples need wording changes),dev(programming projects, just read "student/workshop" as "user/activity"). What is truly tied to the teaching context is only lesson(lesson preparation materials).
If this domain will recur, after the interview proactively suggest that the user backfill the good questions into a new domain section (for the format, see the template at the end of question-bank.md ).
Phase 4｜【Quadrant IV】Proactive suggestions ★Stop point
Don't ask questions, serve the menu. From question-bank.md the IV section of ＋ task context ＋ the pitfall list of the global CLAUDE.md project template library, generate 3–5"You might not have thought of":
每條格式：<一句話建議> — <一句話代價／影響>
Use one AskUserQuestion（multiSelect: true) to let the user check off what to include.
Hard rules(to prevent degeneration into sales pitch):
- Each itemmust be labeled with its cost(will take more time / cost more money / increase complexity)
- Unchecked by default, and it can proceed even if none are checked
- Maximum 5 items; better to have fewer than to be excessive
- Unchecked items are recorded in the spec card's "❌ Exclusions"——clearly deciding what not to do is also a requirement, and it prevents downstream skills from adding it back on their own initiative
Lite mode: this question is merged into the same round as Phase 3, with no separate round.
Phase 5｜Produce the requirements spec card
Generate according to references/spec-template.md ,hard limit of one screen to read through(if it exceeds that, it loses the value of "glance to confirm").
- Paste the full text directly in the conversation, not just give a path——confirmation happens in the conversation.
- Save location:
<專案>/rdq/RDQ-spec-<任務slug>-<YYYYMMDD>.md - When not in the project folder: first paste only in the conversation, and ask "Do you want to save it? Where?"——do not scatter files randomly in the home directory.
- frontmatter
status: draft。
Phase 6｜User confirmation ★★The only hard stop point
Absolutely do not start work before the user explicitly confirms. This is the most visible difference between RDQ and the ordinary agent behavior of "ask while doing," and it is also the most important line of instruction in this skill.
Use AskUserQuestion single question:
- ✅ Start work according to this
- ✏️ Something needs changing (fill in where in Other)
- 🔁 Ask me another round (only provided in Full)
Ask the user to look especially at three places:❓ Assumptions list(yellow-light guesses are caught here),❌ Exclusions、Keywords(names/dates/numbers/file names echoed in bold, the last safety net for homophone typos).
If changes are requested → only change the spec card and confirm once more, do not rerun the interview.
After confirmation → change frontmatter to status: confirmed。
status: draftspec cardmust not be delivered for execution. Any model, any subsequent session, any other Agent that reads draft should stop and request confirmation.
Phase 7｜Execute or hand off
Determine the destination by domain lookup table:
| Task type | Handoff target |
|---|---|
| Interactive presentation / slides | html-slide-builder、soil-html-deck、soil-image-deck、soil-teaching-deck |
| Lesson preparation material package | lesson-prep |
| Teaching cockpit | teaching-cockpit |
| YouTube upload material | yt-pack |
| Formative assessment mini-game | teaching-minigames |
| Image / video assets | draw、seedance |
| Other | Execute directly yourself |
When handing off, use the **entire "one-paragraph requirement specification"** from the spec card as input, and attach this handoff statement:
The requirements have already been confirmed through the RDQ interview and with the user; do not repeatedly ask about already-confirmed matters; but retain your own output confirmation checkpoints (e.g., outline confirmation).
Requirement confirmation (RDQ) and output confirmation (downstream skills) are layered and do not overlap.
If the project has handoff.md → add a note: "RDQ spec confirmed, spec path, next step".
After execution: each time the user requests a modification, increment the spec card frontmatter's revisions by 1 in place. A one-line action; no other mechanism needed.
Demo mode (enabled only when the user says "demo RDQ" or "demo it for the audience")
The user is a promoter of the RDQ method, and this skill itself is his demo piece. When enabled:
- Each phase title carries the quadrant number and English term:
【象限Ⅲ・Unknown Knowns】訪談追問 - Empty quadrants also output a placeholder line("No Quadrant II items this time") — let the audience see that all four quadrants are handled, neither forced nor invisible
- Phase 1 explicitly states what the "environment known scan" found — demonstrating the Agent's Known Knowns are greater than what the user said out loud, which is concrete evidence of RDQ moving from Prompt Engineering toward requirements engineering
- End with the originality statement from Section 11 of the methodology
Do not do this in daily mode— keep quadrant labels lightweight; the sense of ritual is a reading cost for the user.
External communication discipline
When citing the output of this skill in public, you must adhere to the positioning in Sections 11 and 12 of the methodology:
The RDQ Method does not claim to have created the Known/Unknown four quadrants or requirements engineering theory, but rather integrates, reinterprets, and processualizes them and conducts experiments.
telemetry data can only be calledsingle-arm descriptive data, and you must not claim "RDQ reduced the number of revisions by N%" — there is no control group, and tasks where the user skipped RDQ are systematically simpler (self-selection bias).
Epistemic honesty: AI cannot truly determine whether the user "knows that they know"; "whether they can answer on the spot" is only anoperational approximationof Unknown Knowns. Answer this way when asked in public.
Files
| File | Purpose |
|---|---|
references/spec-template.md |
Requirement spec card verbatim template and field definitions |
references/question-bank.md |
Domain-specific III interview question bank and IV suggested menu (living document: please backfill good questions from real practice) |
Voice input prompt
Users often use voice input, and "RDQ" may be transcribed as "阿滴Q", "R滴Q", "二滴Q", etc. It is sufficient to handle this according to the global principle of charitable restoration; there is no need to maintain a whitelist of variants. The free-form answers in the Other field during interviews also apply—but the restored keywords must appear on the specification card for visual secondary confirmation, and must not be silently adopted.