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: