Requirements Discovery Quadrant Method Before executing, first find the real problem.
See the methodology summary at README.md. This edition is OpenCode-exclusive, the original Claude Code edition is at rdq-skill。
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 after confirmation does it hand off.
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 has adedicated verb, and boundaries must not be crossed. This is the only structural guarantee that RDQ will not degrade into a "chatbot that asks a few more questions".
| Quadrant | English | Verb Lock | Absolutely must not |
|---|---|---|---|
| Ⅰ | Known Knowns | Only capture——echo back 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 |
| Ⅲ | Unknown Knowns | Only askwhat the user can answer on the spot | Do not ask what he cannot answer |
| Ⅳ | Unknown Unknowns | Only statesuggestions and let him check them off | Do not ask open-ended questions |
Ⅲ／Ⅳ Discrimination Test
Before drafting any item, first ask yourself one question:
"Can the user answer this on the spot right now?"
- Can answer → Quadrant Ⅲ, useasking(e.g.: Is the classroom network stable? What is the students' level?)
- I need to give information first before he can judge → Quadrant Ⅳ, usepresented(e.g.: Should we prepare a fallback for login failure?——he has not thought that this could happen)
Asking the user "is there anything else you have not thought of?" is a logical error; never ask it.
Interaction Budget (hard upper limit, fixed and not to be improvised)
| Mode | Applies to | Ⅲ Interview | Ⅳ Menu | Confirmation | Total number of times the user is disturbed |
|---|---|---|---|---|---|
| Lite(default) | Single deliverable, can be done within half a day | 1 round ≤3 questions | merged 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 determined silently by you; do not ask the user whether they want Lite or Full(asking an extra round just to ask "how many rounds should I ask" is self-contradictory).
- When unsure, default to Lite, and simply include one extra question on the uncertain dimension in the first round.
- Full's second roundis sent only when the first round's answers open a new branch; if there is no new branch, stop.
questionWhen tools are unavailable (headless / sub-agent environment): switch to asking with a numbered question list in plain text, with the same question-count limit.
Exit at any time (four stop conditions; if any one holds, converge and produce the spec card)
- Escape hatch: the last question of each round always includes the option "That's enough, just start"; if the user writes "stop asking / you decide / enough" in a custom answer, it counts as selecting it.
- Escape phrase: if at any time during the conversation "just do it", "no need to ask", or "show me a first draft first" appears → immediately stop the interview and produce the spec card using the existing information.
- Zero-question collapse：even if the user explicitly says "use RDQ", if the necessary fields (goal / audience / 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(affecting audience, architecture, cost, compliance, irreversible decisions) | Must ask, enter question |
| 🟡 Yellow light | There is a reasonable default value (style, detail preferences, secondary format) | Do not ask, infer and write into the ❓ assumption list |
| 🟢 Green light | Anything goes | Decide yourself, without consuming 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 "align on one sentence for ambiguities that could cause trouble; quietly smooth over the obvious ones."
Execution flow
Phase 0 | Silent determination (not shown to the user)
- Determine mode: Lite or Full (see the interaction budget table).
- Determine domain: educational workshop / teaching slides / lesson preparation materials / video content / programming project / general → determines which section of
references/question-bank.mdto read later.When the question bank does not have this domain(law, medical care, e-commerce, manufacturing, marketing...), see "When the question bank does not have your domain" at the end of Phase 3. - Determine whether to exit: 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 & Confirm (No Questions)
Known-Environment Scan——Quadrant I doesn't just capture what the user said; it also scans:
- Project
AGENTS.md/CLAUDE.md(goals, progress, existing agreements) handoff.md(other Agents' progress)- Existing files in the current folder
- Old RDQ spec cards for the same project
List back both "what the user said" + "what I already know":
我聽到的是：
- 目標：…
- 對象：…
- 產出：…
- 已知限制：…
（我從專案 AGENTS.md 讀到：…）
Voice tolerance: restored keywords (names, dates, numbers, filenames, paths) go hereClearly mark them, so the user can correct errors. Correction is an order of magnitude cheaper than answering—this is also why Quadrant I doesn't count against any question quota.
Don't stop; go straight to Phase 2.
Phase 2｜【Quadrant II】Answer & Clarify (No Counter-Questions)
Pick out from the user's messagethe questions they themselves asked("Which tool is better?" "What budget should I set?"), answer them on the spot; if verification is needed, webfetch verify first, then answer.
Don't leave these questions until after the interview—don't make the user answer your questions while carrying their own doubts。
In daily mode, if there are no such questions, skip this section entirely (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; 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's AGENTS.md, what's in old spec cards → pre-fill and turn into "confirmation questions," or just don't ask.
- Use the
questiontool to ask questions, and respect the interaction budget.
Option Design Rules(quality is the experience):
- Options must beconcrete enough to be written directly into a 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 list only the direction you prefer (anti-anchoring）。
- The question stem must not carry suggestions—suggestions are Quadrant IV's job.
- Attach an escape option "Let's go with this and start right away" to the last question of each round.
- If the user answers "I don't know / either is fine" → record it as a ❓ assumption with your default value,don't keep asking。
When the question bank doesn't have your domain
question-bank.md 's six sections are written for Taiwan's teaching context. If the user's domain isn't among them (law, healthcare, e-commerce, manufacturing, marketing, nonprofit…),don't force-fit an irrelevant domain section, and don't just cobble something together from the generic section—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-off 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; mark the rest as ❓ assumptions.
- Route with the Ⅲ／Ⅳ discrimination test: The user can answer on the spot → ask them (Ⅲ); if they need you to provide information first before they can judge → turn it into a menu for them to check off (Ⅳ).
- Quadrant Ⅳ: Find material from three places: This domain'sirreversible decisions、compliance and information security red lines、the most common reasons this kind of thing fails。
- Options must likewise be concrete enough to be written directly into the 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 word 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 feed good questions back as a new domain section (for the format, see the template at the end of question-bank.md ).
Phase 4｜【Quadrant Ⅳ】Proactive suggestions ★Stop point
Do not ask questions; serve the menu. From question-bank.md 's Ⅳ section ＋ task context ＋ the pitfalls list in the global CLAUDE.md project template library, generate 3–5"things you may not have thought of":
每條格式：<一句話建議> — <一句話代價／影響>
Use a question tool (multiple: true) to let the user check off which ones to include.
Hard rules(to prevent degeneration into sales pitching):
- Each itemmust state the 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"——explicitly deciding what not to do is also a requirement, and it prevents downstream skills from adding them 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 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 the question tool for a single question:
- ✅ Start work according to this
- ✏️ Something needs changing (where to put the custom answer)
- 🔁 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 are echoed in bold, the last safety net for homophone typos).
Request changes → Only revise the spec card and confirm once more, do not rerun the interview.
After confirmation → change frontmatter status: confirmed。
status: draft's spec cardmust not be delivered for execution. Any model, any subsequent session, any other Agent that reads the draft should stop and request confirmation.
Phase 7｜Execute or hand off
Decide the destination according to the domain mapping table:
| Task type | Handoff target |
|---|---|
| Interactive presentation／slides | soil-html-deck、soil-image-deck、soil-teaching-deck |
| Lesson prep material package | lesson-prep |
| Teaching cockpit | teaching-cockpit |
| Formative assessment mini-game | exam-generator |
| Image／video assets | draw、seedance |
| Other | Execute directly yourself |
When handing off, use the **entire "one-paragraph requirement spec"** of the spec card as input, and attach this handoff statement:
The requirements have already gone through the RDQ interview and user confirmation; do not repeatedly ask about already-confirmed items; but retain your own output confirmation gate (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 recording "RDQ spec confirmed, spec path, next step".
After execution: each time the user requests a revision, increment the revisions in the spec card frontmatter in place by +1. A one-line action; no other mechanism needed.
Demo mode (enabled only when the user says "demo RDQ" or "demo 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 terminology:
【象限Ⅲ・Unknown Knowns】訪談追問 - Empty quadrants also output a placeholder line("No quadrant Ⅱ items this time") — let the audience see that all four quadrants are addressed; neither force-fit nor hide them
- Phase 1 explicitly states what the "environment known scan" found — demonstrating the Agent's Known Knowns are greater than what the user has 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 everyday mode— keeping quadrant labels lightweight is enough; ritual adds to the user's reading cost.
External communication discipline
When citing the output of this skill in public settings, the positioning in Sections 11 and 12 of the methodology must be observed:
The RDQ Method does not claim to create 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 one must not claim "RDQ reduced revision counts 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 a 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 |
Verbatim template and field definitions for the requirements spec card |
references/question-bank.md |
Domain-specific Ⅲ interview question bank and Ⅳ suggested menu (living document: please backfill good questions from real use) |
Voice input hint
Users often use voice input, and "RDQ" may be transcribed as "阿滴Q", "R滴Q", "二滴Q", etc. Just handle it according to the global principle of charitable restoration; there is no need to maintain a whitelist of variants. The same applies to free-form answers in custom answer fields during interviews—but the restored keywords must appear on the specification card for visual secondary confirmation, and must not be silently adopted.