gaia-review-all

name	gaia-review-all
description	Run all 6 review workflows sequentially via subagents. Use when "run all reviews" or /gaia-review-all (formerly /gaia-run-all-reviews).
argument-hint	[story-key] [--force]
allowed-tools	["Read","Grep","Glob","Bash"]
deprecated_aliases	["gaia-run-all-reviews"]
deprecated_since	sprint-37
orchestration_class	heavy-procedural

Orchestration Mode

SESSION_MODE=$(bash "${CLAUDE_PLUGIN_ROOT}/scripts/detect-orchestration-mode.sh")
WARNING_OUTPUT=$(bash "${CLAUDE_PLUGIN_ROOT}/scripts/orchestration-warning.sh" --skill-class heavy-procedural --mode "$SESSION_MODE")
if printf '%s' "$WARNING_OUTPUT" | grep -q '^SURFACE-WARNING: '; then
  SENTINEL_PATH=$(printf '%s' "$WARNING_OUTPUT" | sed -n 's/^SURFACE-WARNING: //p' | head -n1)
  cat "$SENTINEL_PATH"
fi

Surface contract. When the prelude cats a sentinel file — which happens once per session under Mode A (subagent dispatch) — you MUST mirror that cat'd warning text VERBATIM as the FIRST user-visible text of your response, before any skill-phase output. Claude Code auto-collapses Bash tool-call output, so the warning is invisible to users unless re-emitted as LLM turn text. Skip this step only when the prelude produced no sentinel output (Mode B, repeat invocation in same session, or out-of-scope skill class).

Mission

You are running all 6 review workflows sequentially inline for a story. The story is resolved by {story_key} by searching for {story_key}-*.md under docs/implementation-artifacts/ — both the legacy flat layout (docs/implementation-artifacts/{story_key}-*.md) and the canonical nested layout (docs/implementation-artifacts/epic-*/stories/{story_key}-*.md). You orchestrate each review in deterministic order, update the Review Gate table after each, and report a summary of all verdicts.

This skill is the native Claude Code conversion of the legacy _gaia/lifecycle/workflows/4-implementation/run-all-reviews workflow. It is a thin orchestrator: every mechanical step lives in a deterministic bash script, and the LLM only does per-reviewer judgment work.

Inline orchestration: This skill runs all 6 reviews sequentially inline within a single context. It does NOT spawn nested subagents (to avoid nesting limitations). Each review is executed in-process by loading and following the relevant reviewer skill's instructions.

Sequential-only contract: The review gate is intentionally sequential. Parallel execution would create race conditions on the Review Gate table. The canonical order is never reordered.

Scripts-over-LLM: the LLM does NOT count gate rows, write the summary file, classify the composite verdict, or render the nudge — those are deterministic and live in review-skip-check.sh, review-summary-gen.sh, review-gate.sh review-gate-check, and review-nudge.sh respectively.

Worked Example

$ /gaia-run-all-reviews E58-S6
# Step 2.2: review-skip-check.sh emits {"skip":["code-review","qa-tests","security-review","test-automate","test-review"],"run":["review-perf"]}
# Step 2.3: 1 LLM judgment fires (review-perf), gate row written PASSED
# Step 2.4: 5 SKIPPED entries recorded for the summary block
# Step 3:   review-summary-gen.sh writes the locked summary file
#           review-gate.sh review-gate-check exits 0 (COMPLETE)
#           review-nudge.sh emits the progressive nudge block

$ /gaia-run-all-reviews E58-S6 --force
# Step 2.2: review-skip-check.sh --force emits {"skip":[],"run":["code-review","qa-tests","security-review","test-automate","test-review","review-perf"]}
# Step 2.3: all 6 LLM judgments fire; gate rows rewritten
# Summary block: zero SKIPPED entries; six verdicts.

A summary block with 5 SKIPPED + 1 ran reads (excerpt):

- Code Review        SKIPPED (already PASSED)
- QA Tests           SKIPPED (already PASSED)
- Security Review    SKIPPED (already PASSED)
- Test Automation    SKIPPED (already PASSED)
- Test Review        SKIPPED (already PASSED)
- Performance Review PASSED — see report

Operator Quickstart

Run the six review sub-agents (code, security, QA tests, test automation, test review, performance) against a story currently in review status. Each writes its report and updates the corresponding row of the story's Review Gate table. Already-PASSED reviews are skipped by default so re-runs are cheap; --force re-runs every reviewer.

First-time invocation.

/gaia-review-all E1-S1

This loads the story file, walks all six reviewers in canonical order, writes one review report per reviewer under .gaia/artifacts/implementation-artifacts/.../reviews/, updates the Review Gate table, and emits a locked summary block plus the progressive nudge for the next action.

When to use which option.

You want to	Run
Run only the reviewers not yet PASSED	/gaia-review-all <key>
Re-run every reviewer regardless of prior verdict	/gaia-review-all <key> --force
Check which review rows are still BLOCKED	/gaia-check-review-gate <key>
Run a single reviewer (e.g. security only)	/gaia-review-security <key> directly

Common gotchas.

• The story MUST be in review status -- not in-progress, not done. Run /gaia-dev-story first to drive the story into review.
• Reviews run sequentially by design -- never reorder or parallelize the canonical order; the Review Gate table is a shared resource.
• The user-facing command is /gaia-review-all (canonical) -- gaia-run-all-reviews is the deprecated alias from sprint-37 and still works for backward compatibility.

Critical Rules

• A story key argument MUST be provided. If missing, fail fast with "usage: /gaia-run-all-reviews [story-key] [--force]".
• The story file MUST exist under docs/implementation-artifacts/. Resolve by searching both the legacy flat layout (docs/implementation-artifacts/{story_key}-*.md) and the canonical nested layout (docs/implementation-artifacts/epic-*/stories/{story_key}-*.md); prefer the first lexicographic match. If zero matches across both layouts, fail with "story file not found for key {story_key}".
• The story MUST be in review status. If not, fail with "story must be in review status before running reviews".
• The --force flag is the ONLY supported flag. Any other flag (e.g., --frce) MUST be rejected with a usage error and a non-zero exit (AC-EC2).
• Reviews MUST run in this exact canonical order — never reordered, never parallel:
  1. Code Review (gaia-code-review) — gate "Code Review", short-name code-review
  2. QA Tests (gaia-qa-tests) — gate "QA Tests", short-name qa-tests
  3. Security Review (gaia-security-review) — gate "Security Review", short-name security-review
  4. Test Automation (gaia-test-automate) — gate "Test Automation", short-name test-automate
  5. Test Review (gaia-test-review) — gate "Test Review", short-name test-review
  6. Performance Review (gaia-review-perf) — gate "Performance Review", short-name review-perf
• Action-skill exclusion. /gaia-test-automate is an action skill, not a review skill. The "Test Automation" judgment in slot #4 above is a review (read test files, judge automation adequacy) and MUST NOT invoke /gaia-test-automate itself — generation is action-taking and would mutate the codebase mid-review. /gaia-test-automate is triggered on demand by:
  • explicit user invocation (/gaia-test-automate {story_key}),
  • /gaia-review-qa gap findings (uncovered ACs in qa-test-cases-{story_key}.json),
  • /gaia-review-test failure findings on missing automation coverage for a P0 AC. When triggered, /gaia-test-automate runs in its own context with the two-phase persona wiring (Phase 1 Sable, Phase 2 stack-developer per agent-overlay.sh).
• Never short-circuit on failure. If a reviewer returns FAILED, record the verdict and continue to the next reviewer. The entire purpose is to surface ALL issues in one pass.
• After each reviewer completes, update the Review Gate table via ${CLAUDE_PLUGIN_ROOT}/scripts/review-gate.sh update --story {story_key} --gate "{gate_name}" --verdict {PASSED|FAILED} (use the absolute plugin scripts path; this skill has no scripts/ subdirectory — the scripts live in the global plugins/gaia/scripts/ resolved via ${CLAUDE_PLUGIN_ROOT}).
• If a reviewer crashes (unexpected non-zero exit / malformed verdict), record FAILED for that reviewer and continue (AC-EC7).
• If review-gate.sh fails to update a row, log the failure and continue to the next reviewer.
• If review-skip-check.sh returns malformed JSON (missing skip or run keys), HALT with a parse-error message identifying the failing script — do NOT silently treat all 6 as run (AC-EC3).
• If review-summary-gen.sh cannot write its output (read-only filesystem / permission denied), HALT with an explicit write-failure message; story status is left untouched (AC-EC8).
• If review-gate.sh review-gate-check returns an exit code outside {0, 1, 2}, treat the result as UNVERIFIED, log a warning, and proceed (AC-EC13). Do not crash.
• This skill does NOT transition story state. State transitions are owned by the state machine, not by the runner.

Procedure

Step 1: Validate Input

1. Parse the story key from the first positional argument and the optional --force flag (Substep 2.1 prep). Reject any other flag with a usage error and exit non-zero (AC-EC2).
2. Brain-context loader. With the story key now bound, run the brain-reliance loader for this workflow's entry stage. The loader checks governing-context availability and HALTs only when a cleanly-evaluated MANDATORY node is absent; otherwise it warns and continues (fail-open).

bash ${CLAUDE_PLUGIN_ROOT}/scripts/brain/brain-reliance-loader.sh gaia-run-all-reviews:review-entry --story-key "{story_key}"

3. Resolve the story file by searching both layouts in order: first the legacy flat path docs/implementation-artifacts/{story_key}-*.md, then the canonical nested path docs/implementation-artifacts/epic-*/stories/{story_key}-*.md. Prefer the first lexicographic match. If zero matches across both layouts, HALT with "story not found" before invoking any helper script (AC-EC12).
4. Read the story file frontmatter and verify status: review.
5. Read the current Review Gate table to confirm the section exists.

Step 2: Thin-Orchestrator Procedure

Six substeps. Substeps 2.1–2.2 run once. Substeps 2.3–2.4 partition the canonical reviewer set across the LLM (judgment) and the summary block (skipped entries) according to the JSON {skip, run} partition emitted by review-skip-check.sh.

Substep 2.1 — Validate input (already handled in Step 1). Story key required; --force optional; HALT on unknown flags or missing story.

Substep 2.2 — Skip-check. Run:

bash ${CLAUDE_PLUGIN_ROOT}/scripts/review-skip-check.sh --story {story_key} [--force]

(Use the absolute ${CLAUDE_PLUGIN_ROOT}/scripts/ prefix — this skill's directory contains only SKILL.md, no scripts/ subdirectory. Bare scripts/review-skip-check.sh invocations fail with "No such file or directory".)

The script emits a single line of JSON: {"skip":[...],"run":[...]}. If --force was passed by the user, forward it verbatim to the helper — the script owns the bypass semantics (skip becomes [], run becomes the full canonical list). Parse the JSON; if it lacks either the skip or run key, HALT with a parse error naming review-skip-check.sh (AC-EC3).

Substep 2.3 — Run the run slice (Skill dispatch + report assertion + gate write). For each canonical short-name in run (in canonical order), dispatch the corresponding per-review skill via the Skill tool (NEVER inline-judge). After the skill returns, assert the per-review report file exists on disk before writing the verdict. The verdict write itself uses the proof-of-execution contract:

bash scripts/review-gate.sh update --story {story_key} \
  --gate "{gate_name}" --verdict {PASSED|FAILED} \
  --report <absolute-path-to-per-review-report> \
  [--execution-evidence <absolute-path-to-execution-evidence.json>]

For test-execution gates (QA Tests, Test Automation, Test Review), --execution-evidence is REQUIRED in addition to --report — the gate will refuse the verdict otherwise. The dispatched skill is responsible for producing both files; the orchestrator only asserts their existence.

Skill-dispatch contract:

For each short_name in run:
  1. Invoke via the Skill tool:
       Skill({skill: "gaia:<short-name-mapped-to-canonical-skill>", args: "{story_key}"})
     Canonical short-name → skill mapping (one canonical name per skill — the listed name is authoritative; deprecated_aliases live on the skill's own frontmatter):
       code-review     → gaia:gaia-code-review
       qa-tests        → gaia:gaia-review-qa
       security-review → gaia:gaia-review-security
       test-automate   → gaia:gaia-test-automate
       test-review     → gaia:gaia-review-test
       review-perf     → gaia:gaia-review-perf

  2. After the skill returns, derive the expected report path from the
     CANONICAL_REPORT_RELPATHS table (the same table review-summary-gen.sh
     uses). Assert `[ -f "$report_path" ]` — if the report file is absent,
     HALT with an explicit message naming the gate, the expected path, and
     directing the operator to re-dispatch the review skill. Do NOT write
     a PASSED verdict for a gate with no on-disk report.

  3. Read the verdict from the skill's emitted report (the per-review
     skill's contract emits a "Verdict: PASSED|FAILED" line in the report
     body — orchestrators MUST parse the actual report rather than
     self-judge).

  4. Write the verdict via review-gate.sh update with --report (and
     --execution-evidence for test-execution gates).

  5. If the skill dispatch itself fails (skill not installed, subagent
     errors before returning), record a FAILED verdict with
     --report-missing-reason "dispatch-failed: <reason>" so the audit
     trail captures the failure mode. The cap-and-continue rule (AC-EC7)
     still applies — proceed to the next entry in run.

The "Per-reviewer LLM judgment blocks" pattern from the legacy SKILL.md is RETIRED. Inline self-judgment by the orchestrator is forbidden; the per-review skills are the single source of verdicts. If a per-review skill is missing or broken, that is a defect to file — NOT a license for the orchestrator to substitute its own judgment.

Substep 2.4 — Record SKIPPED entries for the skip slice. For each canonical short-name in skip, record a "SKIPPED (already PASSED)" line for the eventual summary block. The summary script (Step 3) consumes the current gate state directly, so SKIPPED rows already at PASSED need no rewrite.

Per-reviewer skill-dispatch reference table

This table is THE single source of truth for review-report paths. review-summary-gen.sh (proof-of-execution), review-skip-check.sh, review-gate.sh, and the six per-review skills all resolve report paths from this table — there is NO divergent per-skill hardcoded path. The path column gives the read-side resolution contract.

Per-story reviews/ home — single-source resolver. The NEW canonical home for each review report is the per-story reviews/ subdir: …/epic-E{N}-{slug}/E{N}-S{M}-{slug}/reviews/<type>-{key}.md (type-FIRST basenames, identical to the flat form). The six review skills no longer hard-code their write directory — each resolves it via the shared ${CLAUDE_PLUGIN_ROOT}/scripts/resolve-review-report-path.sh --key {key} --type <type> helper, which returns the per-story reviews/ path (and creates the dir) for new-layout stories and the flat implementation-artifacts/<type>-{key}.md path otherwise. The flat path in the table below is the read-side fallback during the migration window — review-summary-gen.sh's proof-of-execution check accepts a report at EITHER home (it greps */{key}-*/reviews/<basename> when the flat path is absent), so a report written to the per-story reviews/ dir is never flagged MISSING. The canonical table in this skill remains the single source of the BASENAME (type-first); the resolver is the single source of the DIRECTORY.

Each row names the canonical short-name, the skill to dispatch, the canonical gate name written to the Review Gate, the expected report file path, and whether --execution-evidence is required.

Short-name	Dispatch	Gate name	Report path	Execution evidence?
code-review	gaia:gaia-code-review	Code Review	.gaia/artifacts/implementation-artifacts/code-review-{key}.md	No
qa-tests	gaia:gaia-qa-tests	QA Tests	.gaia/artifacts/implementation-artifacts/qa-tests-{key}.md	Yes
security-review	gaia:gaia-review-security	Security Review	.gaia/artifacts/implementation-artifacts/security-review-{key}.md	No
test-automate	gaia:gaia-test-automate	Test Automation	.gaia/artifacts/implementation-artifacts/test-automate-review-{key}.md	Yes
test-review	gaia:gaia-test-review	Test Review	.gaia/artifacts/implementation-artifacts/test-review-{key}.md	Yes
review-perf	gaia:gaia-review-perf	Performance Review	.gaia/artifacts/implementation-artifacts/performance-review-{key}.md	No

Type-first naming reconciliation. These paths were corrected to the type-prefix-FIRST convention (<type>-{key}.md under implementation-artifacts/) that the six per-review skills actually write to (verified on disk: code-review-{key}.md, qa-tests-{key}.md, test-automate-review-{key}.md, test-review-{key}.md, etc.). The prior reversed {key}-<type>.md form — and the stray test-artifacts/ directory on the test-aligned rows — disagreed with the type-first convention, made review-summary-gen.sh's proof-of-execution check flag every report MISSING, and risked a check-deps.sh {key}-*.md glob collision (a key-first report basename collides with the story-file glob). The per-review SKILL.md write paths were already type-first-correct and are deliberately UNCHANGED.

Under the .gaia/ consolidation, the prefix docs/ may resolve to .gaia/artifacts/ — the report paths are constructed via ${GAIA_ARTIFACTS_DIR} per gaia-paths.sh. Both layouts are accepted by review-gate.sh --report.

Step 2.5: Manual-test dispatch (for manual_verification: true stories)

Deterministic, scripts-over-LLM. The LLM does not dispatch surfaces or judge the manual-test verdict — manual-test-review-dispatch.sh does.

After the six canonical reviews finish (Substeps 2.3–2.4) and BEFORE the summary, run the manual-test dispatch helper for the story. This closes the gap where a story declaring manual_verification: true could reach done with no functional verification (the surface dispatch + ledger gate existed, but nothing in the per-story review ever produced a verdict — so a silently-broken / unwired feature shipped green):

bash ${CLAUDE_PLUGIN_ROOT}/scripts/manual-test-review-dispatch.sh --story {story_key}

• For a story that does NOT declare manual_verification: true, the helper is a clean no-op (exit 0, nothing recorded) — the common case is unaffected, no new mandatory step.
• For a manual_verification: true story, the helper resolves a REAL functional target (the sprint_review.manual_test.api_command for the api surface — the story key is NOT a runnable command), runs the surface check (REUSING gaia-test-manual's dispatch-surface.sh), and records the verdict to the review-gate manual-test ledger gate via review-gate.sh --plan-id.
• The mapping is fail-closed, because the story author asserted that verification is REQUIRED: only a surface verdict that actually ran and PASSED records PASSED (exit 0); a real FAILED records FAILED (exit 3); and anything that did NOT actually verify — no resolvable functional target, SKIPPED, PENDING, an adapter error, or an absent verdict — records UNVERIFIED (exit 4). A SKIPPED surface is NOT a pass here: the absence of execution for a story that requires verification is an unmet requirement, not a green gate.
• Surface the helper's stderr to the user. A non-zero exit (3 = FAILED, 4 = UNVERIFIED) means the manual-test gate is not PASSED — the story should NOT be transitioned to done until the functional verification actually runs and passes. The transition is gated by the advisory/gating consumer in transition-story-status.sh (review→done): for a manual_verification: true story, ANY non-PASSED manual-test verdict (FAILED, UNVERIFIED, or absent) triggers the gate. Behavior is controlled by review_gate.manual_test_mode (advisory WARNING by default; gating blocks the transition).

Step 3: Generate Summary (deterministic three-call sequence)

Summary file is written by script, not LLM. The LLM produces optional one-line synopses via --synopsis-file; everything else is deterministic.

After Substeps 2.3–2.4 finish, run the three deterministic helper scripts in fixed order:

1. Write the summary file via review-summary-gen.sh:

   bash scripts/review-summary-gen.sh --story {story_key} [--synopsis-file <path>]
   

   The script reads the current Review Gate table and writes the V1-locked schema to .gaia/artifacts/implementation-artifacts/{story_key}-review-summary.md. If the script exits non-zero with a write failure (read-only filesystem / permission denied), HALT with an explicit write-failure message; story status is left untouched (AC-EC8).

2. Compute the composite verdict via review-gate.sh review-gate-check and use its exit code as the single source of truth:

   bash scripts/review-gate.sh review-gate-check --story {story_key}
   

   • exit 0 → COMPLETE (all six PASSED)
   • exit 1 → BLOCKED (any FAILED — FAILED dominates over PENDING) (AC-EC14)
   • exit 2 → PENDING (any UNVERIFIED, no FAILED)
   • any other exit code → treat as UNVERIFIED, log a warning, do not crash (AC-EC13)

   The LLM MUST NOT recompute the verdict by counting rows — the exit code is the contract.

3. Emit the progressive nudge block via review-nudge.sh and surface its stdout to the user:

   bash scripts/review-nudge.sh --story {story_key}
   

   The nudge block branches on the composite outcome (ALL PASSED → COMPLETE; N FAILED → BLOCKED with a "Blocking gates" list; N UNVERIFIED → PENDING with a "Pending gates" list).

Step 4: Composite Verdict GATING

The composite verdict is GATING, not informational. The deterministic shell aggregator at scripts/review-common/composite-verdict-aggregator.sh consumes per-gate verdicts (APPROVE | REQUEST_CHANGES | BLOCKED produced by the verdict-resolver.sh path) and emits a composite verdict mapped to the Review Gate vocabulary (PASSED | FAILED). The aggregation path is 100% shell — no LLM — and is invariant under YOLO mode.

After Step 3 emits the nudge block, the orchestrator MUST run the composite aggregator with the per-gate verdicts surfaced by the verdict-resolver runs.

Conditional-skip evaluation. Before invoking the aggregator, the orchestrator runs the deterministic conditional-trigger evaluator to decide whether the conditional gates (a11y, mobile) are included or skipped. The evaluator reads compliance.ui_present and platforms[] from the resolved project-config and emits drop-in argv fragments that the orchestrator forwards verbatim into the aggregator call:

bash scripts/review-common/conditional-trigger-eval.sh
# stdout (when ui_present=false and platforms excludes mobile):
#   a11y=skipped
#   a11y_reason=compliance.ui_present: false
#   mobile=skipped
#   mobile_reason=platforms[] excludes mobile
#   --skip-a11y "compliance.ui_present: false"
#   --skip-mobile "platforms[] excludes mobile"

The orchestrator then composes the aggregator invocation:

bash scripts/review-common/composite-verdict-aggregator.sh \
  --code <verdict> --qa <verdict> --test <verdict> \
  --security <verdict> --perf <verdict> \
  ( --a11y <verdict> | --skip-a11y "compliance.ui_present: false" ) \
  ( --mobile <verdict> | --skip-mobile "platforms[] empty" )

Skip-rule semantics: Skipped conditional gates appear in the aggregator's skipped= enumeration with their skip reason. They contribute neutrally to the precedence chain — only included gates' verdicts count toward BLOCKED > REQUEST_CHANGES > APPROVE. The composite report enumerates included gates (with verdict) and skipped gates (with reason) so reviewers can see at a glance which gates fired.

Degenerate-case safety net (AC-EC3): Should every gate end up skipped (a configuration-error scenario where all gates are conditional and no condition is met), the orchestrator passes --allow-zero-included along with --skip-<gate> flags for the always-on gates as well. The aggregator emits a WARNING: No review gates included line and composite=APPROVE. This is a configuration-error safety net — never a normal flow — and the WARNING is the explicit signal that project-config needs review.

The aggregator emits composite=<APPROVE|REQUEST_CHANGES|BLOCKED> and review_gate=<PASSED|FAILED> plus the included / skipped enumeration. The composite verdict is then evaluated against the seven-day post-flip grace window via scripts/review-common/grace-window.sh:

• WARNING mode (within 7 calendar days of the flip): the composite verdict is surfaced with a resolution recommendation; transition to done is still possible.
• BLOCK mode (after 7 calendar days): if composite ∈ {REQUEST_CHANGES, BLOCKED}, the story cannot transition past review. The orchestrator HALTs the transition until either (a) the underlying gate is resolved and re-reviewed, or (b) the maintainer invokes /gaia-correct-course to move the story off review to a remediation track.

YOLO mode does NOT bypass composite gating — consistent with the CRITICAL-still-halts rule. The aggregator output is byte-identical across runs for byte-identical inputs.

Idempotency invariant

Re-invocation with unchanged gate state MUST produce a byte-identical summary file and nudge block. Determinism comes from the scripts. The SKILL.md just calls them in fixed order — it never inserts timestamps, randomness, or LLM-generated commentary into the summary file or the nudge block.

Mode B Readiness

Driving teammate turns (MANDATORY under team orchestration). Declaring readiness above sets up the spawn / relay / shutdown bookkeeping seams — it does NOT by itself drive a teammate. When SESSION_MODE == team, the orchestrator MUST drive each teammate turn per the canonical Mode B teammate round-trip contract at knowledge/mode-b-round-trip-contract.md: emit a real SendMessage(to: <handle>) whose message ends with the reply-routing reminder, let the teammate reply via SendMessage(to: team-lead) (one-shot re-prompt on idle-without-reply; never fabricate the reply), then relay the received body to the transcript / artifact. The bridge functions named above are bookkeeping only; the round-trip itself is an orchestrator-driven, main-turn loop.

No discretionary Mode A fall-through. The team-mode round-trip is mandatory when the session resolves to team orchestration — "it is a small / focused / quick step" is NOT a license to fall back to one-shot Mode A, and a slow reply is the cross-turn-boundary case (wait or re-prompt once), not a fallback trigger. The ONLY legitimate fall-through is a real MODE_B_FALLBACK token emitted by the bridge at spawn time (substrate genuinely unavailable).

This skill is Mode B-ready for its ORCHESTRATION only. The shared execution bridge library at ${CLAUDE_PLUGIN_ROOT}/scripts/lib/execution-mode-b-bridge.sh (layered on ${CLAUDE_PLUGIN_ROOT}/scripts/lib/dispatch-teammate.sh) supplies the team-orchestration seam — but this skill deliberately uses NONE of its spawn/relay machinery for the six reviewers themselves.

• Reviewers stay one-shot / clean-room — NON-NEGOTIABLE. The six reviewers (code, security, QA tests, test automation, test review, performance) MUST remain one-shot subagents that judge from a clean context. They are NEVER spawned as persistent teammates. This is the clean-room invariant: a reviewer that shared a session's working context could not render an independent verdict. None of these reviewer personas appears in any teammate roster for this skill.
• No reviewer teammate roster. This skill declares no Mode B teammate roster of reviewer personas. The clean-room gate in the shared library (driven by knowledge/reviewer-personas.txt) fails closed and refuses to create a teammate for any reviewer persona, so even an errant execution_spawn_subagent call against a reviewer is blocked before any teammate exists.
• Spawn seam (non-reviewer only). If a future non-reviewer helper persona is ever needed, it would be obtained via execution_spawn_subagent <non-reviewer-persona> "gaia-run-all-reviews"; reviewers are explicitly out of scope for that seam.
• Shutdown seam. At skill exit the orchestration calls execution_shutdown, which delegates to shutdown_all so no teammate pane is left orphaned. With reviewers kept one-shot, there is normally nothing to tear down.
• Honest fallback. Live Mode B is not exercisable in every Claude Code context. The existing Mode A one-shot reviewer-dispatch documented above remains the source of truth; the bridge emits a single MODE_B_FALLBACK token to stderr when the substrate is absent.