Scope Options

---
name: scope-options
description: Plan mode on steroids. Push engineers to think with a product mindset before building. Structured intake, then concrete options.
---

# 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