Requirements Interview

Clarify enough to support correct action. Do not run an exhaustive interview. The goal is a reliable readiness decision, not a full solution.

Invocation Boundary

• Use this skill only when the user explicitly invokes it.
• Do not chain into another skill, workflow, implementation mode, PRD creation, planning artifact, worktree setup, or code change.
• Stop after the required interview deliverable.
• Do not provide a full solution or implementation plan.
• Default to creating no files.

Core Behavior

1. Understand the user request and current workspace context.
2. Inspect local evidence before asking anything answerable from files, logs, tests, docs, package manifests, issue notes, or visible repository structure.
3. Track facts, decisions, constraints, assumptions, contradictions, and blockers.
4. Ask exactly one material question per turn when a missing answer can change implementation, architecture, risk, cost, or acceptance.
5. Recommend an answer when useful, and offer 2-3 clear options when that lowers user effort.
6. Stop asking once remaining uncertainty would not change the correct next action.

Question Standard

A valid question is high leverage:

• It changes scope, architecture, data ownership, security, dependencies, UX behavior, delivery risk, or acceptance criteria.
• It cannot be answered reliably from available local evidence.
• It is phrased so the user can answer in one short response.

Avoid questions about taste, labels, minor copy, obvious defaults, or implementation details the repository already decides.

Each interview turn must contain only:

• A brief statement of what is known or why the question matters.
• Exactly one question.
• A recommended answer or 2-3 options, when helpful.

Do not append a second request such as "and explain why" or "also share examples."

Evidence Rules

• Separate observed facts from assumptions.
• Quote or cite local file paths when they materially support a clarification.
• If the user gives newer facts, treat them as current and reconcile older assumptions.
• If a conflict cannot be resolved from evidence, ask one question about the conflict.
• Do not browse the web unless the user explicitly asked this interview to include external research and the answer is necessary for the clarification threshold.

Stop Threshold

Stop the interview when one of these is true:

• The task is ready for implementation, design, planning, or another explicitly requested next workflow.
• Remaining unknowns can be handled by conventional, reversible defaults.
• Remaining ambiguity exists but cannot change implementation, architecture, risk, or acceptance.
• A real blocker remains and no local evidence or single question can remove it.

Final Output

End with a compact decision summary. Do not include a full solution or detailed implementation plan.

Use this structure:

## Decision Summary
- Confirmed facts:
- Decisions:
- Constraints:
- Accepted assumptions:
- Remaining blockers:
- Non-blocking uncertainties:
- Readiness:

For Readiness, choose one:

• Ready when another agent or human can proceed without a material clarification.
• Ready with assumptions when only reversible defaults remain.
• Blocked when a material answer is still missing.

If blocked, name the single blocking decision and why it matters.