| name | build-subtractive |
| description | Use when facing an "I'll know it when I see it" problem — the right answer can't be specified up front but can be recognized on sight — or when the user is stuck choosing between approaches and incremental refinement of a single candidate keeps stalling. Also use whenever the user invokes "subtractive", "sculptural", "carve", "over-generate then cut", or "build 3 and delete 2". |
Subtractive Build
Generation is cheap; taste is scarce. This methodology spends compute on breadth so the human's (and your) judgment operates on real artifacts instead of speculation. You do not design the solution — you generate a population of rough solutions and carve the final one out of them by deletion. Deleting is the design act. Treat every deletion as a decision worth recording.
The core discipline
Two rules override everything else:
- During GENERATE, no polishing. Variants must be rough, complete, and different from each other. A variant that is 90% identical to another variant is wasted compute. Divergence is the deliverable.
- During CARVE, no new construction. You may delete, merge, and glue. You may not add capabilities that no variant possesses. If carving reveals a missing capability, that's a finding — record it, finish the carve, then run a targeted micro-generate for the gap.
Builders (human and model alike) are wired to keep what they make. This skill exists to counteract that wiring. When you feel reluctance to delete a variant with something clever in it, that reluctance is the signal you're doing the method correctly — extract the clever fragment into QUARRY.md (see below) and delete the variant anyway.
Workspace layout
project/
├── SUBTRACT.md # method state file (phases, decisions, deletion log)
├── QUARRY.md # fragments worth saving from deleted variants
├── variants/
│ ├── v1-<one-word-thesis>/
│ ├── v2-<one-word-thesis>/
│ └── v3-<one-word-thesis>/
└── final/ # created only during CONSOLIDATE
Name each variant with a one-word thesis (e.g. v1-eager, v2-lazy, v3-tableless). If you cannot name a variant's thesis in one word, it doesn't have one — redesign it before building it.
Phases
1. FRAME (short — do not linger)
Write into SUBTRACT.md:
- The prompt: one paragraph on what the thing must do.
- Recognition criteria: how you'll know the right answer when you see it. These are not specs — they're qualities ("feels obvious to extend", "the hot path reads top-to-bottom", "config surface under 5 knobs"). 3–6 of them.
- Variant count and axes of divergence: default 3 variants; 5 if the space feels wide. Pick divergence axes explicitly (e.g. data model, control flow style, dependency posture) so variants differ structurally, not cosmetically.
- Budget: a per-variant effort cap (time or scope). Roughness is enforced by budget, not willpower.
2. GENERATE
Build every variant to demonstrable — it runs, it exercises the core path, it can be judged. Skip: error handling breadth, edge cases, docs, tests beyond a smoke check, naming polish.
- Build variants in isolation. Do not let learnings from v1 leak into v2's structure — cross-pollination collapses divergence. (In multi-session Claude Code, one session per variant is ideal; if single-session, write each variant without re-reading the others.)
- When a variant wants to converge toward another, push it further along its own thesis instead.
- Log completion of each variant in
SUBTRACT.md with one sentence: what its thesis bought and what it cost.
3. CARVE
This is the design phase. Read all variants side by side against the recognition criteria, then delete.
- Delete whole variants first. For each deletion, write one line in the
SUBTRACT.md deletion log: DELETED v2-lazy — thesis buys nothing at this scale; laziness complexity never pays off. The log line is mandatory; it's where the design rationale accumulates.
- Quarry before you delete. Any fragment (a function, a data shape, an idea) from a doomed variant that's better than the survivor's equivalent goes into
QUARRY.md with its source and why it's better.
- Then carve within the survivor. Delete speculative structure, unused flexibility, any code serving a requirement nobody stated. Aim to remove 20–40% of the surviving variant — if nothing is removable, GENERATE was too polished.
- The survivor may be a chimera: one variant's skeleton with quarried organs from the others. That's a normal and good outcome.
4. CONSOLIDATE
Copy the carved survivor into final/, apply quarried fragments, then bring it to real quality: error handling, tests, naming, docs. Only now is polish legal. Delete variants/ when done — keep SUBTRACT.md and QUARRY.md as the permanent design record.
Judging without a human in the loop
When carving autonomously, score each variant against each recognition criterion (pass / partial / fail) in a table in SUBTRACT.md before deleting anything. If two variants tie, prefer the one with less code. If the tie survives that, prefer the one whose thesis you can state most sharply — a sharp thesis is easier to maintain than a mild one.
Failure modes
- Premature convergence: variants that are the same idea in different clothes. Caught by the one-word-thesis test at FRAME.
- Attachment: keeping a variant because it was expensive. Sunk cost is not a recognition criterion.
- Carve creep: "just adding one small thing" during CARVE. Adding is a phase violation — record the gap, finish carving.
- Skipping the log: an unlogged deletion loses the rationale, which is the whole product of this method besides the code.
Claude Code mechanics & siblings
- Isolation is by construction, not willpower: dispatch one blind subagent per variant, each prompt containing ONLY that variant's thesis and the shared prompt — never the other variants. Use worktree isolation if variants would touch overlapping files. "Write each variant without re-reading the others" is the single-context fallback, not the default.
- State files: if the project routes working files to a directory (e.g.
.ai/), put SUBTRACT.md and QUARRY.md there (.ai/build/); variants/ and final/ live wherever the project keeps code.
- Routing: shaping and planning stay upstream (intent-shape, mega-brainstorm, mega-plan); subtractive replaces the execution strategy for the component it governs. Siblings — tournament when "better" is measurable before building; dialectical when exactly two philosophies contest; annealing for ridged spaces worked across many sessions.
When NOT to use this
Well-understood shapes (CRUD endpoint, known refactor) — the linear method is cheaper. Hard deadlines that can't absorb 3x generation cost. Problems where variants can't be judged without long soak time.
