@groupby/ai-dev 0.5.19 → 0.5.21

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@groupby/ai-dev",
-  "version": "0.5.19",
+  "version": "0.5.21",
   "description": "Interactive installer for Rezolve Ai development content",
   "type": "module",
   "bin": {
@@ -15,7 +15,7 @@
   "scripts": {
     "prebuild": "rm -rf skills teams toolsets && cp -r ../skills ./skills && cp -r ../teams ./teams && cp -r ../toolsets ./toolsets",
     "build": "tsup",
-    "prepublishOnly": "npm run build",
+    "prepare": "npm run build",
     "test": "vitest run",
     "test:watch": "vitest",
     "test:coverage": "vitest run --coverage"

package/skills/README.md

@@ -4,7 +4,7 @@ This folder manages all skills, archived skills, and examples/instructions on us
 
 All skills in this `skills/library/` should represent _generally useful skills_ that might be used across teams.
 
-If any particular skill goes missing, note that it may have simply been archived (see [the archive](skills/archived/)) and may no longer be recommended for use. Ideally skills are not simply deleted from this repository, since others may be expecting them to be there.
+If any particular skill goes missing, note that it may have simply been archived (see [the archive](archived/)) and may no longer be recommended for use. Ideally skills are not simply deleted from this repository, since others may be expecting them to be there.
 
 ## Usage
 
@@ -58,4 +58,45 @@ license: Complete terms in LICENSE.txt
 See `docs/ai/skills/frontend-design/SKILL.md` and follow closely.
 ```
 
+## Third-party skills
+
+Skills authored outside the company can be vendored into a team's folder under
+`teams/<team>/third-party/<lib>/<skill>/`, each with the upstream `SKILL.md`
+(vendored verbatim at a pinned commit) plus a `skill-meta.yml` provenance
+sidecar. They are curated per team by evaluation status: `evaluating`,
+`recommended`, or `deprecated`.
+
+The lifecycle is fetch, vendor, evaluate, and promote:
+
+1. **Fetch + Vendor** in one step with the authoring command — paste a GitHub
+   URL to the skill folder and it writes the pinned `SKILL.md` plus a generated
+   `skill-meta.yml`:
+   ```bash
+   npx @groupby/ai-dev vendor <github-url> --team <team>
+   ```
+   Or do it manually: fetch into a scratch directory (for example,
+   `npx skills add <owner/repo> --copy`), then copy the single skill folder into
+   `teams/<team>/third-party/<lib>/<skill>/`, recording the source, pinned
+   commit, and `status: evaluating` in `skill-meta.yml`.
+2. **Evaluate** it in a real project with
+   `npx @groupby/ai-dev install skill <skill-name>` (naming a skill installs it
+   regardless of status).
+3. **Promote** it to `status: recommended` once proven, or graduate it into
+   `skills/library/` as a first-party skill (dropping the sidecar).
+
+A `recommended` third-party skill installs with its team like any other skill;
+`evaluating` and `deprecated` skills are held back from team installs unless you
+pass `--include-evaluating` or `--include-deprecated`. Naming a skill directly
+with `install skill <name>` always installs it. If a name is shared by more than
+one skill in the same tier (for example two teams that each vendored it), the CLI
+lists the matches and asks you to scope it with `install skill <team>/<name>` or
+`--team <team>`. See
+[content conventions](../docs/content-conventions.md) for the `skill-meta.yml`
+schema and the full rules.
+
+The `skill-meta.yml` sidecar is required. A vendored skill missing it has no
+provenance or status, so `list` shows it as `[no status] unknown source`, team
+installs skip it, and installing it by name still works but prints a
+`no recorded status` note. Add the sidecar to make it a fully curated skill.
+
 Note that we MUST include the skill boilerplate in any official skills location (eg. `.github/skills/`, etc.) to enable discovery and usage. We then copy the entire skill into `docs/ai/skills/` to leave it intact, though we don't technically need the boilerplate.

package/teams/OOF/skills/oof-review/SKILL.md

@@ -0,0 +1,319 @@
+---
+name: oof-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
+  /oof-review, /council-review, 'council review', 'multi-model review', 'review
+  council', or 'LLM council'.
+---
+
+<!-- Based on the snpd council-review skill. Special thanks to Haris Dervisevic for the original work. -->
+
+# 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:
+- `/oof-review`
+- `/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 [<target>]`** → review current branch diff vs `origin/main` (default) or a custom target, e.g. `--branch origin/develop` or `--branch origin/release/1.2`
+- **`--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. **Check write-access (advisory):**
+
+   Read `.claude/settings.local.json` in the repo root (if it exists) and check
+   whether it contains `"worktree": { "bgIsolation": "none" }`.
+
+   - **If the setting is absent or the file does not exist:** Inform the user
+     with a one-line notice, then **continue** — do not stop:
+
+     > ℹ️ `.claude/settings.local.json` does not have `bgIsolation: none`.
+     > If the skill is invoked as a background session, writing the report to
+     > `docs/reviews/` may fail. See Phase 5 for the fallback.
+
+   - **If the setting is present:** Continue normally.
+
+2. **Confirm repository scope:**
+   - Run `git status --short` and `git branch --show-current`.
+   - Identify the repo root and project type.
+
+3. **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 `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 and pass the
+     current repo root as its argument:
+
+     ```bash
+     # The skill base directory for this repo is: docs/ai/skills/oof-review/
+     python3 "docs/ai/skills/oof-review/summarize_review_config.py" .
+     ```
+
+     **This step is MANDATORY. Do NOT skip it.**
+     Do NOT fall back to manual reading unless `python3` returns a
+     "command not found" error (i.e. Python is genuinely absent on the machine).
+     Print the full script output verbatim under a `## Repo Config Summary`
+     heading before proceeding to Phase 1.
+
+4. **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)
+
+5. **Detect technology profile:**
+   Scan build files and guidance docs for technology markers. Apply the
+   matching profile from `technology-profiles.md` (in this skill's directory). 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`
+
+6. **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 0 Completion Checklist
+
+Before moving to Phase 1, confirm each item explicitly in your response:
+
+| Step | Status | Notes |
+|------|--------|-------|
+| `.claude/settings.local.json` has `bgIsolation: none` | ✅ present / ℹ️ absent (advisory) | |
+| `git status` + current branch | ✅ / ❌ | |
+| `summarize_review_config.py` ran | ✅ ran / ❌ skipped — reason: _______ | Output printed above |
+| Guidance docs read (CLAUDE.md, copilot-instructions, etc.) | ✅ / ❌ | |
+| Technology profile identified | ✅ `<profile name>` | |
+
+A model that skips a step **must** write `❌ skipped — reason: <explicit reason>` in
+the table. Silent omission is not acceptable.
+
+### Phase 1: Gather the Diff
+
+1. Determine the review scope based on user input:
+   - **Local changes (default):** If working tree has edits, use `git --no-pager diff HEAD`
+     (includes staged + unstaged). If working tree is clean but branch has
+     commits, compare against the PR base: `git --no-pager diff origin/main...HEAD`.
+     If `origin/main` is not available, inspect upstream and available remotes.
+     When the user specifies `--branch <target>`, use that target instead of `origin/main`.
+   - **Staged only:** `git --no-pager diff --cached`
+   - **Branch diff:** `git --no-pager diff <target>...HEAD` where `<target>` is the branch supplied with `--branch` (defaults to `origin/main` when not specified)
+   - **Last N commits:** `git --no-pager diff HEAD~N..HEAD` (ignores working tree entirely)
+     Example: `--commits 2` → `git --no-pager diff HEAD~2..HEAD`
+   - **Commit range:** `git --no-pager diff <sha1>..<sha2>` for explicit ranges
+   - **PR:** `gh pr diff <number>`
+2. Also gather context:
+   - `git --no-pager 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 `reviewer-prompt.md` (in this skill's directory),
+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 `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: Write and Present the Council Review
+
+1. **Determine the output file path.**
+   Use the format: `docs/reviews/oof-review-<YYYY-MM-DD>-<branch-or-scope>.md`
+   - Replace `<YYYY-MM-DD>` with today's date.
+   - Replace `<branch-or-scope>` with the sanitized current branch name (slashes → dashes)
+     or a short descriptor when reviewing uncommitted changes (e.g. `local-changes`).
+   - Example: `docs/reviews/oof-review-2026-08-18-feature-my-branch.md`
+
+2. **Write the review to the file** using the format in `output-format.md`
+   (in this skill's directory). Create the `docs/reviews/` directory if it does not exist.
+
+   > **IMPORTANT — do NOT enter a worktree.** Write the file directly to the
+   > user's current working tree using the Write tool. Entering a worktree
+   > creates an isolated branch and an extra checkout of the repository, which
+   > is unnecessary and confusing for a read-only report file.
+   >
+   > **Do NOT `git add`, `git commit`, or run any git command after writing.**
+   > The deliverable is the file on disk. The user decides whether and when to
+   > commit it.
+
+   **If writing fails** (e.g. the isolation guard is still active despite the
+   Phase 0 check): print the **full review content** as a fenced Markdown
+   block in chat, prefixed with:
+
+   > ⚠️ Could not write to disk — see below. Paste this into
+   > `docs/reviews/<filename>.md` manually, or add
+   > `"worktree": {"bgIsolation": "none"}` to `.claude/settings.local.json` and re-run.
+
+3. **Confirm in chat** — after writing the file, post a short summary message:
+   ```
+   ✅ Council review written to `docs/reviews/council-review-<date>-<scope>.md`
+   Verdict: <PASS | PASS WITH COMMENTS | NEEDS CHANGES>
+   Top findings: <1-line summary of the highest-priority issues>
+   ```
+
+## 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.
+- **No worktree for review output.** Writing the review file is not a code
+  change. Do not call `EnterWorktree` at any point during this skill.
+- **No auto-commit.** Do not run any git command after writing the review
+  file. The user owns the commit decision.
+
+## 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 --no-pager 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/OOF/skills/oof-review/output-format.md

@@ -0,0 +1,166 @@
+# 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.
+
+**Severity-based format for consensus findings:**
+
+> [!IMPORTANT]
+> **Emoji legend — use this table as the single source of truth. Do NOT apply the P3 majority emoji (🟡) to P2 findings.**
+>
+> | Severity | Unanimous (3/3) | Majority (2/3) | Solo (1/3) |
+> |----------|----------------|----------------|------------|
+> | P1       | 🚨              | 🚨              | 🚨          |
+> | P2       | 🔴              | 🔴              | 🔴          |
+> | P3       | 🔴              | 🟡              | 🔵          |
+>
+> The only cell that uses 🟡 is **P3 + Majority (2/3)**. Every other P2 cell is 🔴.
+
+For **P1 (Critical)** consensus findings, wrap in a `> [!CAUTION]` blockquote regardless of agreement level:
+
+```
+> [!CAUTION]
+> ### 🚨 <N>. <One-line summary> — CRITICAL
+> 🚨 Unanimous (3/3) | 🚨 Majority (2/3) — **Severity: P1**
+> **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.>
+```
+
+For **P2 (Important)** consensus findings — **both unanimous AND majority use 🔴**:
+
+```
+### <N>. <One-line summary>
+🔴 Unanimous (3/3) | 🔴 Majority (2/3)   ← both red for P2
+**Severity:** P2
+**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.>
+```
+
+For **P3 (Minor)** consensus findings — **majority drops to 🟡 (yellow), unlike P2 which stays 🔴)**:
+
+```
+### <N>. <One-line summary>
+🔴 Unanimous (3/3) | 🟡 Majority (2/3)   ← majority is yellow ONLY for P3
+**Severity:** 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.
+
+**Severity-based indicators for solo catches:**
+- P1 (Critical): Use `🚨 CRITICAL — Solo catch by <model name>` — render with a blockquote warning prefix to make it visually unmissable
+- P2 (Important): Use `🔴 Solo — flagged by <model name> only`
+- P3 (Minor): Use `🔵 Solo — flagged by <model name> only`
+
+For P1 solo catches, wrap the entire finding in a `> [!CAUTION]` blockquote to trigger a rendered red alert panel:
+
+```
+> [!CAUTION]
+> ### 🚨 <N>. <One-line summary> — CRITICAL SOLO CATCH
+> 🚨 CRITICAL — Solo catch by <model name> only — **not confirmed by other reviewers but high-impact if correct**
+> **Severity:** P1
+> **Category:** <category>
+> **File:** `<path>` (lines ~<range>)
+>
+> <Description from the flagging model.>
+>
+> **Suggested fix:**
+> <Suggestion if provided.>
+```
+
+For P2/P3 solo catches, use the standard format:
+
+```
+### <N>. <One-line summary>
+🔴 Solo — flagged by <model name> only  ← use 🔴 for P2, 🔵 for P3
+**Severity:** 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)            | ✓        |           |         |
+```
+
+---

package/teams/OOF/skills/oof-review/reviewer-prompt.md

@@ -0,0 +1,99 @@
+# Reviewer Prompt Template
+
+You are one member of a 3-model code review council. Your job is to independently
+review the code changes below and produce high-signal findings. Another process
+will compare your review against two other models' reviews to find consensus.
+
+## Your Review Constraints
+
+- **Only flag things that genuinely matter.** Bugs, security issues, logic errors,
+  performance problems, missing error handling, test gaps for changed code.
+- **Never comment on style, formatting, naming preferences, or trivial matters**
+  unless they cause a real problem (e.g., a misleading variable name that could
+  cause a bug).
+- **Be specific.** Always include the file path, approximate line range, and a
+  concrete description of the problem.
+- **Suggest a fix** when possible. Don't just say "this is wrong" — say what to do.
+- **Don't be redundant.** If two issues share the same root cause, report it once.
+- **Respect repo-specific rules.** The project context below includes this repo's
+  own conventions, technology profile, and CI expectations. Review against THOSE
+  rules, not generic best practices. Do not assume patterns from other repos.
+
+## Project Context
+
+{PROJECT_CONTEXT}
+
+This context was discovered from the repo's own guidance files, CI workflows,
+build configuration, and technology markers. If the context mentions specific
+patterns (e.g., Micronaut DI, tenant isolation, cache key format), verify the
+diff follows them. If the context is silent on something, don't invent rules.
+
+## Technology Profile
+
+{TECHNOLOGY_PROFILE}
+
+## Change Classification
+
+{CHANGE_CLASSIFICATION}
+
+## Review Focus Areas (from repo's CI/review config)
+
+Review against these standard areas, but weight them based on the change
+classification above:
+
+1. **Code quality:** single responsibility, clarity, maintainability, unnecessary
+   complexity/nesting, redundant abstractions, local style conventions.
+2. **Security:** auth, authorization, tenant isolation, input validation, secrets,
+   sensitive data exposure.
+3. **Performance:** database/query shape, cache behavior, external calls,
+   async/blocking boundaries, memory/resource lifecycle.
+4. **Testing:** adequate coverage for changed code, edge cases, missing scenarios.
+5. **Documentation:** README/docs/OpenAPI/API docs accuracy when behavior changes.
+
+## Changed Files Summary
+
+{DIFF_STAT}
+
+## Full Diff
+
+{DIFF}
+
+## Output Format
+
+Return your findings as a structured list. Each finding must follow this exact format:
+
+```
+### Finding <N>
+- **File:** <path/to/file>
+- **Lines:** <start>-<end> (approximate)
+- **Severity:** P1 | P2 | P3
+- **Category:** bug | security | performance | design | test-gap | error-handling | concurrency | data-integrity
+- **Summary:** <one-line summary>
+- **Details:** <1-3 sentences explaining the issue>
+- **Suggestion:** <concrete fix or action>
+```
+
+### Severity Guide
+
+- **P1 — Critical:** Likely bug, security vulnerability, data loss, crash, race condition,
+  or production incident. Must fix before merge.
+- **P2 — Important:** Behavior regression, missing important test, incorrect error handling,
+  performance issue under realistic load. Should fix before merge.
+- **P3 — Minor:** Low-risk test gap, minor inefficiency, documentation inaccuracy.
+  Nice to fix but not blocking.
+
+### What NOT to Report
+
+- Style or formatting preferences
+- "Consider renaming X" suggestions
+- "Add a comment explaining Y" suggestions
+- Import ordering
+- Trailing whitespace
+- Suggestions that don't prevent a real problem
+
+If you find zero genuine issues, return:
+
+```
+### No Issues Found
+The changes look correct. No bugs, security issues, or significant concerns identified.
+```