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:

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)

Step 4: Check Scalability

For each Defer item, verify:

• Does the Keep list block it from being added later?
• Does the current increment create a dead-end that forces a rewrite?

If yes → move that item back to Keep or adjust the design.

If the user asks "will this scale?" — answer honestly based on the code, not hypotheticals.

Step 5: Write the Increment

Co-write a short definition of what to build:

• Goal — one sentence
• Delivers — bullet list of Keep items
• Deferred — bullet list of Defer items (so nothing is forgotten)
• Out — what's dropped and why
• Done when — how to verify it's complete

Write to a file if the user wants. Otherwise just confirm alignment.

How to Cut (not gut)

• Respect existing code. Don't propose replacing what works. Build on it.
• Defer > Drop. Dropping feels permanent. Deferring keeps options open and the user at ease.
• Show the path. When deferring something, briefly note how the current design leaves room for it.
• Be specific. "Defer auth" is vague. "Defer OAuth — use API key for now, auth middleware interface stays the same" is actionable.

What NOT to Do

• Don't add new features while slimming down
• Don't redesign the architecture — work with what's there
• Don't say "just do an MVP" without defining what that means concretely
• Don't cut things the user already built — that's wasted work, not saved scope
• Don't assume the user wants the cheapest option — they want the smallest useful one