About to add a feature/layer/process to fix a problem. First ask what to remove instead — subtraction is often more robust than addition. Use for simplification and complexity reduction.
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/thinking-via-negativa
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
About to add a feature/layer/process to fix a problem. First ask what to remove instead — subtraction is often more robust than addition. Use for simplification and complexity reduction.
📊 Stats
Stars863
Forks126
LanguageJavaScript
LicenseMIT
📦 Ships with thinking-skills
</> SKILL.md
thinking-via-negativa.SKILL.md
---name: thinking-via-negativa
description: About to add a feature/layer/process to fix a problem. First ask what to remove instead — subtraction is often more robust than addition. Use for simplification and complexity reduction.
---# Via Negativa
## Overview
Via Negativa, articulated by Nassim Taleb in "Antifragile," is the principle that improvement often comes from subtraction rather than addition. We're biased toward adding (features, processes, complexity) when removing (bugs, friction, unnecessary work) often provides more value with less risk.
**Core Principle:** Focus on what to remove, not what to add. Subtraction is more robust than addition.
## When to Use
- System simplification
- Process improvement
- Feature prioritization (what NOT to build)
- Performance optimization
- Reducing technical debt
- Personal productivity
- Decision-making (what to avoid)
- Code review (what to delete)
Decision flow:
```
Trying to improve something?
→ First instinct is to add? → yes → PAUSE, CONSIDER SUBTRACTION
→ Can you achieve the goal by removing instead? → yes → REMOVE FIRST
→ Is current complexity necessary? → no → SIMPLIFY VIA NEGATIVA
```
- **Never subtract a load-bearing control, test, validation, guard, or safety check** just because it's "extra complexity." Removal is only low-risk when the thing is genuinely unused or redundant. A test you don't understand, an error handler, a rate limiter, an auth check, or a retry are presumed load-bearing — prove they're dead before deleting. The whole "subtraction is safe" claim holds only for things that provide no benefit.
- **Not when the addition is genuinely required** to meet a real, demonstrated need. Via negativa fights the *reflex* to add; it doesn't forbid all addition.
- **Don't delete to hit an aesthetic "less is more" target** without checking what each element does — confirm non-use with evidence (usage data, dead-code analysis, removing it in a branch and watching), not assumption.
## Trigger Card
When about to add a feature, layer, or process to fix a problem:
1. **Ask: "What can I remove instead?"** — before adding, scan for something to subtract that would have the same or better effect.
2. **Identify the highest-cost, lowest-usage candidates** — what's consuming resources (code, process, dependency) but delivering the least value?
3. **Remove the simplest one first** — subtraction is asymmetric: removing is safer than adding because you can always add back. Test by removing it in a branch and seeing what breaks.
Don't delete to hit an aesthetic target without checking what each element does — confirm non-use with evidence, not assumption. If the addition is genuinely required for a real, demonstrated need, add it — via negativa fights the reflex to add, not all addition.
## The Via Negativa Process
### Step 1: Identify What to Eliminate
Instead of "What should we add?", ask:
```
- What's not working that we should remove?
- What's causing harm we should stop?
- What's unnecessary complexity we should eliminate?
- What's outdated that we should delete?
```
### Step 2: Catalog Candidates for Removal
List elements that might be subtracted:
```markdown
## Candidates for Removal
Code:
- Dead code (unreachable)
- Deprecated features (still running)
- Unused dependencies
- Redundant abstractions
Process:
- Meetings that don't produce decisions
- Approval steps that don't add value
- Reports no one reads
- Alerts no one acts on
Features:
- Low-usage functionality
- Legacy features maintained "just in case"
- Edge cases that complicate the core
```
### Step 3: Evaluate Impact of Removal
For each candidate:
```markdown
| Element | Usage | Maintenance Cost | Risk of Removal | Value of Removal |
- Old things that have survived removal attempts are robust
- New additions are fragile, unproven
- Subtracting recent additions is lower risk than adding new things
## Verification Checklist
- [ ] Asked "what can we remove?" before "what should we add?"
- [ ] Identified candidates for removal in multiple categories
- [ ] Evaluated usage/value of removal candidates
- [ ] Planned gradual removal with monitoring
- [ ] Considered second-order effects of removal
- [ ] Resisted the urge to add when subtraction would work
## Key Questions
- "What can we remove instead of add?"
- "What would happen if we stopped doing this?"
- "What's the maintenance cost of this existing thing?"
- "Is this complexity earning its keep?"
- "What should we stop doing?"
- "What would we not build if starting from scratch?"
## Taleb's Wisdom
"The first principle of iatrogenics: we do not need evidence of harm to claim that a treatment is harmful; we need evidence of benefit to claim it is not harmful."
Applied to software: We don't need evidence that a feature is actively harmful to remove it; we need evidence it provides benefit to keep it.
"Via Negativa is more powerful than Via Positiva: omission does less harm than commission."
Removing is safer than adding. Every addition has unknown side effects. Removal of recent additions reverts to a known-good state. When in doubt, subtract.
"The best way to live is to maximize the number of decisions not made."
Reduce decisions through simplification. Fewer features = fewer decisions to make. Fewer processes = fewer coordination points. Simpler is more robust.
