/foundational-review

name: foundational-review
description: "Run the foundational review chain on a project BEFORE an irreversible decision (version freeze, format/schema/spec tag, public API or repo flip, major re-scope, or a 'should we keep building this' moment). Verdict-led review → design spec → cold-executable plan → composed /prospect → paste-ready executor kickoff. Optional --extend runs the system-design extension loop. REQUIRES an irreversible-decision anchor — no decision named → redirect to /prospect (plan pre-mortem) or /readiness-audit (surface audit). Triggers: '/foundational-review <scope-root>', '/foundational-review <scope-root> --decision \"<the irreversible decision>\"', '/foundational-review <scope-root> --extend', 'foundational review', 'review this at the foundations', 'is this the right thing built the right way'. (Code port — ADR-094.)"

/foundational-review — "Is this the right thing, built the right way?"

Run a repeatable, model-agnostic review of a project at the FOUNDATIONS — problem–solution fit, architecture soundness, product coherence — and convert the findings into a prospect-hardened, cold-executable plan with owner routing. This is the productized form of the foundational review chain (the canonical process doc this skill reads at Step 1).

This skill is **orchestration + artifact templates only**. The substance — the A–F review questions, the operating rules, the failure-mode library, the pairing contract — lives in the canonical process doc, which Step 1 reads in full. Do not reproduce that doc's content from memory; read it live every run so the chain evolves in one place.

**What this is NOT** (the process doc opens with this — internalize it):

• **Not a code review** — code review asks "are these changes correct?" on a diff. This asks "should this shape exist?" on a decision.
• **Not a readiness audit** — `/readiness-audit` checks a surface against a checklist and produces a findings list. This produces a VERDICT resting on named PREMISES plus the full execution handoff. Siblings, not substitutes (see the pairing contract in the Step 1 doc and Step 0's pairing check).
• **Not a retrospective** — `/retrospect` validates shipped work backward. This judges a standing architecture/product forward, before an expensive-to-undo step.

When to use

Run it before any IRREVERSIBLE decision — the anchor:

• A version freeze or stable-contract claim
• A format / schema / spec tag (e.g., a `v1.0` spec freeze)
• A public API surface or a repo public-flip
• A major re-scope, pivot, or "should we keep building this at all" moment

**No irreversible decision named → do not run this chain.** Redirect:

• A plan that's about to execute → `/prospect`
• A surface to check clean/legal/consistent for shipping → `/readiness-audit`
• Already-shipped work to validate backward → `/retrospect`

Step 0: Invocation Block

Parse `<scope-root>` (first positional), `--decision "<text>"`, and `--extend`. Then assemble the invocation block. If args are thin, collect interactively — **one ask at a time**:

Invocation:
  Scope root:           <path — the project/workspace under review>
  Read-first:           <docs to read before judging: CLAUDE.md, PROGRESS.md, specs, prior audits>
  THE irreversible decision:  <the single expensive-to-undo step this review gates — REQUIRED>
  Section-F inputs:     <strategy/positioning/licensing docs; mark CONFIDENTIAL ones>
  Constraints:          <read-only repos, build rules, no-push, team-owned repos needing tickets>
  Reviewer model:       <highest-ceiling available; see Model Routing below>
  Extend?:              <yes if --extend — runs the system-design extension loop after Step 6>

**Hard gate — the decision anchor.** If no irreversible decision can be named (the `--decision` arg is absent AND the user can't state one when asked), STOP and redirect:

> This chain is decision-anchored — it needs one expensive-to-undo step to anchor the verdict and the irreversibility inventory. You haven't named one. Did you mean: > 1) `/prospect <plan>` — pre-mortem a plan that's about to execute > 2) `/readiness-audit <scope-root> --for "<event>"` — audit a surface for ship-readiness > 3) I'll name the irreversible decision now: <reply with it>

Do not invent a decision to keep the chain running.

**Pairing check.** If THE irreversible decision is a SHIP / FREEZE / PUBLIC-FLIP, the canonical pairing rule says run BOTH the audit (for the surface) and the chain (for the decision). Ask:

> This decision is a ship/freeze/flip. The pairing contract recommends running `/readiness-audit` first (cheaper, produces the evidence base the review can lean on). Run `/readiness-audit <scope-root> --for "<event>"` now, then resume this chain? (`y` / `n` / `already-have-one`)

On `y`, invoke `/readiness-audit` via the `Skill` tool, then resume at Step 1 with the audit as admissible evidence (per the composition contract — the review re-derives every inherited claim, never trusts the audit's attributions/counts without a fresh sweep).

Model Routing

• **Reviewer = the highest-ceiling model available** (escalate to the top tier only when the decision is extreme-stakes; the default top model otherwise). The ceiling is spent on alternatives steelmanning (§A), portfolio/product judgment (§F), and the irreversibility inventory. **The default model can run the full chain** — it compensates with stricter evidence-sourcing in the /prospect passes.
• **Executor = the default model by default.** Every plan task (Step 4) carries `OWNER: <default model>` unless its *execution* needs extreme judgment — justify any top-tier owner in one line, or it's rewritten to the default.
• **Gate owner = the human.** Anything needing sign-off becomes a named gate `G-A..` in the spec (Step 3), never an inline assumption.
• **Effort ladder (when the reviewer is the top-tier model):** default `xhigh` for every substantive review — these passes are semi-agentic (read files, trace seams) an