slim-down

Slim Down — Cut Scope, Keep Scale

Take a plan or design that's grown too big and cut it down to one increment — the smallest step that delivers value and doesn't block future growth.

Make it work before make it great — but never paint yourself into a corner.

When to Use

• When a plan or design feels over-engineered
• When user says "this is too much", "what do I actually need first?", "MVP"
• Any time scope has ballooned beyond what's practical to build next

Core Principle

Cut scope, not corners. Remove features, not quality. The increment should be small but extensible — no dead-ends, no "throw it away later."

Workflow

Step 1: Read the Ground

Before cutting anything, understand what already exists:

• Read the current codebase — what's built, what patterns are in use
• Read the plan/grill result/spec that needs slimming
• Identify what's new work vs already done or partially done

Summarize in a short block:

• Current state — what exists today (2-3 lines)
• Full goal — what the plan wants to achieve
• Gap — what's missing between current state and full goal

Step 2: Identify the Core

Ask: "What is the one thing this plan must deliver to be useful?"

Draft a single sentence describing the core value. Show it to the user. This is the anchor — everything else gets judged against it.

Step 3: Sort Into Keep / Defer / Drop

Take every item from the plan and sort it:

	Criteria
Keep	Required for the core to work. Can't ship without it.
Defer	Valuable but not needed yet. Design so it can be added later.
Drop	Nice-to-have, speculative, or solves a problem that doesn't exist yet.

Show the table. Let the user move things around.

Rules for sorting:

• If it's only needed at 10x scale → Defer
• If it handles an edge case that hasn't happened → Defer
• If removing it doesn't break the core → Defer
• If it adds a new abstraction layer "for flexibility" → Drop unless proven needed
• If current code already handles it partially → Keep (finish, don't redo)