# Scope Cutter

> Takes an ambitious idea and aggressively cuts it down to the smallest version that is still valid, useful, and shippable — a true MVP — killing scope creep before it starts. Use this skill when the user has a big feature or project and says "this is getting big", "what's the MVP?", "help me scope this down", "where do I start", "this feels like too much", or is planning a build that's ballooning. Forces a ruthless distinction between what proves the core hypothesis now and what is genuinely "later".

- Skill: `opelpleple/scope-cutter` (Agent Skill)
- Install (CLI): `npx skillmds@latest add opelpleple/scope-cutter`
- Raw SKILL.md: https://api.skillmd.com/api/skills/opelpleple/scope-cutter/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: opelpleple (https://skillmd.com/u/opelpleple)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/opelpleple/scope-cutter

---


# Scope Cutter

Find the smallest thing that is still true to the idea and could ship this week. Everything else is a "later" until proven otherwise.

## When to use
- An idea or feature list is ballooning past what one person/sprint can ship.
- The user asks "what's the MVP?" or "where do I start?"
- Planning a build and wanting to de-risk by shipping something small first.
- A roadmap where everything is labeled "must-have."
- Procrastination born of a project feeling too big to begin.

## When NOT to use
- Safety-critical or compliance work where cutting corners is dangerous (scope is the requirement).
- The "small version" would be misleading or actively harmful as a half-thing.
- The user has already shipped an MVP and now legitimately needs to scale it.
- Pure research/exploration with no shippable artifact yet.

## The method
1. Name the core hypothesis in one sentence: "This is worth building if [the one thing we believe] is true." Everything serves testing that.
2. List every feature/requirement the user has in mind — get it all out.
3. Sort each into exactly three buckets: Must (the idea is meaningless without it), Should (real value, not essential to prove the hypothesis), Later (everything else). Force a true split — if everything is "Must," re-ask "would the very first user still get value without this?"
4. Attack the Musts. For each, ask: "Can this be faked, manual, smaller, or hardcoded for v1?" A spreadsheet, a manual step, or one hardcoded case often replaces a system.
5. Define the walking skeleton: the thinnest end-to-end slice that a real user could actually use and that proves the hypothesis.
6. Write the explicit NOT list — what v1 deliberately does not do. This is the scope's fence; naming it prevents creep.
7. Sanity-check shippability: could this ship in days, not months? If not, cut again.
8. Output: the one-sentence hypothesis, the v1 slice, the NOT list, and the first thing to build.

## What good looks like
- The v1 is embarrassingly small and still proves the core hypothesis.
- There's an explicit, written list of what v1 will NOT do.
- "Manual for now" or "hardcoded for now" appears at least once.
- The user can start building today and a real user could touch it within days.
- Cut features are parked in "Later," not deleted — the ambition survives, the v1 shrinks.

## Anti-patterns
- "MVP" that's actually a full product with a smaller logo.
- Everything marked Must; nothing genuinely cut.
- Building infrastructure for scale no one has yet ("we'll need sharding").
- Cutting so hard the result no longer tests the hypothesis (that's not an MVP, it's nothing).
- Skipping the NOT list, so scope quietly creeps back in.

## Example
Idea: "A platform where users track habits, with social feeds, streaks, AI coaching, gamification, and integrations with five wearables."
- Core hypothesis: "People will return daily to log a habit if it's frictionless."
- Must: log a habit, see today's status. Should: streaks, history. Later: social, AI, gamification, wearables.
- Attack the Musts: no accounts yet — one hardcoded user. No DB schema for "habits" plural — start with one habit, one button.
- Walking skeleton: a single page with one button, "Did you do it today? ✓", and a count of days done. Stored locally.
- NOT list: no login, no social, no AI, no multiple habits, no integrations.
- First thing to build: the button and the daily counter. Ships this week; tells you if anyone comes back tomorrow — which is the only thing that matters yet.