Requirements interview

Requirements Interview

Use this skill to run an understanding-and-judgment workflow before implementation. It converts vague requests into requirements artifacts through progressive, impact-framed Socratic questioning.

Responsibility Boundary

Do:

• Ask one high-value question at a time.
• Explain why the question matters and what the answer will affect.
• Maintain an editable Interview Ledger during the interview.
• Produce or update a PRD or brief, ADR candidates, and a handoff contract.
• Preserve unresolved items as open questions instead of guessing.
• Run a convergence check before closing the interview.

Do not:

• Implement code, execute tasks, schedule work, or call /goal.
• Run phase-harness or produce a full implementation phase plan.
• Create final ADR files; only identify ADR candidates.
• Hide requirements state in conversation context only.

Workflow

1. Locate or create artifacts

   • Prefer docs/requirements/<slug>/.
   • Use these files unless the user requests another location:
     • interview-ledger.md
     • prd.md
     • adr-candidates.md
     • handoff-contract.md

2. Set the artifact language

   • Write the Interview Ledger, PRD/brief, ADR candidates, and handoff contract in the user's working language.
   • Infer the working language from the interview language and project instructions. If the interview is in Korean, write user-facing artifacts in Korean.
   • Keep stable IDs, file names, commands, code identifiers, and accepted domain terms in their original form.
   • Do not copy English section titles from reference templates into final artifacts unless the user asks for English.

3. Reconcile editable ledger first

   • If interview-ledger.md exists, read it before asking a new question.
   • Detect manual edits, deleted IDs, changed decisions, and new assumptions.
   • Summarize impacts and resolve material conflicts before continuing.
   • See ledger-schema.md.

4. Ask impact-framed questions

   • Ask from broad frame to details: goal, audience, output, scope, success, constraints, risks, then execution handoff.
   • Every question must include an Impact Frame.
   • See interview-flow.md.

5. Update the Interview Ledger after each answer

   • Add or update stable IDs such as REQ-001, DEC-001, ASM-001, OQ-001, IMPACT-001, and ADR-CAND-001.
   • Show changed items and newly introduced impacts before the next question.
   • If an answer changes prior decisions, run the correction protocol in ledger-schema.md.

6. Checkpoint before narrowing

   • After goal/audience/output, scope/non-scope, and success criteria are clear, show a short checkpoint summary and ask whether to continue deeper.
   • Do not wait until the end to reveal accumulated requirements.

7. Run the convergence check

   • Check whether the ledger has converged into a coherent requirements ontology before closing.
   • Do not invent a numeric ontology similarity score. If no real ontology comparison tool exists, use the qualitative convergence gate in convergence-check.md.
   • Continue interviewing if the latest answer creates new high-impact questions, unresolved conflicts, or blocking open questions.

8. Close with artifacts

   • Write or update the PRD/brief using prd-template.md.
   • Write ADR candidates using adr-candidates-template.md.
   • Write the handoff contract using handoff-contract-template.md.

Question Format

Use this compact format for each substantive question:

### 질문
[one question]

### 왜 묻는가
[one or two sentences]

### 영향
- [affected area]: [consequence]
- [affected area]: [consequence]

### 답변에 따른 변화
- A: [likely scope/decision impact]
- B: [likely scope/decision impact]

For low-impact clarifications, compress the frame to one sentence, but still state the impact before asking.

Completion Criteria

End the interview only when all are true:

• Goal, user/audience, and output are explicit.
• Scope and non-scope are explicit.
• Success criteria and verification approach are explicit enough for execution.
• High-impact data, security, operational, cost, and schedule constraints are either confirmed or listed as open questions.
• Key decisions, assumptions, rejected alternatives, and impacts are recorded.
• The convergence check is converged: no material conflicts remain, no new high-impact question was introduced by the last answer, and every blocking open question has an owner and next decision point.
• A handoff contract tells future agents what to read and preserve.

Follow-Up Routing

After this skill completes:

• Small clear work may be implemented directly by the current agent.
• Larger work may be handed to /goal.
• Multi-phase work may be handed to phase-harness.
• Architecture decisions should be checked later with /adr --check, using adr-candidates.md as context.

The artifacts, not the current chat session, are the source of truth for later execution.