claude-dev-env 8.11.1 → 8.13.0

package/.agents/skills/e-code-review/SKILL.md

@@ -1,90 +1,43 @@
 ---
 name: e-code-review
 description: >-
-  Max-recall code review at a selectable effort level (low, medium, xhigh), with
-  optional auto-fix and an auto-execute loop for any level. Triggers:
-  /e-code-review, /e-code-review low, /e-code-review medium, /e-code-review
-  xhigh, /e-code-review <level> --fix, /e-code-review <level> loop,
-  /e-code-review preflight-proposal.
+  Code review at one of five effort levels that match the built-in
+  /code-review recipes step for step: low, medium, high, xhigh, max.
+  Triggers: /e-code-review, /e-code-review low, /e-code-review medium,
+  /e-code-review high, /e-code-review xhigh, /e-code-review max, and any
+  level with --fix.
 ---
 
 # e-code-review
 
-**Pick a level, run that review, optionally fix and loop.** Each level has its own procedure file. Fix application lives in `reference/fix.md`; repeat-until-clean lives in `reference/loop.md`.
+**Pick a level, load its file, run it.** Each file has the same steps, angles, caps, and fields as the built-in `/code-review` recipe for that level. Only the wording differs, where this repo's prose rules require it.
 
-## Mode routing
-
-Resolve the first matching invocation before the normal refusal and loop rules:
-
-1. `preflight-proposal` requires `<pr_number>`, `--level <low|medium|xhigh>`, `--base-sha <immutable SHA>`, `--head-sha <immutable SHA>`, and `--worktree <isolated path>`. Default level is `low`. Follow [reference/preflight-proposal.md](reference/preflight-proposal.md). The mode runs `<review_level> --fix loop` locally and returns selected-candidate-ready proposal evidence.
-2. Normal mode follows the current level, `--fix`, and `loop` behavior.
-
-Proposal mode selects the review level and records finding outcomes. The downstream owner records selected proposal IDs before reapplication. Each new finding gets a new ID.
-
-## Gotchas
-
-- **`low` stays single-pass.** No subagents, no full-file reads: one read pass per target item, one findings pass.
-- **Collection reports every finding.** Keep every CONFIRMED or PLAUSIBLE finding at its assigned severity (`blocker`, `high`, `medium`, `low`, `nit`). Do not drop low or nit findings during collection. Severity or action filtering is a separate consumer stage after the collection record is complete (`scripts/finding_pipeline.py`).
-- **`medium` favors precision, `xhigh` favors recall.** At `medium` (8 angles) assign severity carefully so a later filter can pick maintainer-action findings. At `xhigh` (10 angles plus a gap sweep) a single non-REFUTED vote carries the finding; do not drop on uncertainty.
-- **Every retained finding carries `severity` and `verdict`.** Severity is one of `blocker`, `high`, `medium`, `low`, `nit`. Verdict is `CONFIRMED` or `PLAUSIBLE`. Drop REFUTED candidates only; never emit an unclassified retained finding.
-- **`--fix` applies findings once.** Load `reference/fix.md` and follow it. That file owns the fix agent, the code-rules gate, skip logging, and outcome reporting. Commits are lead-owned; fix agents never commit or push.
-- **`loop` never asks.** A round with bug findings validates them with an advisor, fixes, and re-reviews. Terminals are exactly `clean`, `nits_fixed`, and `advisor_blocked`. There is no reviewed-head count limit; a new head increments the count once, a re-review of the same head does not. Load `reference/loop.md` and follow it.
-- **`--fix` and `loop` combine.** With both, each loop round runs the level file, and the round's fixing happens inside `reference/loop.md`'s gate sequence, which loads `reference/fix.md` for the mechanics. There is no separate fix pass around the round.
-
-## When this skill applies
+| Level | File | Shape |
+|---|---|---|
+| `low` | [reference/low.md](reference/low.md) | 1 diff pass, no verify, at most 4 findings |
+| `medium` | [reference/medium.md](reference/medium.md) | 1 careful diff pass, at most 15 findings |
+| `high` | [reference/high.md](reference/high.md) | 8 inline angles, dedup with no verify, at most 10 findings |
+| `xhigh` | [reference/xhigh.md](reference/xhigh.md) | 10 inline angles, dedup, gap sweep, at most 15 findings |
+| `max` | [reference/max.md](reference/max.md) | 10 subagent angles, 1-vote verify, gap sweep, at most 15 findings |
 
-Triggers: `/e-code-review <level> [--fix] [loop]`. `<level>` is `low`, `medium`, or `xhigh`. `--fix` and `loop` are each optional and may be used together.
+## Level
 
-**Refusal. First match wins:**
+With no level, or an unknown one, run `high`.
 
-- **No level, or an unknown level.** Respond exactly: `Which effort level — low, medium, or xhigh?`
+## Target
 
-## Evaluation-backed defaults (e-code-review family)
+A PR number, branch name, or file path after the level is the review target. With no target, the review reads the current diff.
 
-When the caller asks which level to pick for a known fixture band (easy / medium / demanding scope), use the committed OP-02B evaluation evidence. Thinking stays on; **effort** is the only cost/latency lever.
+## Report
 
-| Fixture band | Skill effort | Source |
-|---|---|---|
-| easy | `medium` | `scripts/effort_defaults_evidence.json` → `skill_defaults.default_by_band.easy` |
-| medium | `xhigh` | same file → `medium` (maps evaluation `high`) |
-| demanding | `xhigh` | same file → `demanding` (maps evaluation `max`) |
+Each level file reports through the ReportFindings tool. When the host has no ReportFindings tool, print the findings in its place, most severe first, one per line as `file:line — summary`. `--fix` reports its outcomes the same way, with the outcome at the end of each line.
 
-Resolve programmatically with `scripts/effort_evaluation.py` → `resolve_skill_effort_for_band`. Every default cites a completed evaluation row. The user-facing command still requires an explicit level flag; these defaults answer "what should I pick?" for this workflow family only.
+## --fix
 
-Detail: `reference/effort-evaluation.md`.
+`--fix` works with every level. It lives in one file, [reference/fix.md](reference/fix.md). No level file carries its own fix steps.
 
 ## The process
 
-1. Read `<level>` and the optional `--fix` and `loop` flags. Apply the refusal first.
-2. Load `reference/low.md`, `reference/medium.md`, or `reference/xhigh.md`. Run that file as one review cycle, ending in its structured findings report.
-3. If `--fix` is set and `loop` is not set, load `reference/fix.md` and apply it to that cycle's findings. This path has no commit step: the fixes stay uncommitted in the working tree for the user to review and commit.
-4. If `loop` is set, load `reference/loop.md` and follow it with that cycle's findings still unfixed. Round 1's findings are the ones step 2 already produced; from the second round on, the round re-runs that same level file end to end. End to end means the level file's review phases, up to and including its findings report. Skip that file's *Looping* section, which hands control to `loop.md` and would re-enter the loop the round is already inside. `loop.md`'s gate sequence owns when the round fixes.
-5. Without `--fix` or `loop`, return the cycle findings and stop.
-
-## File index
-
-| File | Purpose |
-|---|---|
-| `SKILL.md` | Route by level; dispatch `--fix` and `loop` |
-| `reference/low.md` | low review procedure: 1 diff pass per target item, no verify |
-| `reference/medium.md` | medium review procedure: 8 angles, 1-vote verify |
-| `reference/xhigh.md` | xhigh review procedure: 10 angles, 1-vote verify, gap sweep |
-| `reference/fix.md` | Fix application, code-rules gate, skip logging, outcome reporting |
-| `reference/loop.md` | Repeat review/fix rounds until clean |
-| `reference/preflight-proposal.md` | Isolated local review, immutable SHAs, proposal evidence, and mutation boundary |
-| `reference/effort-evaluation.md` | Effort evaluation fixtures, evidence, and skill defaults |
-| `reference/runner-selection.md` | Runner selection map |
-| `scripts/finding_pipeline.py` | Collect every finding; filter severity only later |
-| `scripts/test_finding_pipeline.py` | Collection and filter-stage behavioral tests |
-| `scripts/e_code_review_scripts_constants/finding_pipeline_constants.py` | Named constants for the collect-then-filter pipeline |
-| `scripts/effort_evaluation.py` | Effort rows, recommendation, skill default resolver |
-| `scripts/effort_defaults_evidence.json` | Committed evaluation rows + e-code-review skill defaults |
-| `scripts/grok_code_review.py` | Grok medium-review discovery and verification |
-| `scripts/test_grok_code_review.py` | Behavioral tests for the Grok medium-review module |
-| `scripts/e_code_review_scripts_constants/` | Skill-local constants (unique package name; avoids bare `config` import shadow) |
-
-## Folder map
-
-- `SKILL.md`: route and dispatch.
-- `reference/`: level procedures, fix/loop, effort evaluation, runner selection.
-- `scripts/`: collect-then-filter finding pipeline, effort evaluation, Grok medium-review module, tests, and `e_code_review_scripts_constants/`.
+1. Read the level and the optional `--fix` flag. Load the level file.
+2. Run it end to end, ending in its ReportFindings call.
+3. With `--fix`, load `reference/fix.md` and run it on those findings.

package/.agents/skills/e-code-review/reference/fix.md

@@ -1,80 +1,9 @@
-# Fix Behavior (--fix)
+# --fix
 
-When `--fix` is passed, apply the reviewed findings to the working tree.
+Runs after any level's review, once its findings are reported.
 
-## Preflight-proposal mode
-
-When the hub selects `preflight-proposal`, consume the established proposal context, selected review level, and current pull-request head.
-
-## Resume the finding agent
-
-For each finding, resume the same Agent-tool agent instance that originally
-surfaced it. That agent applies all relevant fixes, which you provide guidance
-on in your resume prompt.
-
-At `low`, and any time the Agent tool is unavailable, no finder agent exists
-to resume. Apply the fixes yourself, sequentially, in this context, holding to
-every rule below.
-
-## Code-rules gate
-
-Before returning, the resumed agent runs the code-rules gate with the same bare
-call every other surface in this skill uses:
-
-1. Run `python ~/.claude/_shared/pr-loop/scripts/code_rules_gate.py --repo-root
-   <repo root>` with no file paths and no `--only-under` prefix. The `python`
-   prefix is required. On Windows a bare `.py` path opens the file in Cursor,
-   which then crashes on the gate flags.
-2. If the gate reports violations **on lines this fix already owns** (the files
-   and added lines the fix changed), fix them and re-run the exact same command.
-3. A violation on a path or added line outside this fix's own work is reported
-   or skipped. It is not force-fixed into unrelated files. Log each skip with
-   the path and reason, then continue.
-4. Repeat until every violation on this fix's own work is clean (or skipped with
-   a logged reason for out-of-scope hits).
-5. Only after that result does the agent return control and report its outcome.
-
-A file path named on the command line puts the gate in whole-file scope and can
-churn on untouched lines; keep the call bare.
-
-This gate commits nothing. The fix lands in the working tree and stays
-uncommitted. **Commit ownership is lead-only:** a fix agent, patch worker, or
-resumed finding agent never runs `git commit` or `git push`. The lead that owns
-the branch creates the commit after gates pass. The bare code-rules call covers
-the merge-base surface and staged added lines only. Working-tree-only lines
-enter that scope after the lead stages or commits them.
-
-Under a bare `--fix` (this document invoked without `loop`), nothing
-downstream commits either. A one-shot fix pass leaves its fixes uncommitted in
-the working tree for the lead to review and commit (stage first if you re-run
-the gate on those lines). Under `loop`, the round tail in `reference\loop.md`
-stages and runs required checks; the lead still owns the commit and push.
-
-## Skip candidates
-
-Skip a finding when fixing it would change intended behavior, require changes
-well outside the reviewed diff, or the finding itself is judged a false
-positive.
-
-Every logged skip surfaces exactly once, batched together, in a single
-list presented to the user at the end of the fix pass, after every other
-finding has been fixed, marked not-needed, or skipped, and never before.
-
-## Reporting outcomes
-
-After fixes land, report the same findings list again through the structured
-findings-report call, the call that renders this review's results as a typed
-list in the host UI, with each finding now carrying an `outcome`:
-`fixed`, `no_change_needed` (the finding was wrong or already handled), or
-`skipped` (the finding stands but no fix was applied). Do not repeat the findings as text in the
-response body; the structured call is the record the host UI reads, and the
-batched skip list from above goes in the prose that follows it.
-
-## If findings are fixed later
-
-Whenever a reported finding is fixed later in the session, because the user
-asks for the fix or later work fixes it incidentally, call the structured
-findings-report call again with the same findings, each carrying an
-`outcome` (`fixed`, `no_change_needed`, or `skipped`). Do not repeat the
-findings as text. Make that call immediately after the fixes land, before any
-prose summary.
+1. Take the findings the review just reported, most severe first.
+2. Apply each one to the working tree. Keep each edit to the finding's own lines.
+3. Make no commit and no push. The edits stay uncommitted for the user.
+4. When a finding cannot be fixed, or the fix would change behavior the finding did not name, leave the code and mark it `skipped`.
+5. Report the same findings again, each with an `outcome`: `fixed`, `no_change_needed` (the finding was wrong or already handled), or `skipped`.

package/.agents/skills/e-code-review/reference/high.md

@@ -0,0 +1,129 @@
+`high effort → 8 inline angles → dedup (no verify) → ≤10 findings`
+
+You are reviewing for **recall** at high effort: catch every bug a careful
+reviewer would catch in one sitting. At this level, surface a finding even when
+it may be a false positive. Err on the side of surfacing.
+
+## Phase 0 — Gather the diff
+
+Run `git diff @{upstream}...HEAD` (or `git diff main...HEAD` / `git diff HEAD~1`
+if there's no upstream) to get the unified diff under review. If there are
+uncommitted changes, or the range diff is empty, also run `git diff HEAD` and
+include the working-tree changes in scope — the review often runs before the
+commit. If a PR number, branch name, or file path was passed as an argument,
+review that target instead. Treat this diff as the review scope.
+
+## Phase 1 — Find candidates (3 correctness angles + 3 cleanup angles + 1 altitude angle + 1 conventions angle, up to 6 each)
+
+Run **8 independent finder angles** in sequence yourself, in THIS context — do NOT spawn subagents for them. Each
+surfaces **up to 6 candidate findings** with `file`, `line`, a one-line
+`summary`, and a concrete `failure_scenario`.
+
+### Angle A — line-by-line diff scan
+
+Read every hunk in the diff, line by line. Then Read the enclosing function for
+each hunk — bugs in unchanged lines of a touched function are in scope (the PR
+re-exposes or fails to fix them). For every line ask: what input, state, timing,
+or platform makes this line wrong? Look for inverted/wrong conditions,
+off-by-one, null/undefined deref, missing `await`, falsy-zero checks,
+wrong-variable copy-paste, error swallowed in catch, unescaped regex metachars.
+
+### Angle B — removed-behavior auditor
+
+For every line the diff DELETES or rewrites, name the invariant or behavior it
+enforced, then search the new code for where that invariant is re-established.
+If you can't find it, that's a candidate: a removed guard, a dropped error
+path, a narrowed validation, a deleted test that was covering a live case.
+
+### Angle C — cross-file tracer
+
+For each function the diff changes, find its callers (Grep for the symbol) and
+check whether the change breaks any call site: a new precondition, a changed
+return shape, a new exception, a timing/ordering dependency. Also check callees:
+does a parallel change in the same PR make a call unsafe?
+
+### Reuse
+
+The angles above hunt for bugs; this one and the next two hunt for cleanup in
+the changed code. Flag new code that re-implements something the codebase
+already has — Grep shared/utility modules and files adjacent to the change,
+and name the existing helper to call instead.
+
+### Simplification
+
+Flag unnecessary complexity the diff adds: redundant or derivable state,
+copy-paste with slight variation, deep nesting, dead code left behind. Name
+the simpler form that does the same job.
+
+### Efficiency
+
+Flag wasted work the diff introduces: redundant computation or repeated I/O,
+independent operations run sequentially, blocking work added to startup or
+hot paths. Also flag long-lived objects built from closures or captured
+environments — they keep the entire enclosing scope alive for the object's
+lifetime (a memory leak when that scope holds large values); prefer a
+class/struct that copies only the fields it needs. Name the cheaper
+alternative.
+
+### Altitude
+
+Check that each change fixes the root cause at the right depth. A fix that
+patches a symptom with a fragile bandaid is a finding. Special cases layered on shared
+infrastructure are a sign the fix isn't deep enough — prefer the simpler, more
+general change to the underlying mechanism over adding special cases, and name
+that change.
+
+### Conventions (CLAUDE.md)
+
+Find the CLAUDE.md files that govern the changed code: the user-level
+~/.claude/CLAUDE.md, the repo-root CLAUDE.md, plus any CLAUDE.md or
+CLAUDE.local.md in a directory that is an ancestor of a changed file (a
+directory's CLAUDE.md only applies to files at or below it). Read each one
+that exists, then check the diff for clear violations of the rules they state.
+
+Only flag a violation when you can quote the exact rule and the exact line
+that breaks it — no style preferences, no vague "spirit of the doc"
+inferences. In the finding, name the CLAUDE.md path and quote the rule so the
+report can cite it. If no CLAUDE.md applies, return nothing for this angle.
+
+Cleanup, altitude, and conventions candidates use the same
+`file`/`line`/`summary` shape; in `failure_scenario`, state the concrete
+cost (what is duplicated, wasted, harder to maintain, or which CLAUDE.md rule
+is broken) in the place a crash would go. Correctness bugs always outrank cleanup,
+altitude, and conventions findings when the output cap forces a cut.
+
+Pass every candidate with a nameable failure scenario through — finders that
+silently drop half-believed candidates are the dominant cause of misses.
+
+## Phase 2 — Dedup only (no verify)
+
+Pool all candidates. Dedup near-duplicates only (same defect, same location, same reason → keep one). Do NOT run verifiers; do NOT re-judge. Sort by severity.
+
+## Output
+
+Target **at least 5 findings**. If fewer findings exist, emit what you have — do not invent to hit the floor.
+
+Call the ReportFindings tool once to report this review's results
+with `{level, findings}`. `findings` is at most 10 entries ranked
+most-severe first; each entry has `file`, `line`, `summary`,
+`short_summary` — the claim compressed to ≤60 characters, no rationale
+or consequence clause — `failure_scenario`, and `category` — a short kebab-case slug for the angle
+that produced it (`correctness`, `simplification`, `efficiency`,
+`reuse`, `altitude`, `conventions`, or a more specific slug like
+`test-coverage` when one fits better) — plus `verdict` when a verify pass
+produced one. If more than 10 survive, keep the 10 most severe. If
+nothing survives, call it with an empty array. Do not also print
+the findings as text, and do not create or publish an artifact of the review -
+the tool call is the report.
+
+
+## If findings are fixed later
+
+Whenever reported findings get fixed later in this session - the user asks you
+to fix them, or later work fixes them incidentally - you MUST call ReportFindings again with the same findings, each
+carrying an `outcome`: `fixed`, `no_change_needed` (the finding was wrong or
+already handled), or `skipped` (valid but not applied). Do not repeat the
+findings as text.
+Make that call immediately after the fixes land, before any prose summary; the
+host UI's per-finding status updates only from it, and without it the findings
+stay marked unresolved.

package/.agents/skills/e-code-review/reference/low.md

@@ -1,20 +1,13 @@
-`low effort → 1 diff pass per target item → no verify → ≥min(files,4) findings`
+`low effort → 1 diff pass → no verify → ≤4 findings`
 
 ## Turn 1 — read
 
-Read the unified diff (`git diff @{upstream}...HEAD; git diff HEAD`
+One tool call: read the unified diff (`git diff @{upstream}...HEAD; git diff HEAD`
 to cover both committed and uncommitted changes, or `git diff main...HEAD` /
-the target passed as an argument). A target names one or more items, each a PR
-number, a branch name, a file path, or `default-range` — the default `git diff`
-read named above, which is what this step reads when no target is passed — and
-it may mix those forms. A loop round widens a target by adding a path to whatever it
-started as, and it names `default-range` as an item whenever the round it
-widened was given no target argument, so the original scope stays under review.
-When a target names more than one item, read each item's diff and review their
-union — a shared hunk counted once, an empty one adding nothing. Skip
-test/fixture hunks (`test/`, `spec/`, `__tests__/`, `*_test.*`, `*.test.*`,
+the target passed as an argument). Skip test/fixture
+hunks (`test/`, `spec/`, `__tests__/`, `*_test.*`, `*.test.*`,
 `fixtures/`, `testdata/`) — test-file changes are not reviewed at this level.
-One read pass per target item, and no more: no subagents, no full-file reads.
+No subagents, no full-file reads.
 
 ## Turn 2 — findings
 
@@ -28,48 +21,24 @@ helper visible in the diff context, and dead code the diff leaves behind.
 Do **not** flag style, naming, perf, missing tests, or anything outside the
 hunk.
 
-Target **min(files_changed, 4) findings**, most-severe first, reported in one
-call to the structured findings-report call — the mechanism that renders
-findings as a typed list in the host UI — with `{level, findings}`; each
-entry has `file`, `line`, `summary`, `short_summary` (≤60 characters), and
-`failure_scenario`. If you have fewer, do one more pass focused on the largest
-changed file and on any **removed** code blocks. Make that call with an empty
-findings array only if the diff is trivially correct after that pass. Do not
-also print the findings as text.
+Report at most **4 findings**, most-severe first, in one
+ReportFindings call with `{level, findings}` — each entry has
+`file`, `line`, `summary`, `short_summary` (≤60 characters), and
+`failure_scenario`. If nothing qualifies, call it with an empty findings
+array. Do not also print the findings as text.
 
-## Applying fixes (--fix)
-
-The `--fix` flag was passed. Follow `reference\fix.md` (relative
-to this skill's folder) for the exact fix, code-rules-gate, and skip-handling
-behavior — it governs which agent applies each fix, how the code-rules gate
-runs, how a skip is logged, and how outcomes get reported. Do not repeat the
-findings as text; follow that document's reporting rules once fixes land.
-
-When `loop` is also set, skip this section.
 
 ## If findings are fixed later
 
-Whenever a reported finding is fixed later in this session — the user asks you
-to fix it, or later work fixes it incidentally — follow `reference\fix.md`'s
-reporting rules again: report the same findings through the structured
-findings-report call, each carrying an `outcome`. Do not repeat the findings
-as text. Make that call immediately after the fixes land, before any prose
-summary; the host UI's per-finding status updates only from that call.
-
-## Looping (`loop`)
-
-The `loop` arg was passed. Follow `reference\loop.md` (relative to this
-skill's folder) for how to re-run Turn 1 (read) and Turn 2 (findings)
-repeatedly — including its exit condition and re-invocation rules. Schedule no
-fix pass of your own here: when `--fix` is also present, `reference\loop.md`'s
-gate sequence owns the round's fixing and loads `reference\fix.md` for the
-mechanics. Do not treat a single pass through this document as complete while
-`loop` is active; hand control to that document, and do not stop at Turn 2.
+Whenever reported findings get fixed later in this session - the user asks you
+to fix them, or later work fixes them incidentally - you MUST call ReportFindings again with the same findings, each
+carrying an `outcome`: `fixed`, `no_change_needed` (the finding was wrong or
+already handled), or `skipped` (valid but not applied). Do not repeat the
+findings as text.
+Make that call immediately after the fixes land, before any prose summary; the
+host UI's per-finding status updates only from it, and without it the findings
+stay marked unresolved.
 
-That hand-off applies when this document is entered directly. When a loop round
-is already running and has handed this document its target, the round owns the
-loop: end at Turn 2 with the findings report and return those findings to
-`reference\loop.md`'s gate sequence, rather than handing control to that
-document again from here.
 
-When `loop` was not passed, skip this section.
+After you finish the review, end your response with this exact line on its own:
+Tip: For a deeper cloud-based review, try /ultrareview next time.

package/.agents/skills/e-code-review/reference/max.md

@@ -0,0 +1,169 @@
+`max effort → 5+5 angles × 8 candidates → 1-vote verify → sweep → ≤15 findings`
+
+You are reviewing for **recall** at maximum effort: catch every bug. At
+this level, surface a finding even when it may be a false positive. A
+missed bug ships. Err on the side of surfacing.
+
+## Phase 0 — Gather the diff
+
+Run `git diff @{upstream}...HEAD` (or `git diff main...HEAD` / `git diff HEAD~1`
+if there's no upstream) to get the unified diff under review. If there are
+uncommitted changes, or the range diff is empty, also run `git diff HEAD` and
+include the working-tree changes in scope — the review often runs before the
+commit. If a PR number, branch name, or file path was passed as an argument,
+review that target instead. Treat this diff as the review scope.
+
+## Phase 1 — Find candidates (5 correctness angles + 3 cleanup angles + 1 altitude angle + 1 conventions angle, up to 8 each)
+
+Run **10 independent finder angles** via the Agent tool. Each
+surfaces **up to 8 candidate findings**. Do NOT let one angle's conclusions
+suppress another's — if two angles flag the same line for different reasons,
+record both. If the Agent tool is not available in your current tool set, do not error — perform each angle (and each verification) yourself, sequentially, in this context.
+
+### Angle A — line-by-line diff scan
+
+Read every hunk in the diff, line by line. Then Read the enclosing function for
+each hunk — bugs in unchanged lines of a touched function are in scope (the PR
+re-exposes or fails to fix them). For every line ask: what input, state, timing,
+or platform makes this line wrong? Look for inverted/wrong conditions,
+off-by-one, null/undefined deref, missing `await`, falsy-zero checks,
+wrong-variable copy-paste, error swallowed in catch, unescaped regex metachars.
+
+### Angle B — removed-behavior auditor
+
+For every line the diff DELETES or rewrites, name the invariant or behavior it
+enforced, then search the new code for where that invariant is re-established.
+If you can't find it, that's a candidate: a removed guard, a dropped error
+path, a narrowed validation, a deleted test that was covering a live case.
+
+### Angle C — cross-file tracer
+
+For each function the diff changes, find its callers (Grep for the symbol) and
+check whether the change breaks any call site: a new precondition, a changed
+return shape, a new exception, a timing/ordering dependency. Also check callees:
+does a parallel change in the same PR make a call unsafe?
+
+### Angle D — language-pitfall specialist
+
+Scan for the classic pitfalls of the diff's language/framework — for example:
+JS falsy-zero, `==` coercion, closure-captured loop var; Python mutable default
+args, late-binding closures; Go nil-map write, range-var capture; SQL injection;
+timezone/DST drift; float equality. Flag any instance the diff introduces.
+
+### Angle E — wrapper/proxy correctness
+
+When the PR adds or modifies a type that wraps another (cache, proxy, decorator,
+adapter): check that every method routes to the wrapped instance and not back
+through a registry/session/global — e.g. a caching provider holding a
+`delegate` field that resolves IDs via `session.get(...)` where it should call
+`delegate.get(...)` will re-enter the cache or recurse. Also check that the
+wrapper forwards all the methods the callers use.
+
+### Reuse
+
+The angles above hunt for bugs; this one and the next two hunt for cleanup in
+the changed code. Flag new code that re-implements something the codebase
+already has — Grep shared/utility modules and files adjacent to the change,
+and name the existing helper to call instead.
+
+### Simplification
+
+Flag unnecessary complexity the diff adds: redundant or derivable state,
+copy-paste with slight variation, deep nesting, dead code left behind. Name
+the simpler form that does the same job.
+
+### Efficiency
+
+Flag wasted work the diff introduces: redundant computation or repeated I/O,
+independent operations run sequentially, blocking work added to startup or
+hot paths. Also flag long-lived objects built from closures or captured
+environments — they keep the entire enclosing scope alive for the object's
+lifetime (a memory leak when that scope holds large values); prefer a
+class/struct that copies only the fields it needs. Name the cheaper
+alternative.
+
+### Altitude
+
+Check that each change fixes the root cause at the right depth. A fix that
+patches a symptom with a fragile bandaid is a finding. Special cases layered on shared
+infrastructure are a sign the fix isn't deep enough — prefer the simpler, more
+general change to the underlying mechanism over adding special cases, and name
+that change.
+
+### Conventions (CLAUDE.md)
+
+Find the CLAUDE.md files that govern the changed code: the user-level
+~/.claude/CLAUDE.md, the repo-root CLAUDE.md, plus any CLAUDE.md or
+CLAUDE.local.md in a directory that is an ancestor of a changed file (a
+directory's CLAUDE.md only applies to files at or below it). Read each one
+that exists, then check the diff for clear violations of the rules they state.
+
+Only flag a violation when you can quote the exact rule and the exact line
+that breaks it — no style preferences, no vague "spirit of the doc"
+inferences. In the finding, name the CLAUDE.md path and quote the rule so the
+report can cite it. If no CLAUDE.md applies, return nothing for this angle.
+
+Cleanup, altitude, and conventions candidates use the same
+`file`/`line`/`summary` shape; in `failure_scenario`, state the concrete
+cost (what is duplicated, wasted, harder to maintain, or which CLAUDE.md rule
+is broken) in the place a crash would go. Correctness bugs always outrank cleanup,
+altitude, and conventions findings when the output cap forces a cut.
+
+## Phase 2 — Verify (1-vote, 3-state)
+
+Dedup candidates that point at the same line/mechanism, keeping the one with
+the most concrete failure scenario. For each remaining candidate, run **one
+verifier** via the Agent tool: give it the diff, the relevant
+file(s), and the candidate, and have it return exactly one of:
+
+- **CONFIRMED** — can name the inputs/state that trigger it and the wrong
+  output or crash. Quote the line.
+- **PLAUSIBLE** — mechanism is present, trigger is uncertain (timing, env,
+  config). State what would confirm it.
+- **REFUTED** — factually wrong (code doesn't say that) or guarded elsewhere.
+  Quote the line that proves it.
+
+Keep candidates where the vote is CONFIRMED or PLAUSIBLE.
+
+This is recall mode — a single non-REFUTED vote carries the finding. Do NOT
+drop on uncertainty.
+
+## Phase 3 — Sweep for gaps
+
+Run **one more finder** as a fresh reviewer who has the verified list. Re-read
+the diff and enclosing functions looking ONLY for defects not already listed.
+Do not re-derive or re-confirm anything already there — the job is gaps. Focus
+on what the first pass tends to miss: moved/extracted code that dropped a guard
+or anchor; second-tier footguns (dataclass default evaluated once, `hash()`
+non-determinism, lock-scope shrink, predicate methods with side effects);
+setup/teardown asymmetry in tests; config defaults flipped.
+
+Surface **up to 8 additional candidates**, each naming a defect not already on
+the list. If nothing new, return an empty sweep — do not pad.
+
+## Output
+
+Call the ReportFindings tool once to report this review's results
+with `{level, findings}`. `findings` is at most 15 entries ranked
+most-severe first; each entry has `file`, `line`, `summary`,
+`short_summary` — the claim compressed to ≤60 characters, no rationale
+or consequence clause — `failure_scenario`, and `category` — a short kebab-case slug for the angle
+that produced it (`correctness`, `simplification`, `efficiency`,
+`reuse`, `altitude`, `conventions`, or a more specific slug like
+`test-coverage` when one fits better) — plus `verdict` when a verify pass
+produced one. If more than 15 survive, keep the 15 most severe. If
+nothing survives verification, call it with an empty array. Do not also print
+the findings as text, and do not create or publish an artifact of the review -
+the tool call is the report.
+
+
+## If findings are fixed later
+
+Whenever reported findings get fixed later in this session - the user asks you
+to fix them, or later work fixes them incidentally - you MUST call ReportFindings again with the same findings, each
+carrying an `outcome`: `fixed`, `no_change_needed` (the finding was wrong or
+already handled), or `skipped` (valid but not applied). Do not repeat the
+findings as text.
+Make that call immediately after the fixes land, before any prose summary; the
+host UI's per-finding status updates only from it, and without it the findings
+stay marked unresolved.