interview

Use before implementation, design, or migration when requirements are unclear and targeted clarifying questions are needed to gather precise context.

<SUBAGENT-STOP> If you were dispatched as a subagent to execute a specific task, skip this skill entirely. This skill is for orchestrators and interactive session-level routing only. Proceed directly with your assigned task. </SUBAGENT-STOP>

Interview

Critical requirements interviewer that asks targeted clarifying questions before expensive operations begin. The goal is to eliminate ambiguity and gather precise context so downstream skills (job-orchestrator, feature-dev, prd-creator) produce accurate results.

Input Contract

When called by another skill (orchestrated mode):

{
  "goal": "what needs to be done (issue title, feature description, task)",
  "context": "collected context from context-collector or another agent",
  "domain": "implement | review | design | migrate | custom",
  "caller": "job-orchestrator | feature-dev | user | prd-creator",
  "known_facts": ["already known facts or decisions"],
  "max_questions": null
}

When called standalone: input is the user's free-text description.

Output Contract

{
  "decisions": [
    {"question": "...", "answer": "...", "impact": "high | medium"}
  ],
  "constraints": ["identified constraints"],
  "assumptions": ["confirmed assumptions"],
  "risks": ["identified risks"],
  "refined_goal": "refined, unambiguous goal statement"
}

Workflow

Phase 1: Context Acquisition

Orchestrated mode (called with context):

  • Parse the input contract
  • Proceed directly to Phase 2

Standalone mode (called by user):

  1. Ask the user: "What are you trying to accomplish?"
  2. If in a project directory, launch context-collector as sub-agent to gather codebase context
  3. Wait for context, then proceed to Phase 2

Phase 2: Uncertainty Analysis

Analyze goal + context to identify "uncertainty zones" — areas where:

  • Multiple valid approaches exist
  • Requirements are ambiguous or contradictory
  • Technical constraints are unclear
  • Scope boundaries are undefined
  • Dependencies or impacts are unknown

Each uncertainty zone becomes a potential question. Skip questions where the answer is already clear from context or known_facts.

Determine question count dynamically:

  • Simple task with good context → 2-3 questions
  • Complex task with sparse context → 5-7 questions
  • Stop when remaining uncertainty is low enough to proceed confidently

Phase 3: Interactive Interview

Ask questions one at a time, each with answer options where possible:

❓ Question 1/~N: [Topic — e.g., "Authentication approach"]

[Brief context why this matters for the task]

  A) Option one (brief explanation)
  B) Option two (brief explanation)
  C) Option three
  D) Need more context — tell me more

> answer with letter or free text

Adaptation rules:

  • If user picks an option → record decision, move to next question
  • If user answers in free text → extract the decision, confirm understanding
  • If user picks "Need more context" (D) → provide deeper explanation or trigger a mini /brainstorm --quick on this specific point, then re-ask
  • If user says "skip" or "don't care" → record as assumption with medium confidence, move on
  • Adjust remaining questions based on answers (some questions become irrelevant after certain decisions)

Phase 4: Synthesis

After all questions are answered:

  1. Compile the output contract:

    • decisions: all Q&A pairs with impact level
    • constraints: technical and business constraints identified
    • assumptions: things assumed true but not explicitly confirmed
    • risks: potential issues surfaced during interview
    • refined_goal: clear, unambiguous restatement of the goal

  2. Present summary to user:

## Interview Summary

### Goal (refined)
[Clear statement]

### Key Decisions
1. [Decision] — impact: high
2. [Decision] — impact: medium

### Constraints
- [Constraint]

### Assumptions (please verify)
- [Assumption]

### Risks
- [Risk]
  1. Ask: "Does this look right? Anything to correct before we proceed?"

Phase 5: Handoff

Return the output contract to the calling skill, or if standalone — ask what the user wants to do next:

  • "Start implementing? I can run /feature-dev"
  • "Create a PRD? I can run /prd-creator"
  • "Need more brainstorming? Try /brainstorm"

Question Design Principles

Good interview questions are:

  • Specific: "Should auth use JWT or session cookies?" not "How should auth work?"
  • Impactful: the answer meaningfully changes the implementation
  • Non-obvious: don't ask things derivable from the codebase
  • Ordered by dependency: ask foundational questions first (they may make later questions unnecessary)

Provide answer options when:

  • There are 2-4 clear alternatives
  • The user might not know all options available
  • You want to speed up the interview

Skip options when:

  • The question requires a free-text answer (e.g., "What's the deadline?")
  • The space of answers is too large

Integration with Other Skills

job-orchestrator → context-collector → interview → plan → execute
feature-dev → interview (Phase 1) → design → implement
prd-creator → interview → requirements document

The interview skill is designed to be composable — any skill that needs user input before proceeding can call it.

Rules

  • NEVER ask more than 7 questions (keep it focused)
  • NEVER ask questions whose answers are already in the provided context
  • ALWAYS provide answer options when 2-4 clear alternatives exist
  • ALWAYS adapt subsequent questions based on previous answers
  • If the user seems impatient or says "just do it" — stop interviewing, document remaining unknowns as assumptions, and proceed
  • One question at a time — never dump all questions at once