/readiness-audit

name: readiness-audit
description: "Audit a surface against a checklist to answer 'is it clean/legal/consistent to ship for THIS event?' — the recurring sibling of /foundational-review. Parallel exploration per surface, controller re-verification of every load-bearing claim, then tiered evidence-celled findings and a phased remediation plan (findings triage to phases, NOT a shipping list). Read-only probes only. No irreversible-decision anchor required (contrast /foundational-review). Triggers: '/readiness-audit {scope-root} --for \"{event}\"', '/audit-ready', 'readiness audit', 'release-readiness audit', 'is this ready to ship/publish/hand over', 'public-release audit'. (Code port — ADR-094.)"

/readiness-audit — "Is it clean / legal / consistent to ship?"

A checklist-against-a-surface audit that recurs, needs no irreversible-decision anchor, and answers "is it ready to ship for THIS event," not "should this shape exist." The companion format is canonicalized in the **"Companion format: the readiness audit"** section of the foundational review chain process doc (read at Step 1).

This skill is **orchestration + artifact templates only**. The format spec and the pairing contract live in the canonical process doc, which Step 1 reads. Do not reproduce them from memory.

**Sibling of `/foundational-review`** — audit = recurring, checklist-shaped, surface-anchored; chain = per-decision, verdict-shaped. When the event is a SHIP / FREEZE / PUBLIC-FLIP, the pairing contract says run BOTH: this audit for the surface, the chain for the decision (audit first — cheaper, produces the evidence base). Step 8 surfaces that pairing.

When to use

• Before a release, a public-repo flip, a handover, or any "is this ready for X" moment that's about the *surface* (clean, legal, consistent), not the *shape*.
• As the recurring instrument — re-runnable whenever the surface changes; no decision anchor needed.

If the question is "should this shape exist / is this the right thing built the right way" before an expensive-to-undo step → use `/foundational-review`. If it's a plan about to execute → `/prospect`.

Step 0: Inputs

Parse `<scope-root>` (first positional) and `--for "<event>"`. If thin, collect interactively:

Inputs:
  Scope root:   <path under audit>
  Ready for WHAT:  <the event: public release | repo public-flip | handover | v1.0 tag | …>
  Locked decisions:  <any already-decided constraints that become audit premises>
  Inherited audits:  <prior audits whose findings/claims this one re-derives, never trusts>

"Ready for WHAT" is the frame that makes a finding a blocker vs. a nice-to-have — get it explicit before exploring.

Step 1: Load Canonical Companion Format & Bound Scope

1. Read the **"Companion format: the readiness audit"** section of the canonical process doc, preferring a user copy when present:

• If `<knowledge_folder>/approaches/foundational-review-chain.md` exists (resolve `<knowledge_folder>` from `~/.gemini/antigravity/aria-knowledge.local.md`), read THAT.
• Otherwise read the plugin-bundled copy at `${CLAUDE_PLUGIN_ROOT}/skills/foundational-review/foundational-review-chain.md` (always present).

It defines the tier structure, the agent-claim-correction discipline, and the composition contract with the chain. 2. State in-scope / out-of-scope explicitly. Fence sibling workstreams ("the chain's plan owns architecture-freeze risks — not duplicated here").

Step 2: Parallel Exploration (read-only)

Dispatch exploration agents per surface — typically:

• **source/build** — what builds, what's dead, what the artifact actually contains
• **licensing/hygiene** — license headers, secrets, internal URLs, third-party-asset rights
• **docs/tooling** — stale docs, broken references, release pipeline presence
• **over-build** (opt-in: when `--for` mentions bloat/over-engineering, or always when the scope is a code repo) — one read-only Explore agent walks `rules/overbuild-patterns.md`'s ladder + smells across the surface's source, reporting candidate over-build sites (each: `file:line`, matched smell, failed ladder rung, concrete leaner alternative). Respects `aria:simplification` markers — a marked site is reported "resolved", never flagged. Read-only per the guardrail below: it reports what it would change, never mutates a build artifact.

Use the `Task` tool (Explore agent type) per surface, in parallel. **Guardrail — read-only verification probes only.** No probe may mutate a build artifact. (A real incident: an agent "verified a build" by RUNNING it and overwrote a generated source file.) If a check would require building/running, the agent reports *what it would run + expected output*, and the controller decides whether to run it under the diff-check discipline in Step 3.

Step 3: Controller Re-Verification (the defining discipline)

This is what separates a readiness audit from a pile of agent claims. **Re-verify every load-bearing agent claim with a direct controller-level check** before it enters the findings. In real runs, multiple agent claims were corrected by direct checks.

For each claim an agent surfaced:

• Re-derive it yourself (`Read`/`Grep`/`git`), at `file:line`.
• If it holds → it becomes a finding with a verified Evidence cell.
• If it's wrong → record the correction as a **decision-trail row**: `Agent claimed X → direct check showed Y → corrected.`
• **Inherited claims from prior audits are re-derived, never trusted** (per the composition contract — a real review corrected an inherited file misattribution and a mis-scoped variable claim).

**Artifact diff-check (mandatory).** If any verification required building or running anything, immediately run `git diff --stat` (and restore) to prove no tracked artifact was mutated. Record the diff-check result in the audit. A test-build step that can't show a clean diff is a finding against the audit itself.

Step 4: Tiered Findings

Each finding carries a **verified Evidence cell** (cita