@groupby/ai-dev 0.5.1 → 0.5.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@groupby/ai-dev",
-  "version": "0.5.1",
+  "version": "0.5.3",
   "description": "Interactive installer for Rezolve Ai development content",
   "type": "module",
   "bin": {

package/teams/snpd/skills/README.md

@@ -0,0 +1,306 @@
+# SNPD Team — SDLC Skills
+
+A set of explicitly-invoked skills that walk a code change through the full
+software-development lifecycle — from a Jira ticket to a draft pull request —
+with a clean, auditable artifact at every step.
+
+Each skill does **one** job, hands off a file, and **stops**. Nothing runs
+automatically; every command must be explicitly invoked (`/jira-spec`,
+`/draft-plan`, etc.). The human stays in control of every transition, and each
+stage leaves a durable artifact the next stage reads.
+
+---
+
+## The Pipeline
+
+```
+   Jira ticket
+       │
+       ▼
+┌──────────────┐   writes    .claude/artifacts/{KEY}_{slug}-spec.md
+│  jira-spec   │ ──────────▶  (verbatim ticket + AI repo context)
+└──────────────┘
+       │
+       ▼
+┌──────────────┐   reads spec, discusses, writes on approval
+│  draft-plan  │ ──────────▶  .claude/artifacts/{KEY}_{slug}-plan.md
+└──────────────┘              (high-level plan, no code)
+       │
+       ▼
+┌──────────────────┐  reads plan, branch + strict TDD, local commits
+│  tdd-implement   │ ─────▶   feature branch {KEY}-{slug}
+└──────────────────┘          + appends Impl Details / Post-Mortem to plan
+       │
+       ▼
+┌──────────────────┐  3 LLM models review the diff, vote on findings
+│ council-review   │ ─────▶   consensus-ranked review (in chat)
+└──────────────────┘
+       │
+       ▼
+┌──────────────┐  pushes branch, opens DRAFT PR on GitHub
+│  draft-pr    │ ─────▶  draft pull request
+└──────────────┘
+
+       ┌─────────────┐
+       │  docs-init   │  (independent — runs on any repo at any time)
+       └─────────────┘
+```
+
+The first five skills form a **linear pipeline** where each stage's output
+becomes the next stage's input. `docs-init` is **independent** and can be run
+on any repo to initialize or refresh project documentation.
+
+---
+
+## Skills
+
+### 1. `jira-spec` — Capture the ticket
+
+| | |
+|---|---|
+| **Trigger** | `/jira-spec S4R-1234` or a Jira URL |
+| **Reads** | Jira ticket (via Atlassian MCP, go-jira CLI, or curl) |
+| **Produces** | `.claude/artifacts/{KEY}_{slug}-spec.md` |
+| **Stops before** | Planning |
+
+Fetches a Jira ticket and writes a development spec. The spec preserves the
+original ticket description **verbatim** (for audit) and adds AI-gathered
+repo context (touch points, patterns, test surface) from a **medium-depth**
+repo scan. If Jira is unreachable, the skill refuses to proceed — it never
+fabricates ticket content.
+
+**Key rules:**
+- Verbatim means verbatim — no paraphrasing the Jira description
+- One spec file per ticket
+- No invented metadata or acceptance criteria
+- Does not start coding or planning
+
+---
+
+### 2. `draft-plan` — Decide the approach
+
+| | |
+|---|---|
+| **Trigger** | `/draft-plan S4R-1234` or path to spec file |
+| **Reads** | `…-spec.md` from `.claude/artifacts/` |
+| **Produces** | `.claude/artifacts/{KEY}_{slug}-plan.md` |
+| **Stops before** | Implementation |
+
+Turns a spec into a discussed, approved, high-level implementation plan.
+Performs a **deep** codebase review (deeper than jira-spec) — reads relevant
+files end-to-end, traces data flow across layers, checks architecture and
+conventions docs. Presents the plan in chat (Goal, Approach, Affected areas,
+Sequencing, Test strategy, Risks, Out of scope) and **discusses it with the
+user** before writing.
+
+**Key rules:**
+- High-level by default — no line numbers, no code snippets
+- Every cited file path is verified to exist in the repo
+- The plan must trace back to the spec's acceptance criteria
+- Only writes the plan file on explicit user approval
+- Never starts implementation
+
+---
+
+### 3. `tdd-implement` — Build with strict TDD
+
+| | |
+|---|---|
+| **Trigger** | `/tdd-implement S4R-1234` or path to plan file |
+| **Reads** | `…-plan.md` from `.claude/artifacts/` + `docs/conventions.md`, `docs/architecture.md` |
+| **Produces** | Feature branch `{KEY}-{slug}` with squashed commit; plan file updated with Implementation Details + Post-Mortem |
+| **Stops before** | Push / PR |
+
+Implements an approved plan using strict, phase-bound TDD on a feature
+branch. For each phase: writes failing tests → commits → implements until
+green → commits. Supports resuming interrupted sessions. Runs the project's
+full verification gate before declaring completion.
+
+**Key rules:**
+- Never assumes the default branch is `main` — detects dynamically
+- Strict TDD per phase (never batch tests up-front)
+- Every commit message starts with `{KEY}:`
+- Discoveries classified as trivial/plan-affecting/spec-affecting with
+  appropriate handling
+- Never pushes, never opens a PR
+- Squash via `git reset --soft`, not interactive rebase
+
+---
+
+### 4. `council-review` — Multi-model review before the PR
+
+| | |
+|---|---|
+| **Trigger** | `/council-review`, "council review my changes", "multi-model review" |
+| **Reads** | The diff (local changes, staged, branch, last N commits, or a PR) + repo config/conventions |
+| **Produces** | A single consensus-ranked review **in chat** (no file artifact) |
+| **Stops before** | Pushing / opening a PR |
+
+Runs a high-signal, consensus-driven code review by spawning **three
+independent `code-review` sub-agents on different LLM models**
+(`claude-opus-4.8`, `gpt-5.3-codex`, `gpt-5.5`) — inspired by
+[Karpathy's LLM Council](https://github.com/karpathy/llm-council). All three
+get the **identical** prompt and diff, then their findings are deduplicated,
+scored by agreement (🟢 unanimous / 🟡 majority / 🔵 solo), and ranked by
+agreement then severity. Different models catch different things, so requiring
+consensus drops noise and raises signal.
+
+This is the **quality gate between `tdd-implement` and `draft-pr`**: review the
+implemented diff, address the findings, then open the draft PR with confidence.
+
+**Key rules:**
+- Identical prompts for all reviewers — fair comparison is the whole point
+- No model bias — agreement count is the only ranking signal
+- Always launches all 3 agents in parallel, never sequentially
+- Always shows which models agreed on each finding (transparency)
+- Never generates hallucinated replacement code during synthesis
+- On severity disagreement, uses the highest severity any reviewer assigned
+
+---
+
+### 5. `draft-pr` — Open the draft PR
+
+| | |
+|---|---|
+| **Trigger** | `/draft-pr` |
+| **Reads** | Plan file (preferred), spec file (for AC), or commit history (fallback) |
+| **Produces** | Draft pull request on GitHub |
+| **Stops before** | Marking ready / assigning reviewers |
+
+Pushes the current branch and opens a **draft** pull request on GitHub.
+Resolves the PR template (`.github/PULL_REQUEST_TEMPLATE.md`), derives
+content from the plan and spec files, shows a full preview for confirmation,
+then pushes (fast-forward only) and creates the draft PR.
+
+**Key rules:**
+- Always `--draft` — never marks the PR ready
+- Shows a full preview before any push or PR creation
+- Leaves all template `- [ ]` checkboxes unchecked
+- Never assigns reviewers, labels, or milestones
+- Never force-pushes
+- Never invents acceptance criteria or test results
+
+---
+
+### 6. `docs-init` — Initialize or refresh project docs
+
+| | |
+|---|---|
+| **Trigger** | `/docs-init` or "update the docs", "refresh project documentation" |
+| **Reads** | The entire repo (build files, source, CI, deploy configs, etc.) |
+| **Produces** | `README.md`, `CLAUDE.md`, and `docs/` folder (architecture, local-setup, conventions, operations, decisions) |
+| **Stops before** | Writing anything — presents an audit report first |
+
+Initializes or refreshes the canonical documentation structure. Works in
+two modes:
+
+- **Init mode** — `docs/` is missing or incomplete. Drafts all seven
+  canonical files from a fresh repo scan.
+- **Refresh mode** — `docs/` exists. Audits each file for outdated content,
+  drift, and new opportunities.
+
+Includes a **verification checklist** — every command, config key, directory
+description, and workflow trigger is confirmed against actual source files
+before inclusion. Presents a human-readable audit report and applies changes
+only after explicit user approval.
+
+**Key rules:**
+- Never writes files before user approval
+- `decisions.md` is append-only
+- Preserves `> **Scope:**` blocks on every edit
+- Verifies every factual claim against source
+- `CLAUDE.md` ≤ 40 lines, `README.md` ≤ 30 lines
+
+---
+
+## How the Skills Connect
+
+### Artifact Flow
+
+```
+Jira Ticket
+    │
+    │  /jira-spec
+    ▼
+{KEY}_{slug}-spec.md          ◄── verbatim ticket + shallow repo context
+    │
+    │  /draft-plan
+    ▼
+{KEY}_{slug}-plan.md          ◄── approved high-level plan
+    │
+    │  /tdd-implement
+    ├──▶ feature branch       ◄── squashed commit with code changes
+    ▼
+{KEY}_{slug}-plan.md          ◄── updated with Implementation Details + Post-Mortem
+    │
+    │  /council-review
+    ▼
+Consensus review (in chat)    ◄── 3 models vote; address findings before the PR
+    │
+    │  /draft-pr
+    ▼
+Draft Pull Request            ◄── body sourced from plan + spec
+```
+
+All spec and plan artifacts live in `.claude/artifacts/` within the repo,
+using a consistent naming convention: `{KEY}_{slug}-spec.md` →
+`{KEY}_{slug}-plan.md`. The `-spec` and `-plan` suffixes are mandatory.
+
+### Separation of Concerns
+
+| Boundary | Meaning |
+|---|---|
+| Spec ≠ Plan | The spec records *what the ticket asks*; the plan decides *how to build it* |
+| Plan ≠ Code | The plan describes the approach at the level of files and phases — no code |
+| Build ≠ Ship | Implementation produces a local branch only — no push, no PR |
+| Code ≠ Review | The council reviews the diff and surfaces findings — it never edits code or ships |
+| PR ≠ Merge | The PR is always a *draft* — marking ready is the human's call |
+
+Each boundary is a **human checkpoint**. No skill silently rolls into the
+next. Approval at one stage authorizes *only* that stage's output.
+
+### docs-init Integration
+
+`docs-init` is not part of the linear pipeline but supports it:
+
+- **draft-plan** reads `docs/architecture.md`, `docs/conventions.md`, and
+  `docs/decisions.md` during its deep codebase review.
+- **tdd-implement** loads `docs/conventions.md` and `docs/architecture.md`
+  before writing any code, and references them for style and patterns.
+- **tdd-implement** may suggest entries for `docs/decisions.md` in its
+  Post-Mortem section (but never writes them directly).
+
+Running `/docs-init` on a repo before starting the pipeline ensures the
+plan and implementation stages have reliable documentation to reference.
+
+---
+
+## Typical End-to-End Run
+
+```bash
+/jira-spec S4R-10453            # → S4R-10453_mongo-cluster-routing-spec.md
+/draft-plan S4R-10453           # discuss → approve → …-plan.md
+/tdd-implement S4R-10453        # branch + TDD + squash; plan updated
+/council-review                 # 3-model review of the diff; address findings
+/draft-pr                       # confirm → draft PR on GitHub
+```
+
+---
+
+## Conventions Shared Across All Skills
+
+- **Explicit invocation only.** None auto-trigger on keywords.
+- **Artifacts live in the repo.** All specs and plans go to
+  `.claude/artifacts/`, never `~/.claude/`.
+- **Each stage stops at a human checkpoint.** No skill silently continues
+  into the next.
+- **No fabrication.** Ticket text, acceptance criteria, file paths, and test
+  results are verified or quoted — never invented.
+- **Source control hygiene.** Commits start with the Jira key (`{KEY}: …`).
+
+---
+
+## Also in This Folder
+
+- `../github/PULL_REQUEST_TEMPLATE.md` — the SNPD team's PR template,
+  used by `draft-pr` when resolving templates.

package/teams/snpd/skills/council-review/SKILL.md

@@ -0,0 +1,243 @@
+---
+name: council-review
+description: "Multi-model code review council inspired by Karpathy's LLM Council. Spawns 3 sub-agents on different models (Claude Opus 4.8, GPT-5.3 Codex, GPT-5.5) to independently review code changes, then synthesizes and votes on the best comments to produce a unified, high-signal review. Use when the user says /council-review, 'council review', 'multi-model review', 'review council', or 'LLM council'."
+---
+
+# LLM Council Code Review
+
+## Purpose
+
+Provide a high-quality, consensus-driven code review by running **three independent
+reviewers on different LLM models**, then synthesizing their findings into a single
+review ranked by agreement and severity — similar to
+[Karpathy's LLM Council](https://github.com/karpathy/llm-council).
+
+The insight: different models catch different things. One model may spot a race
+condition another misses; one may flag a security issue the others gloss over.
+By requiring consensus, noise drops and signal rises.
+
+## Models Used (The Council)
+
+| Seat       | Model ID            | Strengths                                      |
+|------------|---------------------|-------------------------------------------------|
+| Reviewer A | `claude-opus-4.8`   | Deep reasoning, architecture, subtle logic bugs |
+| Reviewer B | `gpt-5.3-codex`     | Code-native, practical fixes, test gaps          |
+| Reviewer C | `gpt-5.5`           | Broad knowledge, security, API design            |
+
+## Trigger
+
+Activate this skill when the user says any of:
+- `/council-review`
+- `council review my changes`
+- `multi-model review`
+- `LLM council review`
+- `review council`
+
+## Inputs
+
+The user may provide:
+- **No argument** → review local uncommitted changes (staged + unstaged)
+- **`--staged`** → review only staged changes
+- **`--branch`** → review current branch diff vs `origin/main`
+- **`--commits <N>`** → review the last N commits (ignores uncommitted changes)
+- **`--commits <sha>..<sha>`** → review a specific commit range
+- **`--pr <number>`** → review a specific GitHub PR
+- **A file path or glob** → review only those files
+
+Natural language also works:
+- "review my last 2 commits" → same as `--commits 2`
+- "review last 3 commits before I open a PR" → same as `--commits 3`
+
+## Workflow
+
+### Phase 0: Repo Discovery
+
+Before reviewing any code, discover the **current repo's own rules**. Do not
+carry assumptions from another repo.
+
+1. **Confirm repository scope:**
+   - Run `git status --short` and `git branch --show-current`.
+   - Identify the repo root and project type.
+
+2. **Discover review configuration:**
+   - Check for these files and read them if present:
+     - `.github/workflows/claude-pr-review.yml` or `.github/workflows/claude.yml`
+     - `.github/workflows/build-pr.yaml`
+     - `.github/PULL_REQUEST_TEMPLATE.md`
+     - `.github/CODEOWNERS`
+   - Run this skill's bundled `scripts/summarize_review_config.py` script for a
+     quick context summary — it is repo-agnostic and works on any repository.
+     Resolve the script from this skill's own base directory (shown in your skill
+     context; do not hard-code a personal/author path) and pass the current repo
+     root as its argument:
+
+     ```bash
+     # <skill-dir> = this skill's base directory, e.g.
+     #   macOS/Linux: ~/.copilot/skills/council-review (or ~/.agents/skills/...)
+     #   Windows:     %USERPROFILE%\.copilot\skills\council-review
+     python3 "<skill-dir>/scripts/summarize_review_config.py" .   # use `python` on Windows
+     ```
+
+     If Python is unavailable, fall back to reading the config files above manually.
+
+3. **Discover repo guidance (read if present):**
+   - `.github/copilot-instructions.md`
+   - `CLAUDE.md`, `AGENTS.md`
+   - `docs/conventions.md`, `docs/project-rule.md`, `docs/source-control.md`
+   - `README.md` (skim for architecture/setup sections)
+
+4. **Detect technology profile:**
+   Scan build files and guidance docs for technology markers. Apply the
+   matching profile from `references/technology-profiles.md`. Only apply
+   rules that the **current repo actually uses**.
+
+   Key markers to scan for:
+   - Java/Gradle: `build.gradle`, `build.gradle.kts`, `settings.gradle`
+   - Maven: `pom.xml`
+   - Go: `go.mod`, `Makefile`
+   - Python: `pyproject.toml`, `requirements*.txt`
+   - Node: `package.json`
+
+5. **Build a PROJECT_CONTEXT block** from all discovered information. This
+   block will be injected into every reviewer's prompt so all three models
+   review against the same repo-specific rules.
+
+### Phase 1: Gather the Diff
+
+1. Determine the review scope based on user input:
+   - **Local changes (default):** If working tree has edits, use `git diff HEAD`
+     (includes staged + unstaged). If working tree is clean but branch has
+     commits, compare against the PR base: `git diff origin/main...HEAD`.
+     If `origin/main` is not available, inspect upstream and available remotes.
+   - **Staged only:** `git diff --cached`
+   - **Branch diff:** `git diff origin/main...HEAD`
+   - **Last N commits:** `git diff HEAD~N..HEAD` (ignores working tree entirely)
+     Example: `--commits 2` → `git diff HEAD~2..HEAD`
+   - **Commit range:** `git diff <sha1>..<sha2>` for explicit ranges
+   - **PR:** `gh pr diff <number>`
+2. Also gather context:
+   - `git diff --stat` for the file change summary
+   - The PROJECT_CONTEXT block built in Phase 0
+3. If the diff is empty, tell the user and stop.
+4. If the diff is very large (>5000 lines), warn the user and suggest narrowing scope.
+5. **Classify the change** (helps reviewers focus):
+   - API/controller, service/orchestration, repository/database, search engine,
+     Mongo query/indexing, cache, Pub/Sub/messaging, auth/security, feature flags,
+     docs, tests, build/dependency, deployment, or tooling.
+
+### Phase 2: Deploy the Council (Parallel Sub-Agents)
+
+Launch **exactly 3 `code-review` agents in parallel** using the `task` tool, each
+with a different `model` parameter. All three receive the **identical prompt** so
+their reviews are directly comparable.
+
+**CRITICAL: Launch all 3 in a single response — they run in parallel.**
+
+Each agent receives the prompt from `references/reviewer-prompt.md`, with the
+diff and project context injected.
+
+```
+Agent A: task(agent_type="code-review", model="claude-opus-4.8", ...)
+Agent B: task(agent_type="code-review", model="gpt-5.3-codex", ...)
+Agent C: task(agent_type="code-review", model="gpt-5.5", ...)
+```
+
+All three agents run in `mode="background"`. Wait for all three to complete
+before proceeding to Phase 3.
+
+### Phase 3: Collect & Parse Reviews
+
+Read all three agent results. Each agent returns findings in the structured
+format defined in `references/reviewer-prompt.md`. Extract:
+- File path and line range for each comment
+- Severity (P1/P2/P3)
+- Category (bug, security, performance, style, test-gap, design)
+- The finding description and suggested fix
+
+### Phase 4: Council Vote — Synthesize & Rank
+
+This is the core "council" step. Process the three reviews:
+
+#### 4a. Deduplicate
+
+Group comments that refer to the **same issue** (same file, overlapping lines,
+same root cause). Two comments are "the same issue" if they:
+- Point to the same file and overlapping line range, AND
+- Describe the same underlying problem (even in different words)
+
+#### 4b. Score by Agreement
+
+For each unique issue, count how many of the 3 reviewers flagged it:
+
+| Agreement | Label        | Weight |
+|-----------|--------------|--------|
+| 3/3       | 🟢 Unanimous | High   |
+| 2/3       | 🟡 Majority  | Medium |
+| 1/3       | 🔵 Solo      | Low    |
+
+#### 4c. Rank
+
+Sort the final list by:
+1. **Agreement** (unanimous > majority > solo)
+2. **Severity** (P1 > P2 > P3) within each agreement tier
+3. Within the same tier+severity, keep the most actionable/clear version of
+   the comment (pick the best phrasing from whichever model wrote it)
+
+#### 4d. Solo Comment Filter
+
+Solo comments (1/3) are **not discarded** but are presented separately under
+a "Minority Opinions" section. They may contain genuine catches the other
+models missed, or they may be noise. Let the user decide.
+
+### Phase 5: Present the Council Review
+
+Output the review using the format in `references/output-format.md`.
+
+## Hard Rules
+
+- **Identical prompts.** All three reviewers get exactly the same input.
+  Do not customize prompts per model — the whole point is fair comparison.
+- **No model bias.** Do not weight one model's opinion over another during
+  voting. Agreement count is the only ranking signal.
+- **Parallel launch.** Always launch all 3 agents in a single response.
+  Never run them sequentially.
+- **Transparency.** Always show which models agreed on each finding.
+- **No hallucinated code.** Do not generate suggested replacement code
+  yourself during synthesis. Use the reviewers' suggestions as-is.
+- **Severity consistency.** If reviewers disagree on severity for the same
+  issue, use the highest severity any reviewer assigned.
+- **Signal over noise.** The council exists to reduce noise. If a comment
+  is unclear or contradictory across reviewers, note the disagreement rather
+  than forcing consensus.
+
+## Configuration
+
+The user can customize the council by telling the agent:
+- Different models: "use Opus 4.5 instead of Opus 4.8"
+- Different number of reviewers: "use 5 models" (but default is 3)
+- Focus areas: "focus on security" or "focus on performance"
+- Strictness: "be strict" (lower the noise threshold) or "only critical" (P1 only)
+
+## Error Handling
+
+- If one agent fails, proceed with the remaining 2. Note the failure.
+- If two agents fail, fall back to a single-model review and explain.
+- If all three fail, tell the user and suggest running a simple code-review instead.
+
+## Phase 6 (Optional): Post-Review Verification
+
+After presenting the council review, **offer** to run verification. Do not
+run automatically — the user may just want the review.
+
+If the user accepts:
+
+1. **Run targeted tests** for changed files using the repo's test command
+   (discovered in Phase 0). Prefer the narrowest test scope first.
+2. **Run the PR build command** when feasible (from `build-pr.yaml`).
+3. **Run `git diff --check`** for whitespace issues.
+4. **Check PR template compliance** — if the repo has a PR template with
+   checkboxes, note which items are affected by the change.
+5. **Report CODEOWNERS** — if the repo has CODEOWNERS, note which owners
+   are relevant for the changed files.
+
+Append verification results to the review output.

package/teams/snpd/skills/council-review/references/output-format.md

@@ -0,0 +1,108 @@
+# Council Review Output Format
+
+Use this format when presenting the synthesized council review to the user.
+
+---
+
+## Header
+
+```
+# 🏛️ LLM Council Code Review
+
+**Scope:** <description of what was reviewed — branch, PR #, local changes>
+**Council:** Claude Opus 4.8 · GPT-5.3 Codex · GPT-5.5
+**Date:** <current date>
+**Verdict:** <PASS | PASS WITH COMMENTS | NEEDS CHANGES>
+```
+
+### Verdict Rules
+- **PASS** — No P1 or P2 issues found by any reviewer
+- **PASS WITH COMMENTS** — No P1 issues; some P2/P3 found
+- **NEEDS CHANGES** — At least one P1 issue found, OR 3+ P2 issues with majority agreement
+
+---
+
+## Consensus Findings (2/3 or 3/3 agreement)
+
+These are issues flagged by multiple models independently. High confidence.
+
+For each finding:
+
+```
+### <N>. <One-line summary>
+🟢 Unanimous (3/3) | 🟡 Majority (2/3)
+**Severity:** P1 | P2 | P3
+**Category:** <category>
+**File:** `<path>` (lines ~<range>)
+**Agreed by:** Opus 4.8 ✓ · Codex 5.3 ✓ · GPT-5.5 ✓
+
+<Best description from the reviewers. Pick the clearest, most actionable version.>
+
+**Suggested fix:**
+<Most concrete suggestion from any reviewer.>
+```
+
+---
+
+## Minority Opinions (1/3 — solo catches)
+
+These were flagged by only one model. They may be genuine catches the others
+missed, or false positives. Included for completeness.
+
+For each:
+
+```
+### <N>. <One-line summary>
+🔵 Solo — flagged by <model name> only
+**Severity:** P1 | P2 | P3
+**Category:** <category>
+**File:** `<path>` (lines ~<range>)
+
+<Description from the flagging model.>
+
+**Suggested fix:**
+<Suggestion if provided.>
+```
+
+---
+
+## Review Statistics
+
+```
+| Metric                    | Value |
+|---------------------------|-------|
+| Total unique issues       | <N>   |
+| Unanimous (3/3)           | <N>   |
+| Majority (2/3)            | <N>   |
+| Solo (1/3)                | <N>   |
+| P1 (Critical)             | <N>   |
+| P2 (Important)            | <N>   |
+| P3 (Minor)                | <N>   |
+| Files reviewed             | <N>   |
+| Lines changed              | +<N> / -<N> |
+```
+
+---
+
+## Model Agreement Matrix (optional, for large reviews)
+
+Show which model caught what. Only include for reviews with 5+ findings.
+
+```
+| # | Finding                        | Opus 4.8 | Codex 5.3 | GPT-5.5 |
+|---|--------------------------------|----------|-----------|---------|
+| 1 | Race condition in UserService   | ✓        | ✓         | ✓       |
+| 2 | Missing null check in parser    | ✓        | ✓         |         |
+| 3 | SQL injection in search filter  |          | ✓         | ✓       |
+| 4 | Unused import (solo)            | ✓        |           |         |
+```
+
+---
+
+## Footer
+
+```
+---
+*Review generated by LLM Council · 3 independent models · consensus-ranked*
+*Models may miss issues. This review supplements, not replaces, human judgment.*
+```