/first-principles-review

name: first-principles-review
description: "Use when asked for first-principles or Occam's-razor review, or when high-risk decisions involve competing constraints, fallback growth, duplicate owners, or architecture direction risk. Ordinary bug fixes stay on the fast path."

First Principles Review

Purpose

Use this as a lightweight decision review before another Aegis workflow makes a directional choice. It is a compositional skill, not a standalone workflow.

Do not replace `brainstorming`, `systematic-debugging`, `writing-plans`, `requesting-code-review`, or `verification-before-completion`. Use it to clean the decision surface those skills will act on.

When this review materially changes the direction, surface `Aegis Visibility` in natural prose: name the first principle, dropped assumption, smallest sufficient path, or owner / retirement falsifier that changed the decision. Keep it advisory and task-specific; do not turn the lens into approval authority or a generic skill trace.

Use When

• The user asks for first principles, first-principles thinking, or Occam's

razor.

• A design, plan, or fix has multiple plausible paths and unclear selection

criteria.

• The task has ambiguous goals, competing constraints, or product/architecture

direction risk.

• Debugging is drifting into repeated fixes, fallback growth, duplicate owners,

consumer-side patches, or "just add another branch" reasoning.

• A review finds that the implementation may be locally correct but directionally

wrong.

Do Not Use

• Simple Q&A, status checks, tiny wording/config edits, or clearly bounded

single-owner changes.

• Mechanical execution of an approved plan unless a new directional conflict

appears.

• As a required step for every task, every turn, or every TDD cycle.

Five-Line Review

Check the agreed goal for omissions and unsupported additions, including quantities, exclusions, relationships and conditions. Review criteria come from authorized requirements; this lens cannot add them or veto an authorized transformation merely because its form differs.

Answer only what is needed, usually in five short lines:

First Principle: What irreducible outcome must this satisfy?
Non-negotiables: What constraints cannot be broken?
Assumptions to Drop: What is habit, inherited shape, or unproven preference?
Smallest Sufficient Path: What is the least complex path that satisfies the first principle?
Escalation Signal: What finding would require spec/design/architecture review?

When the direction depends on a new mechanism or an unfamiliar domain, insert one optional line between path and escalation:

Known Prior Art: proven external pattern worth adopting or adapting to project
constraints (cite source), or `unknown` when precedent cannot be verified here

For repairs and optimization, require evidence for the cause or bottleneck before retaining a solution. Resolve unknowns that could change the choice; experiments may precede that decision. "Smallest" means the least intervention covering relevant causal paths while preserving required behavior, not the smallest diff or fewest owners. Independent causes may need separate repairs; a shared carrier does not prove a shared cause. Use systematic debugging when causal coverage is unresolved; no extra checklist is required for a settled case:

Minimality Check:
- Smallest textual diff:
- Correct owner:
- Bug class fixed:
- New branch/fallback added:
- Old path retired or scheduled:
- Verdict: sufficient repair | local patch | needs first-principles review

Decision Hygiene Review

Use this escalation only when a design, fix, or plan needs endorsement before it is written into a spec or implementation plan.

Escalate from the five-line review when any of these risk signals appear:

• multiple plausible paths and no clear selection criteria
• a new owner, duplicate owner, fallback, adapter, or compat-only carrier
• an old path that may need delete-first handling or a retirement trigger
• an unverified assumption that the proposal depends on
• user language such as "more elegant", "long-term stable", "first

principles", or "Occam"

• a plan could encode the wrong owner, abstraction, compatibility boundary, or

retirement schedule

• an existing object, behavior, responsibility, contract, or relationship may

be reinterpreted, narrowed, replaced, or retired, and the proposal could lose a legitimate role or explicit reference while removing invalid authority

Use this compact shape:

First-principles invariants:
- Non-negotiable goal:
- Non-negotiable constraints:
- Historical assumptions to delete:

Bounded preservation reminder:
- Evidence-backed behavior that must remain correct:
- Highest-risk counterexample:
- Material unknown / uninspected surface:
- Known explicit anchors / upstream-downstream refs and disposition:
- Role-before-value ambiguity, if any:

Owner / retirement matrix:
- New canonical owner:
- Old owner:
- Compat-only carrier:
- Delete-first / retirement trigger:

Falsification matrix (evaluate in order; stop at the first failing gate):
- Gate 0 - Premise evidence (stage-graded): design stage accepts spec/logic
  refs; implementation/runtime stage requires log, telemetry, or test
  evidence. No evidence -> park as watch-listed, do not enter value
  evaluation.
- Gate 1 - Decidability: no obtainable evidence to judge it -> park as a
  watched falsifier, do not act.
- Gate 2 - Value (any one): lowers future fix probability / shrinks the
  solution set / exposes a missing actionable acceptance criterion / the same
  broken assumption is reused elsewhere. Passing here still requires
  gates 3-5.
- Gate 3 - Cost match: change cost vs business priority, costed at the
  current stage; a valid but deferred counterexample is recorded in the owner
  doc, never parked orally.
- Gate 4 - Goal regression: the constrained solution still meets the original
  goal; re-read the accepted-constr