メニュー
Start a structured interview to gather requirements for complex features. Use when tackling multi-layer features, validating PRDs, or defining scope for implementation.
| name | deep-interview |
| description | Start a structured interview to gather requirements for complex features. Use when tackling multi-layer features, validating PRDs, or defining scope for implementation. |
| argument-hint | <issue-number|prd-path|feature-description> |
| user-invocable | true |
| allowed-tools | ["Bash(git:*)","Bash(gh:*)","Read","Glob","Grep","AskUserQuestion","Write","Agent"] |
A structured interview process for gathering requirements and making design decisions on complex features.
$ARGUMENTS can be:
| Format | Example | Description |
|---|---|---|
| Issue number | #531 or 531 | GitHub issue to research first |
| PRD path | docs/feature-spec.md | Existing PRD to validate |
| Feature description | "user authentication flow" | Free-form description |
| Nothing | (empty) | Ask what we're planning |
Silently research the topic before asking any questions:
Summarize findings to the user before starting questions:
"I've reviewed [issue/PRD/code]. Here's what I found: [current state, planned state, key gaps]. Let me ask some questions to clarify the approach..."
First question — establish boundaries:
Question: "What does [goal] mean to you? What's your target scope?"
Header: "Scope"
Options:
- Minimal: [simplest version, automatic, no new UI]
- Medium: [adds user interaction after completion]
- Full: [mid-process interaction, complete workflow]
- Other: (always available)
Options should represent increasing complexity, not different features.
Second question — choose implementation strategy:
Question: "Which approach do you prefer for [main mechanism]?"
Header: "Approach"
Options:
- Option A: [simpler, faster to build]
- Option B (Recommended): [better UX, more robust]
- Hybrid: [combine best of both]
Listen for: If stakeholder suggests something different ("we could do X because Y already exists"), probe deeper — they have context about existing patterns.
Third question — identify most valuable improvements:
Question: "What's the most valuable improvement for users right now?"
Header: "Priority"
multiSelect: true
Options:
- [Capability A]: [benefit description]
- [Capability B]: [benefit description]
- [Capability C]: [benefit description]
Drill into specifics for each selected priority. Ask about context/data flow, UI/UX patterns, and behavior on triggers — adapting questions to the feature at hand.
Architectural choices — new implementation vs reusing existing patterns, and why.
Listen for: "We could reuse X" — stakeholder knows about existing infrastructure you should leverage.
Final questions: timeline expectation (quick win / full feature / polish) and any additional ideas or concerns.
After completing the interview, generate a PRD covering:
Save the PRD to an appropriate location (e.g., prds/[date]-[feature-name].md or as specified).
multiSelect: true when options aren't mutually exclusive$ARGUMENTS
Creates expert consultation documents with code extraction, git diffs, and size tracking (125KB limit). Use when user asks to "create an expert consultation document", "prepare code for expert review", "gather architecture context", or needs comprehensive technical documentation for external analysis. Requires Node.js 18+.
Analyze dependency updates and generate a changelog report with breaking changes, new features, and actionable recommendations. Use after updating packages, before planned upgrades (preflight), or to research what changed between specific versions. Triggers on "analyze deps", "analyze dependencies", "dependency update report", "breaking changes in update", "what changed in dependency update".
Capture session learnings and update project docs. Use when ending a session, after completing a feature, or when asked to "debrief", "capture learnings", "update project knowledge", or "what did we learn".
Extract and synthesize learnings from past Claude Code session transcripts into project documentation. Use when asked to "mine history", "extract learnings from past sessions", "what patterns keep recurring", or "improve docs from history".
Trim a PR before merging - remove complexity that accumulated during development. Use when preparing to merge, cleaning up code, trimming unnecessary complexity, or asked to simplify a PR.
Creates comprehensive PR descriptions by systematically reviewing ALL changes - features, bug fixes, tests, docs, and infrastructure. Use when user asks to "update the PR", "prepare PR for review", "write PR description", or "document branch changes". Requires gh CLI.