# First Principles Review

Use when asked for first-principles or Occam's-razor review, or when high-risk...

- Repository: https://github.com/GanyuanRan/Aegis (1408 stars)
- Category: Marketing
- License: MIT
- Last updated: 2026-10-25
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add GanyuanRan/Aegis --skill first-principles-review -g -a claude-code -y`
Codex: `npx skills add GanyuanRan/Aegis --skill first-principles-review -g -a codex -y`
Cursor: `npx skills add GanyuanRan/Aegis --skill first-principles-review -g -a cursor -y`
Gemini CLI: `npx skills add GanyuanRan/Aegis --skill first-principles-review -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add GanyuanRan/Aegis`

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

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

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

The rest: https://github.com/GanyuanRan/Aegis/blob/HEAD/skills/first-principles-review/SKILL.md