Use when search or investigation could run forever. Set an explicit good-enough threshold first, then stop at the first option that clears it.
1 installs
Coding
thinking-via-negativa
Try itUse when the reflex is to add a feature, layer, or process. Prefer removing harmful or nonessential elements first, with an irreversibility guard before deletion.
What it does
Use when the reflex is to add a feature, layer, or process. Prefer removing harmful or nonessential elements first, with an irreversibility guard before deletion.
The skill document
Via Negativa
Improve by subtraction before addition. Prefer removing harm, waste, and nonessential complexity; add only when a demonstrated need remains after removal candidates are exhausted.
When to Use
- About to add a feature, abstraction, dependency, process, or control to fix a problem.
- Simplifying a system or workflow where complexity is the tax.
- Prioritizing by deciding what not to keep, build, or maintain.
- Performance or reliability work where eliminating a bad path beats bolting on mitigation.
When NOT to Use
- Load-bearing controls: auth, validation, tests, rate limits, retries, safety checks — presume necessary until proven dead.
- A demonstrated requirement that cannot be met by removal or simplification.
- Aesthetic minimalism without evidence of non-use or net harm.
- Irreversible deletion without a rollback path when impact is unknown.
Procedure
- Pause the add reflex. State the goal and the proposed addition in one line.
- Ask the subtraction question first. List what could be removed or stopped to achieve the same goal with less surface area.
- Catalog candidates with evidence. Prefer unused, redundant, high-cost/low-value, or harmful elements. Require usage, call-graph, metrics, or experiment evidence — not taste.
- Apply the irreversibility guard. Classify reversible vs hard-to-restore; identify dependents; refuse deleting unproven mystery guards. Plan staged removal or flag when risk is non-trivial.
- Remove the safest high-value candidate first. Subtract, monitor, and verify absence of needed behavior before the next removal.
- Add only if the goal still fails. If subtraction cannot meet the need, add the minimum change and record why removal was insufficient.
- Stop when the goal is met by absence, or remaining candidates fail the irreversibility/evidence bar and a minimal addition is justified.
Stop condition: Goal achieved via removal, or residual need documented after evidence-backed subtraction failed.
Output
Goal:
Proposed add (if any):
Removal candidates:
Action: remove | staged remove | add minimal because
Verification plan:
Do-not-touch:
Verification
- Falsify if something was deleted without non-use/harm evidence, or a safety control was removed as "complexity."
- Falsify if an addition shipped without a prior subtraction pass on the same goal.
- Over-application guard: do not delete for line-count or purity when the element is load-bearing or the need is demonstrated.
Related skills
Use when a selective defect needs IS/IS-NOT difference analysis or a consequential option choice needs must/want weighting and adverse-consequence comparison.
1 installs
Before heavy deliberation, classify the decision as cheap or costly to undo; decide two-way doors fast and stage one-way doors to preserve options.
1 installs
Deciding what to build or why adoption fails. Recover the progress users hire a solution for under a circumstance, then rank by outcome and competing workarounds.
1 installs
Use when longevity of a non-perishable option matters. Treat survival duration as a remaining-life prior, then check domain drift before favoring the proven.
1 installs
When a constraint is treated as fixed, separate physics from convention, keep only independently supported primitives, and rebuild the simplest solution that satisfies real constraints.
3 installs