Super Review Generator (brewcode:superreview-setup)

ROLE: GENERATOR. This skill is HUMAN-invoked. It analyzes the TARGET project, then WRITES a self-contained, project-local .claude/skills/superreview/ into that project — the merged deep-review skill (review + standards-review folded into one). It does NOT review code itself; it EMITS the skill that does.

OUTPUT: A project-local skill at <target>/.claude/skills/superreview/ (SKILL.md + references) PLUS a project agent at <target>/.claude/agents/intent-guard.md, modeled exactly on the canonical shape: deterministic MODE resolution + semantic DEPTH resolution -> MECHANICAL GATES -> ANNOUNCE -> the INTENT pass (intent-guard, both depths) -> [EXTENDED only:] route changed files to project DOMAIN-EXPERT agents selected at RUNTIME -> resolve the SANCTIONED SCOPE baseline -> reference (not restate) the project's .claude/rules + convention files -> ONE targeted parallel fan-out (domain experts + 2 scope passes + intent) -> per-finding adversarial VALIDATION gate -> scope gate (AskUserQuestion) -> ONE merged P0-P3 report at .claude/reports/{TIMESTAMP}_superreview/REPORT.md, READ-ONLY (recommends /simplify, never edits).

Three things make or break the emitted skill: (1) DOMAIN EXPERTS — a review routed to generic agents finds generic issues. Phase 1.6 below is mandatory: discover the experts, and CREATE the missing ones before emitting. (2) SCOPE DISCIPLINE — the emitted skill measures every change against the SANCTIONED baseline (task + issue

• recorded decisions): creep, blast radius, under-delivery, closeout. Phase 1.5 wires it to the target's tracker. (3) THE INTENT PASS — intent-guard answers "was the DELIVERED thing the ASKED thing?". It runs at BOTH depths and is the whole review at QUICK. Phase 1.6 + Phase 3 wire it to this project's real invariants.

The emitted skill has TWO orthogonal axes. {MODE} selects SCOPE (FULL_PROJECT / EXPLICIT / UNCOMMITTED / LAST_COMMITS). {DEPTH} selects EFFORT: QUICK (the DEFAULT and common case — mechanical gates + the intent pass, ONE spawn, no domain experts) or EXTENDED (the full fan-out + validation + scope gate, plus the intent pass). Depth is inferred SEMANTICALLY from the user's prompt, exactly like the {MODE} whole-project rule — there is no --fast, no flag and no CLI token, and you must not add one.

The emitted skill is generic-capable (Java/Kotlin, Node/TS, Python, Go) and self-contained — NO plugin dependency, NO sibling-skill orchestration once generated.

Arguments: $ARGUMENTS — <fine-tune-prompt> (free text: what to emphasize in the emitted skill's focus ordering) plus optional [scope] hint. The fine-tune prompt is woven into the emitted skill's Focus ordering + emphasis.

Prompt contract

Position 1 of $ARGUMENTS is a free-form prompt (RU/EN) — verbs and flags are optional and may follow in any order. Nobody types keys: resolve the verb + fine-tune focus FROM the prompt.

1. Strip flags. An explicit verb token anywhere wins outright, no scoring — the seven canonical verbs are in the Verb routing table below.
2. Else score verbs by distinct whole-word keyword hits (Verb routing table below). Highest unique score wins. Tie involving purge (destructive) -> AskUserQuestion; tie with status -> status; tie of two mutating verbs -> the keyword appearing first; all zero -> status if .claude/skills/superreview/SKILL.md or its .disabled twin exists, else install.
3. Empty arguments -> the default above; ask ONE scoping AskUserQuestion only when the answer changes what gets written. status asks nothing.
4. Outcome-changing ambiguity -> ONE AskUserQuestion (max 4 questions) BEFORE any work.
5. Prose that names no verb is the fine-tune prompt, not an error — it is woven into the emitted skill's Focus ordering (Phase 1.5), never treated as the verb by its first word.

Then print this block ONCE, before the resolved verb runs:

PLAN — brewcode:superreview-setup
INPUT:  <arguments verbatim, or "(empty)">
MODE:   <resolved verb> — <explicit | matched keyword: X | default>
SCOPE:  <target repo, fine-tune focus, scope hint>
DO:     <2-5 imperative bullets>
RESULT: <what the user ends up holding>

Labels are literal; values follow the conversation language.

What the emitted skill merges (review + standards-review)

Reconcile rule: the canonical shape is the STRUCTURE; standards-review + the review template supply the per-stack checks, the reuse matrix and the report scaffolding baked INTO it; the scope + expert-selection references supply the two axes that make the review project-specific rather than generic.

Execution

Verb routing — resolve FIRST, before anything else

$ARGUMENTS may start with one of the seven canonical verbs, in this order: status | install | upgrade | enable | disable | uninstall | purge. Anything else is the fine-tune prompt and takes the free-form path. Strip the verb before using the rest as the fine-tune prompt.

Removed aliases that must never be accepted or printed: init, on, off, setup, remove, reset, create, update, cleanup. Recognize them in free text, echo the canonical verb back.

Print the PLAN block (Prompt contract above) now, before running the resolved verb.

EXECUTE using Bash tool (status only):

if test -f .claude/skills/superreview/SKILL.md; then echo "installed: enabled"
elif test -f .claude/skills/superreview/SKILL.md.disabled; then echo "installed: DISABLED (parked as SKILL.md.disabled — run 'enable' to restore)"
elif test -d .claude/skills/superreview; then echo "installed: BROKEN (dir present, no SKILL.md and no SKILL.md.disabled)"
else echo "not_installed"; fi
test -f .claude/agents/intent-guard.md && echo "intent-guard: present" || echo "intent-guard: MISSING"
test -d .claude/skills/superreview/.template-baseline && echo "baseline: present" || echo "baseline: absent (pre-baseline install)"
echo "reports: $({ find .claude/reports -maxdepth 1 -type d -name '*_superreview' 2>/dev/null || true; } | wc -l | tr -d ' ') dir(s) — deleted by 'purge', kept by 'uninstall'"
bash "${CLAUDE_SKILL_DIR}/scripts/generate.sh" validate && echo "✅ validate" || echo "❌ validate FAILED"

status never writes and never asks. not_installed -> report it and offer install; nothing else. installed: DISABLED is a state, not a fault — report it and offer enable. validate fails on a disabled install (it looks for SKILL.md); say so rather than presenting it as a broken installation.

Modes: enable | disable | uninstall | purge

How the toggle works. Claude Code discovers a project skill only through <dir>/SKILL.md. disable renames that ONE file to SKILL.md.disabled, so /superreview stops being offered while references/, .template-baseline/ and every Phase 3 tailoring stay byte-identical on disk. enable renames it back. Nothing is regenerated in either direction, so no version is bumped and no self-synced edit is at risk. Use disable to park a review setup that is temporarily noisy; use uninstall when it should really go. Both take effect in the NEXT session — skills are discovered at session start.

intent-guard is never touched by any of the four. generate.sh (emit/emit-agent) is its only writer, and it is shared with /brewcode:teams-setup, which may have put it there. Deleting or parking it would silently break an unrelated team install. All four modes print it as KEPT.

Confirm before deleting. uninstall and purge each AskUserQuestion exactly once, listing the real paths (find .claude/skills/superreview -type f | sort) and, for purge, the number of review reports being destroyed, with uninstall offered as the keep-the-reports alternative. A declined confirmation ends the run cleanly — delete nothing.

EXECUTE using Bash tool (the chosen verb, after confirmation where required):

bash "${CLAUDE_SKILL_DIR}/scripts/generate.sh" MODE_HERE && echo "✅ MODE_HERE" || echo "❌ MODE_HERE FAILED"

Then report the script's MOVED: / REMOVED: / KEPT: lines verbatim. Not installed at all -> say so and STOP; never "disable" or "purge" something that was never emitted.

Delegation (applies to every Task this generator spawns AND to the fan-out it emits)

A big task handed to one agent = an agent gone for an hour: you cannot observe it, cannot correct it, and it usually drifts off-target. One subagent = ONE bounded unit — one deliverable (here: ONE file group's review), ~<=5 files, ~<=10 steps. Bigger MUST be split into N tasks, all spawned in ONE message — that is why the emitted skill routes file GROUPS to domain owners.

Every spawn prompt MUST carry:

A bare one-line task is never enough. When filling {FILE_GROUP_MAP} in Phase 3, keep every group small enough to be one bounded unit — split an oversized group into two rows rather than emitting a single agent that owns half the repo.

Phase 0 — Pre-analysis (read THIS skill's emit material)

1. Read the emit templates this generator ships (relative to ${CLAUDE_SKILL_DIR}):
   • references/SKILL.md.template — the emitted SKILL.md (with {PLACEHOLDER} slots)
   • references/agent-prompt.md — runtime expert selection + domain-owner prompt contract (emitted, substituted)
   • references/scope.md.template — scope-discipline reference (emitted as the target's references/scope.md)
   • references/intent-guard.md.template — the anti-drift agent (emitted as <target>/.claude/agents/intent-guard.md; READ it before Phase 3 — you fill three BLOCKs in it). Its own header comment documents every placeholder; generate.sh STRIPS that header on emit
   • references/report-template.md — emitted report layout
   • references/{python,java-kotlin,typescript-react,go}.md — per-stack reference docs (one is emitted)
2. Confirm the TARGET project is the current working directory (the repo to be reviewed). All emitted paths are relative to that repo root.

Phase 1 — Analyze the TARGET project

Gather everything the emitted skill must be wired to. Explore the code with Bash search (grep->ugrep / find->bfs on macOS CC; native Grep/Glob are no-ops there).

EXECUTE using Bash tool (project scan):

bash "${CLAUDE_SKILL_DIR}/scripts/generate.sh" scan && echo "✅ scan" || echo "❌ scan FAILED"

The scan reports: build files, .claude/agents/*, .claude/rules/* + .claude/convention/*, test dirs, source dirs. From it (plus your own reads) determine:

Multi-stack repos: if more than one stack is detected, pick the DOMINANT one for the emitted STACK_REF, and note the secondary stack(s) in DOMAIN_AGENTS_TABLE / FILE_GROUP_MAP. (One stack reference doc is emitted; the rule pointers cover the rest.)

Phase 1.5 — Clarify genuinely ambiguous params (AskUserQuestion)

Use AskUserQuestion ONLY for params you cannot reliably infer. Never auto-guess a non-obvious choice. Typical questions:

• The scope baseline — which tracker sanctions work (file board / GitHub issues / Jira / none), and the branch -> issue convention. Without it the emitted skill caps every scope finding at P2, so ASK when unsure.
• Always-shared surfaces — confirm the list whose edit widens blast radius across the whole team.
• Which agent is the architecture arbiter / Phase-3 validator when several plausible reviewer/architect agents exist.
• The domain-owner mapping when an agent's owned path group is unclear.
• Confirm the dominant stack when the repo is genuinely multi-stack.
• Confirm the mechanical gate commands when several plausible ones exist (CI is the tie-break: use what CI runs).

Weave the <fine-tune-prompt> argument into the emitted Focus ordering: if the user said "focus on X / weight Y higher", reorder/emphasize the emitted FOCUS_TABLE accordingly (e.g. push security to P0-always, or raise reuse to rank 1). Record the emphasis in FOCUS_EMPHASIS. Scope discipline stays inside rank 1 whatever the emphasis — it may be raised, never dropped.

Phase 1.6 — DOMAIN EXPERTS (mandatory — the review is only as good as these)

A superreview routed to generic agents produces generic findings. Before emitting, PROVE that every source group in FILE_GROUP_MAP has a real owner:

1. Classify the live roster from the Phase 1 scan: for each .claude/agents/*.md, does its description claim a concrete path/responsibility in this repo? Exclude READ-ONLY recon agents (they inspect live external systems, never source files) — they may never own a review group.
2. Find the gaps — every group with no confident owner. A gap means the emitted skill falls back to Explore for that surface, i.e. a permanently DEGRADED axis.
3. Fill the gaps (default action). AskUserQuestion listing the uncovered groups, recommending "create the missing domain experts". On approval, spawn brewcode:agent-creator — ONE agent per missing domain, ALL in ONE message — each with the group's paths, the project rules that bind it, and the responsibility it owns. Then re-run the roster scan so the new agents enter DOMAIN_AGENTS_TABLE / FILE_GROUP_MAP.
4. If the user declines, emit anyway but mark each uncovered group DEGRADED in DOMAIN_AGENTS_TABLE, and say so in the Phase 5 summary. generate.sh validate fails when NO project expert is wired at all — pass SUPERREVIEW_ALLOW_NO_EXPERTS=1 to accept that consciously.
5. Never invent an agent name. Every emitted subagent_type must resolve to a real file in .claude/agents/ or a built-in (Explore/Plan/general-purpose) — validate enforces it.

Scope passes need owners too: SCOPE_AGENT_A = the agent that owns the task board / tracker read path (e.g. a task-tracker agent from /brewtools:task-board-setup), else Explore. SCOPE_AGENT_B = a read-only searcher — Explore is the correct default, since pass B's job is proving an ABSENCE across the corpus.

1.6b — intent-guard (create-or-reuse; ONE writer, no gate)

intent-guard is NOT a domain expert and is NOT part of the roster-gap procedure above. It is spawned unconditionally by the emitted skill at BOTH depths, so the emitted skill is broken without it.

Phase 2 — Resolve placeholders + emit (scalar substitution)

Export the SCALAR placeholder values, then run the emit step (mirrors setup.sh copy_review_skill() — sed with a control-char separator; values MUST be single-line):

export PROJECT_NAME="<repo name>"
export STACK_LABEL="<Java/Kotlin | Node/TypeScript | Python | Go>"
export STACK_REF="<python.md | java-kotlin.md | typescript-react.md | go.md>"
export SOURCE_GLOB="<*.py | *.java | *.ts | *.go ...>"
export PATHSPEC_GLOBS="<'*.py' 'requirements*.txt' 'pyproject.toml' 'Dockerfile*' 'docker-compose.yml' '.github/workflows/*.yml'>"
export ARBITER_AGENT="<project architect agent | general-purpose>"
export VALIDATOR_AGENT="<project arbiter agent | general-purpose>"
export SCOPE_AGENT_A="<task-board/tracker agent | Explore>"
export SCOPE_AGENT_B="<read-only searcher | Explore>"
export TRACKER_LABEL="<e.g. '.claude/features board + GitHub issues (read-only)' | 'GitHub issues only' | 'none'>"
# intent-guard tier sources — `none` is a legitimate value; an absent source is REPORTED, never invented
export SPEC_LOCATION="<e.g. '.claude/specs/**' | 'docs/adr/*.md' | 'none'>"
export PLAN_LOCATION="<e.g. '.claude/features/**' | 'TASKS.md' | 'none'>"
export POLICY_LOCATION="<e.g. 'CLAUDE.md, .claude/rules/**, .claude/convention/**' | 'CLAUDE.md' | 'none'>"

EXECUTE using Bash tool:

bash "${CLAUDE_SKILL_DIR}/scripts/generate.sh" emit && echo "✅ emit" || echo "❌ emit FAILED"

STOP if ❌ — UNLESS the message is already installed. That refusal is the EXPECTED path on a live installation: it exits 1 by design, prints no INTENT_GUARD: line at all, and means go to Phase 2b (run upgrade), not stop. Any other ❌ is a real failure: verify ${CLAUDE_SKILL_DIR}/references/SKILL.md.template exists and the target .claude/ is writable.

This writes <target>/.claude/skills/superreview/SKILL.md (scalars substituted), copies agent-prompt.md, report-template.md, scope.md and the chosen ${STACK_REF} (all scalar-substituted) into the emitted references/, saves the pristine templates to .claude/skills/superreview/.template-baseline/ (what upgrade later diffs against), and creates-or-reuses <target>/.claude/agents/intent-guard.md (template header stripped, provenance stamp kept). Every emitted artifact is stamped with the four standard metadata fields — doc_type: llm, version, generated_by: brewcode:superreview-setup, last_updated — in its frontmatter; you export NOTHING for them. version is read out of the plugin's own .claude-plugin/plugin.json by script self-location and last_updated is date +%F. Both stay {PLUGIN_VERSION} / {LAST_UPDATED} in the raw .template-baseline/ copies, so a plain version bump makes upgrade report IDENTICAL, never a diff.

disable-model-invocation MUST NOT be set on the emitted skill: the model invoking it mid-plan is a first-class path, alongside the user typing /superreview.

Key off the ONE machine-readable status line the writer prints — the already installed refusal path prints NO status line, because nothing was written:

The same writer is available standalone as generate.sh emit-agent (agent only, no superreview skill required, same env overrides PROJECT_NAME / TRACKER_LABEL / SPEC_LOCATION / PLAN_LOCATION / POLICY_LOCATION, same three status lines). /brewcode:teams-setup uses it; this generator does not need it, emit covers it.

Phase 2b — Already installed? upgrade, never re-emit

The emitted skill self-modifies: its Phase 4b SELF-SYNC corrects its own routing table, dead gates, scope baseline and shared surfaces in place on every EXTENDED run. A blind re-emit erases all of it, so emit REFUSES on a live installation. When it does:

EXECUTE using Bash tool:

bash "${CLAUDE_SKILL_DIR}/scripts/generate.sh" upgrade && echo "✅ upgrade" || echo "❌ upgrade FAILED"

It rewrites no live file's CONTENT — the one thing it does write into a live file is the metadata restamp below. It stages a fresh emit at .claude/skills/superreview/.upgrade-staging/ (with the raw new templates under .upgrade-staging/.template/) and compares the NEW TEMPLATE against the pristine copies emit saved in .claude/skills/superreview/.template-baseline/ — never the live file against a template, because a live file legitimately carries Phase 3 tailoring and Phase 4b self-sync edits that no template ever knew about. One line per asset:

The stack is re-derived, never re-defaulted. The first line upgrade prints is UPGRADE_STACK=<name>.md (derived from the installed tree). The per-stack reference was a Phase 1 DECISION (STACK_REF), and upgrade runs with a bare environment, so it reads that decision back out of the installed tree — whichever of python.md / typescript-react.md / go.md / java-kotlin.md is present in references/ or in .template-baseline/references/ — instead of falling back to a default. Everything below iterates that name: a wrong one would leave the project's real reference behind at the old version forever while restamping a file the project does not have, so /brewcode:setup-status would report stale after every successful upgrade. More than one present = a multi-stack install, and all of them are restamped. None determinable prints UPGRADE_STACK=none — ❌ NO per-stack reference found and skips the stack doc only; the other four artifacts are still restamped. STACK_REF=<name>.md in the environment overrides the derivation.

The restamp — one RESTAMP: line per live file, and it is unconditional. After the delta report, upgrade refreshes version / generated_by / last_updated in the frontmatter of every live emitted file, in place:

RESTAMP: .claude/skills/superreview/SKILL.md version "A.B.C" -> "X.Y.Z", generated_by/last_updated refreshed (body untouched)

It is deliberately NOT gated on the verdict above. A plain version bump moves no template line, so every asset reports IDENTICAL — and the emitted SKILL.md frontmatter version: is exactly what /brewcode:setup-status reads to decide stale. An upgrade that skipped it reported success and left the stamp where it was, so the next status printed stale again, forever. Nothing else in the file is touched: doc_type is preserved when present (it is user-owned), the body is compared byte-for-byte afterwards, and any mismatch aborts the run before anything is written — Phase 3 tailoring and Phase 4b self-sync edits survive intact. A second upgrade on the same version is a no-op apart from last_updated.

Then, once the delta is applied (and any restored file has been through Phase 3), promote the new templates to the baseline and clean up with the command the script printed: rm -rf <baseline> && mv <staging>/.template <baseline> && rm -rf <staging> — after which go to Phase 4. Both directories carry a .gitignore of *, so they never enter the user's commits.

SUPERREVIEW_FORCE=1 ... emit overwrites and destroys those corrections — use it only when the user asks for a clean regeneration. emit-agent is unaffected: it is already create-or-reuse.

Phase 3 — Adapt the BLOCK placeholders (AI Edit)

Multi-row tables and multi-line bash cannot go through sed (newlines). Using the Edit tool, replace each block placeholder in the EMITTED files with content you build from Phase 1 analysis.

In <target>/.claude/skills/superreview/SKILL.md:

In <target>/.claude/skills/superreview/references/scope.md:

In <target>/.claude/agents/intent-guard.md — ONLY when the writer printed INTENT_GUARD: CREATED. On INTENT_GUARD: REUSE or INTENT_GUARD: MIGRATED, SKIP this table entirely and edit nothing in that file.

The three BLOCK placeholders are already gone by now — emit replaced each with a runnable GENERIC DEFAULT block that ends in its own marker line. Key every Edit on the marker, not on the old {TOKEN}: your old_string is the seeded block PLUS its marker line, and your new_string is the project-specific replacement WITHOUT any marker (a surviving marker makes validate report the agent UNTAILORED).

These three make the generic drift classes checkable HERE. A project whose planned scale is "one user, local script" and one serving 10k RPS produce OPPOSITE verdicts on the same caching layer — that fact belongs in the invariants table or the intent pass is guessing.

Keep every emitted row pointing at a REAL agent (.claude/agents/ or built-in Explore/Plan/general-purpose), a REAL rule file, a REAL path and a REAL command. Do NOT invent agents, rules or gate scripts. Built-in Explore is the only allowed fallback for an unavailable domain agent.

Phase 4 — Validate (NO {PLACEHOLDER} may remain)

EXECUTE using Bash tool:

bash "${CLAUDE_SKILL_DIR}/scripts/generate.sh" validate && echo "✅ validate" || echo "❌ validate FAILED"

STOP if ❌ — validate reports these classes of failure: an unresolved setup-time {PLACEHOLDER} (runtime tokens like {MODE}, {DEPTH}, {COUNT}, {FILE_LIST}, {SCOPE_BASELINE} are allow-listed and expected to remain), an agent name that resolves to nothing, a missing OR unusable emitted asset (.claude/agents/intent-guard.md counts as unusable when empty or missing its name: intent-guard frontmatter), an unresolved placeholder or a surviving TEMPLATE HEADER in that agent file (it has NO runtime tokens — every {...} in it must be gone), and no project domain expert wired at all (intent-guard is excluded from that count — it is not an expert; the count only credits an agent that appears in a ROUTING row — the group/agent tables or a subagent_type=). Fix via Edit (or go back to Phase 1.6 and create the experts), then re-run validate.

The template checks above run ONLY against an agent file carrying the template stamp. A REUSED hand-written intent-guard is byte-untouchable by contract, so validate says so and does not judge it by template rules.

Shell expansions are NOT placeholders. The scan strips every ${UPPER_SNAKE} before looking for tokens, so Phase 3 evidence commands may freely use ${BASE}, ${HOME}, ${CLAUDE_PLUGIN_ROOT} or any other variable — only a BARE {TOKEN} is reported, and it is reported by name with no surrounding characters. Do not work around a false positive by adding the variable's name to the runtime allow-list.

⚠️ UNTAILORED is a WARNING, not a failure (exit code unaffected): the agent still carries seeded generic BLOCK defaults, i.e. the Phase 3 adaptation was skipped or incomplete. Go back to Phase 3, replace each named block AND its marker, and re-run — never ship an UNTAILORED agent silently.

Ordering matters: emit writes .claude/agents/intent-guard.md BEFORE validate runs, which is what lets the subagent_type allowlist accept intent-guard — it is a real project agent by then. Never run validate on a target that was never emitted.

Phase 5 — Report

Print the generation summary:

superreview generated -> <target>/.claude/skills/superreview/

Stack:          {STACK_LABEL}  (reference: {STACK_REF})
Domain experts: {N} wired ({list}){; created this run: <list>}{; DEGRADED groups: <list>}
General agents: {reviewer?}, {ARBITER_AGENT} (arbiter + validator)
Intent guard:   {CREATED from template | REUSED (already existed — left untouched)}
                tiers: T1={TRACKER_LABEL} / T2={SPEC_LOCATION} / T3={PLAN_LOCATION} / T4={POLICY_LOCATION}
Depth axis:     QUICK (default — intent + gates, 1 spawn) | EXTENDED (full fan-out), inferred from the prompt
Scope baseline: {TRACKER_LABEL}; passes A={SCOPE_AGENT_A} / B={SCOPE_AGENT_B}
Shared surfaces: {N} listed in references/scope.md
Mechanical gates: {list of commands}
Rule pointers:  {N} files referenced (not restated)
File groups:    {N}  ({group->agent})
Focus:          {resolved ordering — fine-tune: <emphasis>}

Files written:
- .claude/skills/superreview/SKILL.md
- .claude/skills/superreview/references/agent-prompt.md
- .claude/skills/superreview/references/scope.md
- .claude/skills/superreview/references/report-template.md
- .claude/skills/superreview/references/{STACK_REF}
- .claude/skills/superreview/.template-baseline/  (pristine templates for `upgrade`; git-ignored)
- .claude/agents/intent-guard.md          {created | REUSED, not written}

Run it:  /superreview "<focus>" [scope]              -> QUICK: intent + gates, 1 agent
         /superreview "deep review of <focus>"       -> EXTENDED: full expert fan-out + validation

Say the depth axis out loud in the summary: users who expect the old always-full behaviour must learn that a plain /superreview is now the cheap intent run and that a depth word escalates it. There is no flag to mention.

How the emitted skill behaves (what you are generating)

Recap of the canonical shape the emitted SKILL.md implements (full text in references/SKILL.md.template):

Configuration

Error Handling

References

• references/SKILL.md.template — the emitted SKILL.md (placeholder slots).
• references/agent-prompt.md — runtime expert-selection procedure + domain-owner prompt contract (emitted).
• references/scope.md.template — scope discipline: baseline, ownership, taxonomy, delivery, closeout, gate (emitted).
• references/intent-guard.md.template — the anti-drift agent (asked vs delivered), emitted to .claude/agents/intent-guard.md create-or-reuse.
• references/report-template.md — emitted merged-report layout.
• references/{python,java-kotlin,typescript-react,go}.md — per-stack reference docs (one is emitted).
• scripts/generate.sh — scan / emit / emit-agent / upgrade / enable / disable / uninstall / purge / validate (validate also enforces the domain-expert requirement; emit-agent is the shared intent-guard writer used standalone by /brewcode:teams-setup; upgrade refreshes a live installation without destroying its self-synced edits, diffing the NEW template against the pristine .template-baseline/ copies emit saved).