@groupby/ai-dev 0.5.18 → 0.5.20

package/package.json

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

package/teams/OOF/skills/oof-release-impact-analysis/README.md

@@ -0,0 +1,37 @@
+# OOF Release Impact Analysis
+
+Generates a structured, human-reviewed **Release Impact Analysis** for a critical OOF
+release by correlating the git diff with the surrounding code, linked Jira tickets, and
+live operational signal (GCP Cloud Logging / BigQuery), then optionally publishes it to
+Confluence. Output is AI-generated decision-support and requires human sign-off.
+
+## What it does
+- Resolves the release range (last prod tag → release candidate, or a supplied `base..head`)
+  and gathers signal: diff + changed code and its call sites, linked Jira keys (revert-aware),
+  and — for critical releases — live cloud/outage status, GCP Cloud Logging, and BigQuery.
+- Classifies the blast radius (API/contract, DB/migrations, auth/security, infra/terraform,
+  per-region config, dependencies, cross-service, client compatibility, observability).
+- Produces a consistent, readable report: Found issues → Overview → Cross-service blast
+  radius → Risk assessment + Top risks → Suggested QA focus (non-technical) → Validation
+  performed → Unknowns; with optional Operational context, Pre-launch checklist, and an
+  Engineer detail appendix (`detail=engineer`).
+- Optionally publishes the report to Confluence.
+
+## Prerequisites
+- Read-only git access to the target repo (local clone or `glab` / `gh`).
+- For `depth=full` cloud signal: `gcloud` / `bq` authenticated to the target GCP project.
+- For `publish=confluence`: the Atlassian MCP connector connected.
+- An approved enterprise assistant (no-training / no-retention) — the skill's security
+  guardrails (never ingest secrets, cost-aware cloud access) must be met.
+
+## Inputs
+`repo`, `range`, `critical`, `depth` (`light` | `full`), `detail` (`summary` | `engineer`),
+`publish` (`confluence` | `none`), `gcp_project`.
+
+## Trigger phrases
+- "run impact analysis"
+- "release impact analysis"
+- "analyse this release before we ship"
+
+## Team
+OOF

package/teams/OOF/skills/oof-release-impact-analysis/SKILL.md

@@ -0,0 +1,310 @@
+---
+name: oof-release-impact-analysis
+description: 'Generate a structured Release Impact Analysis for a critical OOF release by correlating git changes with the surrounding code, linked Jira tickets, and live operational signal (cloud/outage status, GCP Cloud Logging, BigQuery), classify the blast radius, and optionally publish to Confluence. Use when the user says "run impact analysis", "release impact analysis", or before a critical release.'
+---
+
+# OOF Release Impact Analysis
+
+**Goal:** For a critical release, produce a structured, human-reviewed **Release Impact
+Analysis** that focuses QA, documents blast radius, and serves as SOC2 change-management
+evidence. The git diff is the *starting point*, not the whole picture — the analysis
+correlates the diff with the surrounding code, the linked Jira tickets, and **live
+operational signal** (cloud/outage status, GCP Cloud Logging, BigQuery) to judge real-world
+impact, not just what a static diff shows.
+
+**Your Role:** You are a release engineer performing change-impact analysis. You are
+precise and conservative: you never overstate confidence, you flag what you *cannot*
+determine from the available signal, and you treat the output as decision-support for a
+human reviewer — never as an automatic release gate.
+
+> ⚠️ AI-generated. This report assists a human decision. It must be reviewed and
+> signed off before it is relied upon. A release is never gated solely on this output.
+
+> 💰 **This deep, multi-source analysis is thorough but expensive** — it burns
+> engineer/agent time, LLM tokens, and real query cost (GCP Logging / BigQuery scanned
+> bytes). Run the **full** analysis only for **critical** releases, and **confirm depth up
+> front** (Step 0) rather than defaulting into it. Non-critical releases should use the
+> lightweight, git-only pass (`depth=light`, no cloud queries, no publish) — or skip the
+> analysis entirely.
+
+## Inputs
+
+- **repo** — Repository to analyse (defaults to the current workspace repo).
+- **range** (optional) — Git range `<base>..<head>`. If omitted, resolve it (see Step 1).
+- **critical** (optional) — Whether this is a critical release. Critical forces `depth=full`
+  **and** `detail=engineer`, and turns on the CDT-parity uplift (deployment/rollback
+  second-order analysis, per-risk severities, a mandatory **Required before production** gate
+  + go/no-go recommendation, and an exhaustive engineer-detail appendix).
+- **depth** (optional) — `light` (git + code only) or `full` (also pulls Jira, cloud/outage
+  status, GCP logs, BigQuery). Defaults to `full` when `critical`, else `light`.
+- **detail** (optional) — output verbosity: `summary` (default) or `engineer`. `engineer`
+  appends the **Required before production** gate and an **Engineer detail** appendix for
+  high-risk / infra-heavy releases; the readable summary stays on top either way. **Critical
+  releases force `engineer`.**
+- **publish** (optional) — `confluence` to publish the report, or `none` (default) to
+  only produce Markdown.
+- **gcp_project** (optional) — GCP project(s) to query for logs/BigQuery (e.g.
+  `bluedot-prod-ause1`). Required for `depth=full` cloud signal.
+
+## Security guardrails (MANDATORY — read before running)
+
+1. **Approved LLM only.** Run this only via an approved enterprise assistant with
+   no-training / no-retention terms. Do not paste diffs into ad-hoc consumer tools.
+2. **Never ingest secrets.** Exclude and never echo the contents of secret-bearing files.
+   Deny-list at minimum: `*.env`, `_config.*.env`, `*.pem`, `*.key`, `*credentials*`,
+   `*secret*`, `serviceAccount*.json`, terraform state, `*.tfvars`. If a diff touches one,
+   report **only the filename and that it changed** — never the values.
+3. **Least privilege.** Read-only git access. Do not push, tag, or modify anything.
+4. **Access-controlled output.** Publish only to an access-controlled Confluence space.
+   Do not expose internal implementation detail to a broad audience.
+5. **Cost-aware cloud access.** GCP Logging / BigQuery queries cost money and scan real
+   data. Always bound queries by the release time window + relevant service/resource, cap
+   scanned bytes, and prefer summaries/counts over dumping rows. Never run unbounded
+   `SELECT *`. Read-only only.
+6. **HALT** if you cannot confirm guardrails 1–2 for the current environment.
+
+## Signal sources (the diff is the starting point, not the whole picture)
+
+Git tells you *what text changed*; these sources tell you *what it actually affects and
+whether it is safe to ship now*. Use them according to `depth`:
+
+- **Git diff + history** (always) — changed files, churn, commit messages, linked tickets.
+- **Surrounding code** (always) — read the changed functions *and their call sites /
+  dependents* in the repo, not just the `+/-` lines, to judge real blast radius. A one-line
+  change to a shared helper can be higher impact than a large isolated feature.
+- **Linked Jira tickets** (`full`) — pull the `BD-xxxx` keys for intent, acceptance
+  criteria, and whether the change is a fix for a known incident.
+- **Cloud / outage status** (`full`) — is the platform currently healthy? Check GCP service
+  health and any ongoing SRE incidents for the target project/region. Releasing into an
+  active outage or degraded dependency raises risk and may warrant a hold.
+- **GCP Cloud Logging (Logs Explorer)** (`full`) — for the services touched, check recent
+  error rates / 5xx / notable log signatures so the analysis reflects the *current* prod
+  behaviour of the code being changed (bounded to a short window).
+- **BigQuery** (`full`) — where relevant (e.g. event/analytics tables), sample real volumes
+  or error patterns for the affected flow (bounded, capped-bytes, aggregate queries only).
+
+## Execution
+
+### Step 0: Confirm scope & depth (ask before spending)
+
+The full analysis costs real time and money, so **confirm depth up front** rather than
+silently defaulting into the expensive path. Unless the user has already specified, ask:
+
+- **Critical release?** The full multi-source pass is intended for critical releases only.
+- **Depth?** `full` — code + Jira + cloud/outage status + GCP Logging + BigQuery: thorough,
+  but burns agent time, LLM tokens, and **real GCP query charges** (Logging + BigQuery
+  scanned bytes). `light` — git + code only: fast and free, no cloud queries, no publish.
+- **Publish?** `confluence`, or Markdown-only (`none`).
+
+If the user defers, default to `full` + `detail=engineer` + publish when `critical`, else
+`light` + `none` — but **don't assume `full` for an unspecified release; ask first.**
+Non-critical releases use `light` or skip the analysis entirely. State the chosen depth (and
+why) at the top of the report.
+
+### Step 1: Resolve the release range
+
+- If `range` is given, use it.
+- Otherwise resolve `<base>` = most recent production tag/release, `<head>` = the release
+  candidate (target branch or RC tag). Prefer, in order:
+  - `git describe --tags --abbrev=0` on the last prod tag, or the last tag matching the
+    project's release pattern (e.g. semantic-release tags), through `HEAD`.
+- State the resolved `base..head`, both short SHAs, and the commit count. If you cannot
+  resolve it confidently, ask the user for the range and HALT.
+
+### Step 2: Gather signal (read-only)
+
+Gather from the sources above, without ever printing secret values. Scale effort to
+`depth`.
+
+**Always (both `light` and `full`):**
+- Changed files with status + churn: `git diff --stat <base>..<head>` and
+  `git diff --name-status <base>..<head>`.
+- Commit messages: `git log --no-merges --pretty='%h %s' <base>..<head>`.
+- Linked work items: Jira keys parsed from commit messages / branch names (e.g. `BD-\d+`).
+  **Revert-aware (critical):** a ticket only counts as *in the release* if its changes survive
+  in the **net** diff. When commits were reverted within the range (net ≠ history), verify
+  whether each ticket's files/content actually survive (e.g. a feature file added then deleted
+  is reverted). List reverted tickets **separately** as *reverted in-range (not shipped)* —
+  never imply reverted work is part of the release.
+- For non-secret files, inspect the diff **and the surrounding code / call sites** to judge
+  real blast radius. For deny-listed files, record filename + "changed (contents not
+  inspected)".
+
+**Additionally when `depth=full` (critical releases):**
+- **Jira:** read each linked ticket for intent / acceptance criteria / incident linkage.
+- **Cloud / outage status:** confirm the target project/region is healthy (GCP service
+  health + any ongoing SRE incidents). Note anything degraded.
+- **GCP Cloud Logging:** for each touched service, sample recent error/5xx signatures in a
+  bounded window (e.g. last 1–24h) for `gcp_project` — e.g.
+  `gcloud logging read '<filter> severity>=ERROR' --project <p> --freshness=24h --limit=50`.
+- **BigQuery:** where the change touches an event/analytics flow, run a bounded, aggregate
+  query (capped bytes, `--maximum_bytes_billed`) to sample real volume / error rate for the
+  affected path. Never `SELECT *` unbounded.
+- Record every source actually consulted (feeds the "Data sources consulted" report field).
+- If cloud access is unavailable or `gcp_project` is missing, note it as a gap and continue
+  with git+code+Jira signal only (do not fabricate cloud findings).
+
+### Step 3: Classify into impact areas (internal analysis)
+
+Bucket every change into the areas below. This classification is **internal** — it drives
+the report's `Found issues`, `Cross-service blast radius`, and the Overview `What changed`
+summary. Do **not** emit a standalone per-area "What changed" section (the report no longer
+uses one). For each touched area capture the concrete files/commits and a one-line "so what";
+note clean areas so their absence can be reflected in the risk assessment.
+
+- **API / contract changes** — swagger/openapi specs, route handlers, request/response
+  shapes. Flag anything **breaking** for consumers.
+- **Database / migrations** — schema changes, migration scripts, index changes,
+  destructive operations.
+- **Auth & security-sensitive** — `auth/`, `security/`, token/session logic, permissions,
+  crypto, dependency CVE-relevant bumps. Any change here raises the risk rating.
+- **Infrastructure** — terraform, Dockerfiles, CI/CD pipelines, service definitions.
+- **Config / environment** — per-region config (**AU / EU / US incl. DR**), feature flags,
+  env keys added/removed. Note if a change lands in some regions but not others.
+- **Dependencies** — `package.json` / lockfiles and other manifests; separate security
+  bumps from feature bumps; note major-version jumps.
+- **Cross-service blast radius** — shared patterns/libraries or contracts that other OOF
+  services depend on (a change here can affect repos outside this diff).
+- **Client backwards-compatibility** — impact on Android / native / web clients consuming
+  the changed contracts.
+- **Observability / operational** — logging, metrics, alerts, rollback affordances.
+- **Deployment & rollback effects (second-order)** — reason beyond *what code changed* to
+  *what the deploy does*: artifact/checksum changes that force a **new revision** even with no
+  logic change; provider/toolchain upgrades (e.g. Terraform / `google` provider pins) that can
+  cause **state or computed-field drift** → require a `terraform plan` review **per environment
+  incl. DR**; CI rules that don't match the release config (e.g. `hotfix/*` allowed in CI but not
+  in `.releaserc`) that can tag a build semantic-release later refuses to release; and whether
+  the change also gates the **rollback path** (e.g. an auth / Workload Identity migration that
+  affects deploy *and* rollback). These are the subtle, high-impact issues a raw diff misses —
+  always assess them on `full` / critical runs.
+
+### Step 4: Risk rating
+
+Assign an overall risk rating with a one-paragraph justification:
+
+- **Low** — isolated, non-breaking, well-tested, easy rollback.
+- **Medium** — touches a shared/contract surface OR config across regions OR notable deps.
+- **High** — breaking API, auth/security, DB migration (esp. destructive), or infra with
+  no clean rollback.
+
+Bias upward when auth/security, migrations, or cross-service contracts are involved, when
+you had to inspect deny-listed files by name only, or when **live signal is adverse** —
+e.g. an active outage / degraded dependency in the target region, or an elevated error rate
+in Cloud Logging for a service this release touches.
+
+**Critical releases (CDT-parity uplift):** tag **each Top risk with its own severity**
+(High / Med / Low), consolidate the concrete pre-production validations into a **Required
+before production** gate, and finish with an explicit **go/no-go recommendation** ("promote
+only after X, Y, Z pass"). Populate the **Engineer detail** appendix in full — exact
+versions/pins, **every** affected environment (incl. DR), and per-item failure mode +
+required validation. This mirrors the manual CDT analysis's audit-grade evidence trail and
+clear release gate.
+
+### Step 4b: Synthesise the findings
+
+From the classification + risk, distil a short **Found issues** list for the top of the
+report — **only realistic, critical items**; omit perfect-world / low-tier concerns (e.g.
+dev-only paths with no production impact, pre-existing standing gaps, or future / in-flight
+fixes). Favour: risky or changed semantics, real deploy/rollout hazards, security-relevant
+changes, and cross-service latent bugs. Each issue = a **bold one-line title** + a 1–3
+sentence description. If there are genuinely none, say so explicitly rather than padding.
+
+### Step 4c: Record what you verified
+
+Keep a running list of what you **actually checked** while analysing (e.g. "confirmed
+app/API/test paths identical via `git diff --name-status`", "confirmed dependency pin",
+"ran `git diff --check` (clean)", "verified WAF rules are `preview=true`"). This feeds the
+**Validation performed** section and, together with **Unknowns**, gives an auditable
+evidence trail — what was, and was not, confirmed.
+
+### Step 5: Produce the report
+
+Output this structure in Markdown, in this order (the layout must match the published
+report). Every section is required **except** the ones marked *[OPTIONAL]*: *Operational
+context* (include only if significant), and *Required before production* + *Engineer detail*
+(**required for critical releases**; otherwise include only when `detail=engineer`, or the
+release is high-risk / infra-heavy).
+
+```
+# Impact Analysis of Release — <repo> `<base>` → `<head>` (<short change summary>)
+
+## Found issues
+
+1. **<issue title>.** <1–3 sentence description of the issue and why it matters.>
+2. **<issue title>.** <...>
+   <If genuinely none: "No notable issues found — see Overview.">
+
+## Overview
+- **What changed:** <concise 1–2 sentence summary of the change and its intent>
+- **Repo / range:** `<repo>` `<base>` (`<sha>`) → `<head>` (`<sha>`) — <N> commits
+- **Changed:** <N> files, +<X> / -<Y> — `<file>` (+n), `<file>` (+m)
+- **Linked tickets (in this release):** <tickets whose changes survive in the net diff | none referenced>
+- **Reverted in-range (not shipped):** <tickets whose commits were reverted within the range — omit this line entirely if none>
+- **Depth:** <light|full> · **Data sources consulted:** <git, code, jira, outage-status, gcp-logs, bigquery> · **Not consulted:** <sources skipped / unavailable>
+- **Overall risk:** **<LOW|MEDIUM|HIGH>** — <one-line reason>
+
+## Cross-service blast radius
+<shared patterns/contracts other OOF services depend on that this change (or the bug it
+fixes) also affects; "None identified" if isolated>
+
+## Operational context   [OPTIONAL — include ONLY if there is something significant to report]
+<Include this section only when live signal is material — e.g. an active outage, a degraded
+dependency, or a notable error/volume pattern in Cloud Logging / BigQuery for a touched
+service. If nothing significant (or live queries were not run), OMIT this section entirely
+and record the "not queried" fact under Unknowns instead.>
+
+## Risk assessment
+**<LOW|MEDIUM|HIGH>.** <justification paragraph; note if live signal changed the rating.>
+
+### Top risks
+<only material, realistic risks — omit perfect-world / low-tier concerns; for critical
+releases tag each with a severity — **High / Med / Low**>
+1. **<High|Med|Low>** — <...>
+2. **<High|Med|Low>** — <...>
+
+## Suggested QA focus
+<solely the QA / functional areas a non-coder QA reviewer should confirm — assume engineers
+have already completed their technical and infrastructure checks. Concise, plain-language, no
+code or jargon. For a purely infra change with no user-facing effect, state what to confirm
+still works after go-live.>
+
+## Validation performed
+<short bullet list of what this analysis ACTUALLY checked / verified — the evidence behind the
+conclusions above. E.g. "confirmed app/API/test paths identical", "confirmed dependency pin",
+"ran git diff --check (clean)", "verified WAF rules are preview=true". Pairs with Unknowns.>
+
+## Unknowns / could not determine from available signal
+<explicit list — never leave this empty by guessing; include any source that was
+unavailable, e.g. "no GCP access — live cloud rates not checked">
+
+## Required before production   [REQUIRED for critical releases; else OPTIONAL — include when detail=engineer or high-risk / infra-heavy]
+<concrete boxes the release owner must tick before go-live — each naming the *validation*, not
+just the risk; cover auth/deploy, `terraform plan` per env incl. DR, artifact/revision
+expectations, CI vs `.releaserc` alignment, and that the **rollback path** still works under any
+changed auth>
+- [ ] <check 1 — e.g. production Workload Identity auth validated for all prod + DR projects>
+- [ ] <check 2 — e.g. `terraform plan` reviewed per env; no unexpected replace / delete / IAM change>
+
+**Recommendation:** **<GO | NO-GO / HOLD>** — <promote only after the named validations pass; one-line rationale.>
+
+## Engineer detail   [REQUIRED for critical releases; else OPTIONAL — include only when detail=engineer]
+<the exhaustive, engineer-grade specifics the summary above intentionally omits — **exact
+versions / pins**, **every** affected environment (incl. DR), per-item failure mode + required
+validation, and the deployment/rollback second-order effects (artifact/revision changes,
+provider state drift, CI-vs-`.releaserc` mismatch, rollback-path auth). Kept at the bottom so
+the summary stays readable for non-technical readers.>
+
+---
+*AI-generated by the `oof-release-impact-analysis` skill (BD-8139) · reviewer: TBD · <date> · decision-support only. Range `<base>..<head>`. Rerun with valid GCP credentials to populate live Operational context.*
+```
+
+### Step 6: Publish (only if `publish=confluence`)
+
+- Publish the report as a **child page** of the **Impact Analysis** folder page in the
+  **OOF Skills** folder: Confluence space **`BNM1`**, parent page id **`5915476067`**
+  (`https://rezolvetech.atlassian.net/wiki/spaces/BNM1/folder/5912657922/OOF+Skills` →
+  *Impact Analysis*). Use markdown format, page emoji 🚦. Page **title**:
+  `Release Impact Analysis — <repo> <base> → <head> (<summary>)`. The page **body** begins
+  with the `# Impact Analysis of Release — …` heading from the template above.
+- Add the Confluence page link back to the release Jira ticket.
+- Never publish if any guardrail check failed.

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.
+```

package/teams/OOF/skills/oof-review/summarize_review_config.py

@@ -0,0 +1,226 @@
+#!/usr/bin/env python3
+"""Summarize PR review and CI configuration for a repository.
+
+Repo-agnostic: takes the repository root as its argument (defaults to the current
+directory) and works on any project. Uses only the Python standard library so it
+can run in sandboxes without installing PyYAML or other dependencies.
+"""
+
+from __future__ import annotations
+
+import argparse
+import re
+from pathlib import Path
+
+
+GUIDANCE_FILES = [
+    ".github/copilot-instructions.md",
+    "CLAUDE.md",
+    "AGENTS.md",
+    "README.md",
+    "docs/conventions.md",
+    "docs/project-rule.md",
+    "docs/source-control.md",
+]
+
+REVIEW_FILES = [
+    ".github/workflows/claude-pr-review.yml",
+    ".github/workflows/claude.yml",
+    ".github/workflows/build-pr.yaml",
+    ".github/PULL_REQUEST_TEMPLATE.md",
+    ".github/CODEOWNERS",
+]
+
+BUILD_FILES = [
+    "build.gradle",
+    "build.gradle.kts",
+    "settings.gradle",
+    "gradle.properties",
+    "pom.xml",
+    "go.mod",
+    "Makefile",
+    "pyproject.toml",
+    "requirements.txt",
+    "package.json",
+]
+
+KEYWORDS = [
+    "Micronaut",
+    "Java 21",
+    "Java 17",
+    "Spring",
+    "Lombok",
+    "Spock",
+    "JUnit",
+    "Mockito",
+    "Testcontainers",
+    "JOOQ",
+    "jOOQ",
+    "Flyway",
+    "PostgreSQL",
+    "Mongo",
+    "Redis",
+    "Google Retail",
+    "Command Center",
+    "Pub/Sub",
+    "BigQuery",
+    "LaunchDarkly",
+    "ANTLR",
+    "Kafka",
+    "JWT",
+    "Docker",
+    "Jib",
+]
+
+
+def read(path: Path) -> str:
+    try:
+        return path.read_text(errors="replace")
+    except FileNotFoundError:
+        return ""
+
+
+def existing(root: Path, paths: list[str]) -> list[Path]:
+    return [root / path for path in paths if (root / path).exists()]
+
+
+def first_match(pattern: str, text: str) -> str | None:
+    match = re.search(pattern, text, re.MULTILINE)
+    return match.group(1).strip() if match else None
+
+
+def command_lines(text: str) -> list[str]:
+    commands: list[str] = []
+    for line in text.splitlines():
+        stripped = line.strip()
+        candidate = stripped
+        if stripped.startswith("run:"):
+            candidate = stripped.removeprefix("run:").strip()
+        if re.match(r"^(\.?/gradlew|gradle|mvn|make|go\s+test|pytest|npm|pnpm|yarn|docker)\b", candidate):
+            commands.append(candidate)
+    return commands
+
+
+def pr_checkboxes(text: str) -> list[str]:
+    checks = []
+    for line in text.splitlines():
+        if re.match(r"\s*-\s+\[[ xX]\]", line):
+            checks.append(line.strip())
+    return checks
+
+
+def collect_keywords(text: str) -> list[str]:
+    found = []
+    lower_text = text.lower()
+    for keyword in KEYWORDS:
+        if keyword.lower() in lower_text:
+            found.append(keyword)
+    normalized = []
+    seen = set()
+    for keyword in found:
+        key = keyword.lower()
+        if key not in seen:
+            seen.add(key)
+            normalized.append(keyword)
+    return sorted(normalized, key=str.lower)
+
+
+def main() -> int:
+    parser = argparse.ArgumentParser(description=__doc__)
+    parser.add_argument("repo", nargs="?", default=".", help="Repository root")
+    args = parser.parse_args()
+
+    root = Path(args.repo).resolve()
+    print(f"# PR Review Configuration Summary\n")
+    print(f"Repository: `{root}`\n")
+
+    review_files = existing(root, REVIEW_FILES)
+    guidance_files = existing(root, GUIDANCE_FILES)
+    build_files = existing(root, BUILD_FILES)
+
+    print("## Files Found\n")
+    for title, files in [
+        ("Review/CI", review_files),
+        ("Guidance", guidance_files),
+        ("Build", build_files),
+    ]:
+        print(f"### {title}")
+        if files:
+            for path in files:
+                print(f"- `{path.relative_to(root)}`")
+        else:
+            print("- none")
+        print()
+
+    claude_text = read(root / ".github/workflows/claude-pr-review.yml")
+    if not claude_text:
+        claude_text = read(root / ".github/workflows/claude.yml")
+    build_text = read(root / ".github/workflows/build-pr.yaml")
+    pr_template = read(root / ".github/PULL_REQUEST_TEMPLATE.md")
+    codeowners = read(root / ".github/CODEOWNERS")
+    guidance_text = "\n\n".join(read(path) for path in guidance_files)
+    build_texts = "\n\n".join(read(path) for path in build_files)
+
+    print("## Claude Review\n")
+    if claude_text:
+        triggers = re.findall(r"types:\s*\[([^\]]+)\]", claude_text)
+        model = first_match(r"--model\s+([^\s]+)", claude_text)
+        print(f"- Workflow present: yes")
+        print(f"- Trigger type lists: {', '.join(triggers) if triggers else 'not parsed'}")
+        print(f"- Model: {model or 'not parsed'}")
+        print("- Standard focus areas present:")
+        for area in ["Code Quality", "Security", "Performance", "Testing", "Documentation"]:
+            print(f"  - {area}: {'yes' if area in claude_text else 'not found'}")
+    else:
+        print("- Workflow present: no")
+    print()
+
+    print("## PR CI Commands\n")
+    commands = command_lines(build_text)
+    if commands:
+        for command in commands:
+            print(f"- `{command}`")
+    else:
+        print("- none parsed")
+    print()
+
+    java_version = first_match(r"java-version:\s*['\"]?([^'\"\n]+)", build_text)
+    if java_version:
+        print(f"Java version from PR workflow: `{java_version}`\n")
+
+    print("## PR Template Checks\n")
+    checks = pr_checkboxes(pr_template)
+    if checks:
+        for check in checks:
+            print(f"- {check}")
+    else:
+        print("- none")
+    print()
+
+    print("## CODEOWNERS\n")
+    owners = [line.strip() for line in codeowners.splitlines() if line.strip() and not line.strip().startswith("#")]
+    if owners:
+        for owner in owners:
+            print(f"- `{owner}`")
+    else:
+        print("- none")
+    print()
+
+    print("## Detected Keywords\n")
+    keywords = collect_keywords("\n\n".join([guidance_text, build_texts, claude_text, build_text]))
+    if keywords:
+        for keyword in keywords:
+            print(f"- {keyword}")
+    else:
+        print("- none")
+    print()
+
+    print("## Suggested Next Steps\n")
+    print("- Review changed files against the discovered keywords and guidance files.")
+    print("- Run targeted tests first, then the PR build command if feasible.")
+    print("- Run `git --no-pager diff --check` before final output.")
+    return 0
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())

package/teams/OOF/skills/oof-review/technology-profiles.md

@@ -0,0 +1,54 @@
+# Technology Profiles
+
+Apply a profile **only** when discovered in the current repo's files.
+Do not carry assumptions from one repo to another.
+
+## Java / Micronaut
+
+- Check the Java version from workflow and Gradle config (do not assume 21 — some repos use 17).
+- Use Micronaut compile-time DI patterns; avoid Spring Boot assumptions unless the repo is Spring-based.
+- Prefer constructor injection and the Lombok annotations already used locally.
+- Follow the repo's `var` rule (many Rezolve Java repos use `var` for new variables created with `new`).
+- Check `@Singleton` vs `@Context` scope, `@Named` qualifiers, `@ExecuteOn` boundaries.
+- Verify blocking operations are not on the event loop thread.
+
+## JOOQ / Flyway / Database
+
+- Migration names and generated classes matter — check naming conventions.
+- Check tenant isolation on queries and mutation side effects (events, audit logs).
+- Verify transaction boundaries and connection management.
+
+## Search Services
+
+- Check strategy and engine selection order.
+- Ensure request builders, filters, refinements, biasing, pagination, and response builders preserve behavior.
+- For Google Retail: check proto conversion, request fields, fallback behavior.
+- For Mongo Atlas Search: check aggregation stages, index assumptions, field paths, unsupported Google-only features.
+- For Redis caches: check key composition, tenant/collection/area isolation, TTLs, skip-cache paths.
+
+## Mongo Data / Indexing
+
+- Check collection and tenant scoping.
+- Check aggregation pipeline correctness, projections, variant/inventory handling.
+- Check index definition generation, conditional indexing, feature flags.
+
+## Authentication / Security
+
+- Check token validation, claims, expiration, signature algorithms, public endpoint boundaries.
+- Check Redis key storage, key rotation, secret handling.
+- Check Pub/Sub credential update idempotency.
+
+## Go / Python / Node
+
+- Prefer repo-provided commands from Makefile, package files, workflow files, or docs.
+- Keep tests close to the changed package/module.
+- Check schema/serialization compatibility and environment variable handling.
+- Do not import Java/Micronaut assumptions into these repos.
+
+## General (all profiles)
+
+- **Code quality:** Single responsibility, clarity, maintainability, unnecessary complexity.
+- **Security:** Auth, authorization, tenant isolation, input validation, secrets.
+- **Performance:** Database/query shape, cache behavior, external calls, async/blocking.
+- **Testing:** Adequate coverage for changed code, edge cases, no superfluous tests.
+- **Documentation:** README/docs/OpenAPI accuracy when behavior changes.