---
name: scorpio-feature-intake
description: Conduct a focused interview to gather complete requirements for a specific feature - what it does, who uses it, how it integrates with existing functionality, and technical constraints. Use when the user wants to add a new feature to an existing codebase.
---

# Feature Intake Interview (alias: Feature Discovery Interview)

A structured methodology for extracting complete requirements for a single feature or small related set of features. This skill helps you understand what needs to be built and how it fits into the existing system.

## Scope

This skill is for **feature-level** planning, not project-level:

| Use This Skill | Use scorpio-project-intake (`scorpio-project-intake`) Instead |
|----------------|---------------------------------------|
| "Add dark mode to the app" | "Let's plan the whole app" |
| "Implement user notifications" | "Design the notification system architecture" |
| "Add export to PDF" | "Build a document management module" |
| "Create an admin dashboard page" | "Plan the admin portal product" |

If the scope is a whole product, module, or multiple unrelated features, use **scorpio-project-intake** (`scorpio-project-intake`).

## The Five Categories

Every feature needs clarity in these five areas:

| Category | Question | Examples |
|----------|----------|----------|
| **WHAT** | What does the feature do? | sends notifications, exports data, filters results |
| **WHO** | Who uses it and when? | admins for reporting, users after checkout |
| **WHERE** | Where does it live in the app? | settings page, sidebar, modal overlay |
| **HOW** | How does it integrate? | uses existing auth, calls external API, extends current UI |
| **CONSTRAINTS** | What limitations exist? | must work offline, no new dependencies, match existing style |

## Coverage Requirements

Track progress toward minimum coverage:

- **WHAT**: Clear description of the feature's behavior
- **WHO**: At least 1 user type and trigger/context
- **WHERE**: Location in the app identified
- **HOW**: Integration approach understood
- **CONSTRAINTS**: Technical or business constraints known (or confirmed none)

## Interview Rules

1. **NO recaps or summaries** - Jump straight into your response
2. **Under 100 words per turn** - Be direct and conversational
3. **Exactly 1 focused question per turn** - Rarely 2 if closely related
4. **Reference specifics** - Use what the user said without restating it
5. **Acknowledge briefly** - "Got it—notifications after checkout. Push or in-app?"

## Question Progression

Follow this order, skipping categories that are already filled:

```
1. If WHAT is unclear:
   → "What should this feature do? Walk me through the behavior."

2. If WHO is unclear:
   → "Who uses this and when do they need it?"

3. If WHERE is unclear:
   → "Where in the app does this live? New page, existing screen, background?"

4. If HOW is unclear:
   → "How should this integrate? Any existing code it should use or extend?"

5. If CONSTRAINTS are unknown:
   → "Any technical constraints—performance, compatibility, dependencies to avoid?"

6. If all categories have sufficient info:
   → "I have enough to investigate the codebase. Ready to design the implementation?"
```

## Gap Detection

After each user response, mentally update your coverage tracker:

```
Feature Coverage:
- WHAT: [clear/unclear]
- WHO: [identified/unknown]
- WHERE: [located/unknown]
- HOW: [understood/unknown]
- CONSTRAINTS: [known/unknown/none]
```

Prioritize questions toward gaps.

## Extracting Information from Responses

When the user provides information, identify and categorize:

**From:** "I want users to be able to export their podcast history as a CSV file. Should be on their profile page, and it needs to handle large histories without timing out."

**Extract:**
- WHAT: Export podcast history to CSV
- WHO: Users (from their own profile)
- WHERE: Profile page
- HOW: (need to ask - new button? existing menu?)
- CONSTRAINTS: Must handle large data sets, avoid timeouts

**Still need:** Integration approach (UI placement, existing export patterns)

## Integration-Focused Questions

Since features are added to existing codebases, probe integration:

| Pattern | Question |
|---------|----------|
| **Reuse** | "Is there existing code that does something similar we should follow?" |
| **Extend** | "Should this extend an existing feature or be standalone?" |
| **Replace** | "Is this replacing something that exists today?" |
| **Parallel** | "How does this relate to [similar existing feature]?" |

## Output Format

When the interview is complete, produce a structured feature brief and **write it to a file**.

### File Output — REQUIRED

Write the feature brief to: `{docs.planning}/FEATURE-BRIEF.md`

Create the `{docs.planning}/` directory if it doesn't exist. This file is the handoff to **scorpio-feature-plan** (`scorpio-feature-plan`) — without it, downstream skills have no access to what the user said.

If multiple feature briefs already exist, append a short slug: `{docs.planning}/FEATURE-BRIEF-[slug].md`

### Brief Structure

```markdown
## Feature Brief: [Feature Name]

### Summary
[2-3 sentences describing the feature]

### Behavior
**What it does**: [Specific behavior description]
**Trigger**: [What initiates the feature]
**Output**: [What the user sees/gets]

### Users & Context
- **Primary user**: [Role]
- **When used**: [Context/trigger]
- **Frequency**: [How often]

### Location
- **Entry point**: [Where users access it]
- **UI placement**: [Specific location in interface]
- **Navigation**: [How users find it]

### Integration
- **Extends**: [Existing feature/code to build on]
- **Uses**: [Existing services, APIs, components]
- **Affects**: [Other features this might impact]

### Constraints
- **Technical**: [Performance, compatibility, etc.]
- **Business**: [Deadlines, compliance, etc.]
- **Design**: [Must match existing patterns, etc.]

### Acceptance Criteria
- [ ] [Specific, testable criterion]
- [ ] [Specific, testable criterion]
- [ ] [Specific, testable criterion]

### Open Questions
- [Any unresolved items]
```

## Example Interview

```
User: I want to add a "share episode" feature

You: Share to where—social media, copy link, or something else?

User: Copy link and share to Twitter/X

You: Two share options: copy link and Twitter. Who uses this—any user, or
just logged-in users?

User: Anyone, even if not logged in

You: Public share, no auth required. Where should the share button appear—
on the episode player, episode list, or both?

User: On the episode detail page, near the play button

You: Episode detail page by the play button. Should this use the same button
style as other actions on that page?

User: Yeah, match the existing download button style

You: Got it—match download button. Any constraints? Need URL shortening,
tracking, specific Twitter card format?

User: Just a clean URL with the episode title in the tweet text

You: Simple implementation. I have enough to investigate the codebase. Ready
to design how this integrates?
```

## What NOT To Do

- ❌ Ask about the whole product when scoping a single feature
- ❌ Assume how it should integrate without asking
- ❌ Skip the WHERE question (placement matters for integration)
- ❌ Ignore existing patterns in the codebase
- ❌ Over-scope by suggesting additional features
- ❌ Use filler phrases ("Great idea!", "That sounds useful!")

## Handling Scope Creep

If the user expands scope during the interview:

```
User: Oh, and we should also add email sharing, SMS, and embed codes...

You: Let's focus on copy link and Twitter first. We can plan additional share
options as a follow-up feature. Sound good?
```

Keep the scope tight. Multiple related features can be separate feature briefs.

## Handling Vague Requests

| User says | You ask |
|-----------|---------|
| "Add sharing" | "Share what, and to where?" |
| "Make it faster" | "What's slow right now? Which action or page?" |
| "Improve the UX" | "Which specific interaction needs improvement?" |
| "Add analytics" | "What do you want to track? User actions, performance, business metrics?" |

## Next Steps

After completing the interview, use the **scorpio-feature-plan** (`scorpio-feature-plan`) skill to:
1. Investigate the codebase for integration points
2. Identify existing patterns to follow
3. Design the implementation approach
4. Produce `TASK-PLAN-HANDOFF.json` for scorpio-task-plan (`scorpio-task-plan`)
5. Route generated tasks to scorpio-execute (`scorpio-execute`)
