| name | additive-bias-defense |
| description | Inverts burden of proof for code additions. Use when reviewing PRs, planning refactors, or running unbloat to challenge every addition's necessity. |
| alwaysApply | false |
| category | quality-contract |
| tags | ["additive-bias","burden-of-proof","scrutiny","cross-cutting","defense"] |
| dependencies | [] |
| tools | [] |
| provides | {"guidance":["additive-bias-scrutiny","burden-of-proof-verdict"]} |
| usage_patterns | ["plan-review","pr-review","code-refinement","unbloat"] |
| complexity | foundational |
| model_hint | standard |
| estimated_tokens | 800 |
| role | library |
The default answer to "should we add this?" is no.
The burden of proof is on the addition.
Additive Bias Defense
Note (#444): Frontmatter declares provides.guidance, not
provides.contract. The scrutiny questions are consumed by
partner skills (pensive:code-refinement, conserve:unbloat,
imbue:scope-guard) that voluntarily embed them; no validator or
hook in leyline enforces them directly. If a future contributor
adds enforcement, restore the contract label and link the
validator path here.
When NOT To Use
- Removing bloat that already landed (use
conserve:bloat-detector)
- Scoring whether a feature is worth building (use
imbue:scope-guard)
The Problem
LLMs are additive by nature. They reinvent wheels, add
unnecessary complexity, hallucinate issues and modify
tests to justify them, and deviate from priorities. This
contract provides a systemic defense.
The Scrutiny Questions
Applied to every proposed addition (code, files,
abstractions, error handling, configuration):
- Priority alignment: Is this a deviation from the
current priority?
- Criticality: Is it critical to implement at this
juncture?
- Simplicity: Does a simpler or more elegant
solution exist?
- Evidence: What evidence proves this is needed
(not assumed)?
- Consequence: What breaks if we do not add this?
If the proposer cannot answer questions 4 and 5 with
concrete evidence, the addition is unjustified.
Anti-Pattern Detection
| Pattern | Signal | Challenge |
|---|
| Wheel reinvention | New utility/helper overlapping existing code | "Does X already do this?" |
| Hallucinated issues | Fix for a bug with no reproduction evidence | "Show the failing test before the fix" |
| Test manipulation | Test changed to match behavior rather than spec | "Did the spec change, or did you change the test?" |
| Complexity creep | Abstraction introduced for single use case | "Is this the 3rd use, or the 1st?" |
