first-principles-review

# 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...