Lens: Scope git:20260814.769885bA

Immutable. This exact content is served forever at /api/v1/blob/0b1380439dafe1f2.

---
name: "Lens: Scope"
description: "Anti-scope-creep. Forces the question: what is the smallest thing that delivers value?"
when_to_use: "When a plan is quietly growing beyond the original ask, or the user sounds overwhelmed by scope; before committing to a large implementation, ask what the smallest valuable version looks like."
user-invocable: false
metadata:
  family: clod-lens
allowed-tools:
  - Read
---

# Scope Coach

Anti-scope-creep skill. Counterbalances the natural tendency to over-analyse, over-build, and resist cutting features. Forces the question: "What's the smallest thing that delivers value?"

---

## When This Skill Applies

Use this skill when:
- A feature design is growing in complexity
- Multiple approaches are being weighed without resolution
- The conversation has been exploring options for too long without committing
- The user says "I'm not sure where to start"
- A domain model reveals more complexity than expected
- The implementation plan has more than 5-7 steps for a single feature
- The user is adding "nice to haves" to the core requirement
- Analysis is deepening but no code is being written

**This skill is a counterweight**; it fires when the natural instinct to understand deeply risks delaying action.

---

## Core Principle

**Systems thinkers see everything. Ship anyway.**

Depth of understanding is a strength. But understanding without shipping is just analysis. The goal is not to stop thinking deeply; it's to think deeply *and then scope ruthlessly*.

The best v1 is the smallest thing that proves the idea works.

---

## The Scope Test

For any feature or task, answer these three questions:

### 1. What's the single thing this must do?

Not the three things. Not the five things. The ONE thing that, if it worked, would prove the concept.

```
✗ "Users can create accounts, manage profiles, set preferences,
   invite team members, and customise their dashboard"
✓ "Users can create accounts"
```

### 2. What can be hardcoded, defaulted, or deferred?

Everything that isn't the core behaviour can wait.

```
✗ Build a configurable notification system with email, SMS, push,
   and in-app channels with user preferences
✓ Send one email on signup. Add channels later.
```

### 3. What's the manual fallback?

If a feature is too complex to automate right now, can it be done manually?

```
✗ Build an automated invoice reconciliation system
✓ Export CSV, reconcile in spreadsheet, automate later if it matters
```

---

## Scope Reduction Patterns

### Pattern: Spike First

When unsure about complexity, write a throwaway proof-of-concept:
- Time-box it (2 hours max)
- No tests, no polish, no error handling
- Answer one question: "Does this approach work?"
- Then plan the real implementation with evidence

### Pattern: Vertical Slice

Build one complete path through the system instead of building all features partially:
```
✗ Build User model + Course model + Enrolment model + Progress model
  (all incomplete, none usable)

✓ Build User model + one API endpoint + one UI page
  (one complete, usable path)
```

### Pattern: Feature Flags Off

Build the minimum, ship it behind a flag, gather feedback, iterate:
- v0: Core behaviour, no edge cases
- v1: Handle main edge cases, improve UX
- v2: Polish, optimise, extend

### Pattern: Delete the Second Feature

If you planned two features, delete one. Ship the other. See if anyone asks for the one you deleted.

---

## Scope Expansion Warning Signs

Watch for these in conversation:

| Signal | What's happening | Response |
|--------|-----------------|----------|
| "While we're at it..." | Scope creep | "That's a separate ticket" |
| "What about edge case X?" | Premature completeness | "Handle it when it happens" |
| "We should also..." | Feature accumulation | "Add to backlog, not this PR" |
| "It would be nice if..." | Gold plating | "Ship without it, add if requested" |
| 45+ minutes discussing approach | Analysis paralysis | "Pick one. Try it. Adjust if wrong" |
| Plan exceeds 7 steps | Over-engineering | "Which 3 steps deliver the core?" |

---

## How to Apply

This skill doesn't produce standalone output. It **challenges** other work:

### During Planning
```
⚠️ Scope: This plan has 12 steps. Which 3-4 deliver a working first version?
The rest can be follow-up tasks.
```

### During Design
```
⚠️ Scope: The domain model covers 8 entities. Which 2-3 are needed for the
first usable feature? Model those. The rest can wait.
```

### During Implementation
```
⚠️ Scope: This function handles 6 edge cases. The happy path covers 90%
of usage. Ship with happy path + one critical error case.
```

---

## The Think-Then-Ship Balance

This skill does NOT mean:
- Skip modelling (domain-modeller is still essential)
- Ignore ethics (ethics-reviewer is still a constraint)
- Write sloppy code (quality per line stays high)
- Never plan (planning is good; over-planning is the enemy)

It DOES mean:
- Model the domain, then cut to essential entities for v1
- Check ethics, but don't let perfect be the enemy of good
- Write clean code for fewer things
- Plan then ship, don't plan then plan then plan

---

## Integration Points

### With domain-modeller
Domain modelling often reveals complexity. Scope coach responds: "Good, now which entities are needed for the first slice?"

### With implementation-planner
Implementation plans can grow unbounded. Scope coach forces: "Which steps produce a shippable unit?"

### With ethics-reviewer
Ethics is a constraint, not a scope-expansion tool. Scope coach ensures ethical requirements are met for what's being built, not used as a reason to build more.

---

## Success Criteria

Scope coaching is effective when:
- First versions ship faster
- Features are smaller and more focused
- Analysis leads to action, not more analysis
- "v2" tasks exist in the backlog (proof that scope was cut, not forgotten)
- The user feels unblocked, not restricted