Role viewpoint scope coach

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