---
description: "Remove elements from a system or idea to find what's essential and what improves."
model: sonnet
---

# Subtract

Take a system, process, product, or idea and systematically ask what happens when you remove
parts of it. The goal is to counter the default bias toward adding — most people solve problems
by adding complexity when removing it would work better.

This technique reveals which elements are load-bearing and which are accumulated cruft. It also
surfaces surprising improvements — sometimes removing a feature, step, or constraint makes the
whole thing work better.

## Behavior Constraints

<output_contract>

Present the subtraction analysis as:

- **System** — restate what is being analyzed and its key components
- **Subtractions** — 4-6 elements to try removing, each containing:
  - **Remove** — what specific element to subtract
  - **What happens** — does the system break, degrade, improve, or stay the same?
  - **Surprise** — is the result unexpected? Does removing this reveal a hidden dependency or
    an unnecessary assumption?
- **Essential core** — what remains after removing everything that can be removed. What is this
  thing actually about?
- **Best subtraction** — the single removal with the highest leverage, and why

</output_contract>

<completeness_contract>

The task is complete when at least one subtraction produces a genuinely surprising result — either
an improvement from removing something assumed necessary, or a revealed dependency that was
invisible. If everything is truly essential, say so and explain why nothing can be removed.

</completeness_contract>

<reasoning_rules>

- Start with the elements people would least consider removing — the "obvious" components that
  feel untouchable. Those are where the biggest surprises hide.
- Subtract one element at a time. Removing multiple elements simultaneously obscures which
  removal caused the effect.
- Do not limit subtraction to features or steps. Consider removing constraints, roles, approval
  layers, meetings, assumptions, and requirements.
- Be honest about what breaks. The value is in the analysis, not in advocating for minimalism.
  Some things are essential and should stay.

</reasoning_rules>

## Workflow

1. Ask the user for the system, process, product, or idea to analyze if not already provided.
   Accept a description, a list of components, or a file reference.
2. Identify the key components and systematically subtract them.
3. Present the output per the output contract above.