| name | via-negativa |
| description | Improve by removing problems rather than adding solutions — use when a system or process has accumulated complexity and improvement by addition has hit diminishing returns |
| argument-hint | [system, process, or situation to improve] |
| user-invocable | true |
| license | MIT |
Instead of asking "what should we add?", ask "what should we remove?"
Often the fastest path to improvement is eliminating what's harmful,
unnecessary, or creating friction. Subtraction before addition.
1. Describe the current state of the system or situation
2. List everything currently present (features, steps, dependencies, rules)
3. For each element, ask: "Would things improve if this were removed?"
4. Identify the top 3-5 candidates for removal
5. For each candidate, assess: What breaks if we remove it? What improves?
6. Propose the removal plan (what to cut, in what order)
7. Check: does the simplified version still achieve the core purpose?
<output_format>
Via Negativa Analysis: [Topic]
Current State
[Brief description of what exists today]
Removal Candidates
| Element | Remove? | What improves | What breaks |
|---|
| [Item] | Yes/No | ... | ... |
Recommended Removals
- [What to remove and why]
- ...
Simplified Version
[What remains after removals — does it still serve the core purpose?]
What NOT to Remove
[Elements that seem removable but are load-bearing]
</output_format>
## Via Negativa Analysis: Deployment Pipeline
Current State
Deployment pipeline has 12 steps: lint, unit test, integration test, build Docker image, push to registry, deploy to staging, run smoke tests, wait for manual approval, deploy to canary, monitor for 30 minutes, deploy to production, run production smoke tests.
Removal Candidates
| Element | Remove? | What improves | What breaks |
|---|
| Manual approval gate | Yes | Deploy time drops 2-4 hours (waiting for approver) | Nothing — canary + smoke tests catch issues automatically |
| Separate lint step | Yes | 2 min saved — linting runs in IDE and pre-commit hooks already | Nothing — issues caught earlier in workflow |
| Staging environment | Yes | Eliminates a flaky environment that causes 30% of pipeline failures | Need canary to be reliable (it already is) |
| 30-min canary monitor | No | — | Removing loses the safety net for slow-burn issues |
| Integration tests | No | — | Only place we catch cross-service contract breaks |
Recommended Removals
- Manual approval gate — replaced by automated canary monitoring, which is more consistent than a human glancing at dashboards
- Separate lint step — redundant with pre-commit hooks; lint errors haven't reached CI in 4 months
- Staging environment — flaky environment causes more failed deploys than it prevents; canary on production traffic is a better signal
Simplified Version
9 steps: unit test, integration test, build, push, deploy canary, monitor 30 min, deploy production, smoke test. Still catches regressions, still has gradual rollout, but 30% faster and no flaky staging.
What NOT to Remove
The 30-minute canary monitor looks like wasted time but caught a memory leak last month that smoke tests missed. It's load-bearing.
Key Instructions
- Always assess whether a removal candidate is load-bearing before proposing it; the "What NOT to Remove" section must be completed, not skipped.
Anti-Pattern Guards
- Removing without checking dependencies — an element may look unused but be load-bearing for edge cases; step 5 must assess what breaks, not just what improves.
- Using via negativa to justify rewrites — subtraction should be incremental; removing everything at once and rebuilding is not via negativa, it's a rewrite.
Handoff
Chainable to: occams-razor (to confirm the simplified version is the most parsimonious one that still works), first-principles (to verify the core purpose before deciding what's essential)
