/additive-bias-defense

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):

1. **Priority alignment**: Is this a deviation from the current priority? 2. **Criticality**: Is it critical to implement at this juncture? 3. **Simplicity**: Does a simpler or more elegant solution exist? 4. **Evidence**: What evidence proves this is needed (not assumed)? 5. **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?" | | Priority deviation | Work not traceable to current task/spec | "Which requirement does this serve?" | | Gold plating | Error handling or flexibility beyond need | "What breaks without this?" |

Burden of Proof Verdict

After applying scrutiny questions and anti-pattern detection, produce a verdict:

| Verdict | Meaning | Action | |---------|---------|--------| | `justified` | Evidence supports the addition | Proceed | | `needs_evidence` | Plausible but unproven | Provide evidence or remove | | `unjustified` | No evidence, likely bias | Remove or justify |

Integration Contract

Review-oriented skills MUST consult this contract by:

1. Applying the 5 scrutiny questions to each addition 2. Scanning for the 6 anti-patterns 3. Producing a burden-of-proof verdict 4. Including the verdict in their output

Consuming Skills

| Skill | Integration Point | |-------|-------------------| | `attune:war-room` | Prosecution Counsel role uses scrutiny questions | | `sanctum:pr-review` | Every added file/function challenged | | `pensive:code-refinement` | Refactors pass "3rd use" test | | `conserve:unbloat` | Findings feed removal candidates | | `attune:mission-orchestrator` | Plan sections scanned before user review | | `imbue:justify` | Scrutiny questions extend audit protocol |

Related Skills

• `imbue:karpathy-principles` - "Simplicity First" and "Surgical Changes" principles invoke this contract from a higher-level four-principle synthesis
• See `docs/quality-gates.md#skill-level-quality-gate-composition` for the full gate-skill federation graph

The Subtraction Principle

> Rely less on AI and initial lines of thinking. > Challenge yourself to think of a more elegant > implementation or a simpler solution.

Before accepting any addition, ask: "Could I achieve this by removing code instead of adding it?" If yes, prefer the subtractive approach.

Exit Criteria

• [ ] All 5 scrutiny questions applied to every proposed addition;

questions 4 (evidence) and 5 (consequence) answered with concrete evidence, not assumptions

• [ ] All 6 anti-patterns scanned (wheel reinvention, hallucinated

issues, test manipulation, complexity creep, priority deviation, gold plating); any match named with the pattern label

• [ ] A burden-of-proof verdict produced for each addition:

`justified`, `needs_evidence`, or `unjustified`; the verdict appears in the consuming skill's output

• [ ] Subtraction principle applied: at least one check for

"could this be achieved by removing code instead?" before accepting any net-positive line-count change