Scope & Options

Plan mode on steroids. Help engineers think like product people before writing code.

When to Use

When the user wants to scope a feature before building it. Triggered by /scope-options or when the user asks to think through, scope, or explore options for a feature.

Process

1. Quick Scan (Fast)

Do a quick, lightweight scan to get the lay of the land:

• Project structure (main directories, tech stack)
• Read key docs (README, CLAUDE.md) if they exist
• Note high-level patterns

This should be fast - don't go deep yet. Just enough to have context.

2. Ask What They're Building

Use AskUserQuestion to get the basic idea:

• What do you want to build? (free text)
• Who is this for? (Internal team, End users, Developers/API consumers, Multiple audiences)

Just these two questions first. Get the core idea before going deeper.

3. Targeted Deep Dive

Now that you know what they want to build, explore the relevant parts of the codebase:

• Look for similar features that could be extended or reused
• Understand patterns in the areas you'll likely touch
• Note relevant dependencies and integrations
• Find code they mentioned or that's clearly related

Skip parts of the codebase that aren't relevant to what they're building.

4. Product & Technical Questions

Use AskUserQuestion for remaining questions. Ask in batches of 2-4.

Product questions:

• What problem does it solve?

  • Free text - what pain point or need does this address?

• How will we know it's successful?

  • Options: User engagement metrics, Revenue/conversion, Time saved, Error reduction, User feedback, Not sure yet

• What's the smallest version that delivers value?

  • Free text - push them to think MVP

Technical questions:

• Any initial ideas on approach?

  • Free text - what have they already considered?
  • Mention similar features you found as options

• What are the constraints?

  • Multi-select: Tight timeline, Must use existing tech stack, Needs to integrate with X, Performance critical, Security sensitive, None

• What's the risk if we don't build this?

  • Options: Users churn, Revenue loss, Technical debt grows, Team productivity suffers, Low risk - it's a nice-to-have

• What are we explicitly NOT building?

  • Free text - force them to set boundaries

Ongoing Exploration

Return to the codebase as needed throughout the conversation:

• When user mentions specific features or systems, go look at them
• To answer questions about how a specific option would work
• To validate assumptions before presenting options

Don't hesitate to explore multiple times. It's better to look things up than to guess.

5. Present Options (2-5 options)

Present concrete options as soon as you have enough context. Each option should address BOTH product and technical dimensions:

## Option A: [Name]

**What it is:** [1-2 sentence description]

**Product lens:**
- Delivers value to: [who]
- Time to value: [fast/medium/slow]
- Supports future iteration: [yes/no/partially]

**Technical lens:**
- Approach: [brief technical approach]
- Builds on: [existing code/patterns it leverages]
- Effort: [low/medium/high]

**Tradeoffs:**
- Pros: ...
- Cons: ...

---

## Option B: [Name]
...

Always include:

• At least one "lean/MVP" option
• At least one "more complete" option
• Note which option you'd recommend and why (if you have a view)

ASCII UI mockups - When the feature involves UI, include simple ASCII mockups to illustrate options:

Option A: Modal approach        Option B: Inline approach

┌─────────────────────┐        ┌─────────────────────┐
│  Page content       │        │  Page content       │
│                     │        │  ┌───────────────┐  │
│   ┌───────────┐     │        │  │ Form inline   │  │
│   │   Modal   │     │        │  │ here          │  │
│   │   Form    │     │        │  └───────────────┘  │
│   └───────────┘     │        │                     │
└─────────────────────┘        └─────────────────────┘

This helps visualize different approaches quickly without building anything.

6. Discuss and Refine

After presenting options, use AskUserQuestion to:

• Get their initial reaction (which options resonate?)
• Dig deeper into options they're interested in
• Surface edge cases and hidden complexity
• Help narrow down or combine approaches

7. Summarize

If conversation gets long, provide a summary:

• Which option(s) they're leaning toward
• Key decisions made
• Open questions remaining
• What's explicitly out of scope

8. Transition to Plan Mode

Once an option is chosen, use AskUserQuestion to ask if they're ready to plan implementation.

If yes, use the EnterPlanMode tool and provide context for the planning phase:

## Planning Context

**Chosen approach:** [Option name and brief description]

**Who it's for:** [from intake]

**Success looks like:** [from intake]

**MVP scope:** [what's in v1]

**Out of scope:** [what we're NOT building]

**Constraints:** [timeline, tech, etc.]

**Relevant existing code:** [what to build on from codebase exploration]

This hands off everything learned during scoping so plan mode can focus on implementation details.

Key Principles

• Product before technical - Ask about who/why/success before how
• Force boundaries - Make them say what they're NOT building
• MVP mindset - Always surface the smallest valuable version
• Use the question UI - Never ask questions in plain text, always use AskUserQuestion
• Get to options fast - Don't over-discuss, present concrete choices
• Effort not time - Use low/medium/high, never give time estimates

What This Skill Does NOT Do

• Write code
• Produce formal specs or documentation
• Make decisions for the user
• Give time estimates
• Let engineers skip the product questions