coder-eval-code-review-wf

Context

This is the workflow-orchestrated variant of /coder-eval-code-review-full. It produces the same report (same axes, severity standard, scoring formula, output files, PR comment) but replaces the inline parallel-Agent fan-out (steps 3–5 of the sibling command) with a single Workflow call:

• One sub-workflow per axis (Option B). The parent workflow invokes a parameterized cr-axis child once per selected axis, so each axis is an isolated, independently-resumable sub-run.
• Each axis agent reads its rubric from the sibling file directly. The Review Principles / Severity Standard / Output Format / Techniques are NOT pasted into the workflow payload — the agent Reads them from .claude/commands/coder-eval-code-review-full.md. This keeps a single literal source of truth and keeps the args payload small (just paths, per-axis starting points, and routed tool output).
• Adversarial verification of every medium+ finding. Inside each axis sub-workflow, every 🔴/🟠/🟡 finding is independently re-checked by a second agent whose job is to refute it. False-positives are dropped; a finding that is real but has an inaccurate detail (wrong line count, metric, symbol) is corrected in place (the verifier returns a corrected_title carrying the verified facts). 🔵 (low) findings pass through unverified. A verification ledger (proposed / verified / refuted / corrected counts + the refuted list with reasons, plus the cross-axis-reconcile drops) is surfaced in the report and results.json, so false-positive rate is measurable and comparable run-over-run. To keep that correction rate low at the source, each axis agent is held to an accuracy gate — cite file/line/metrics only from a direct Read (or verbatim tool output), quoting the offending line — and must record a per-axis signal disposition stating, for each routed automated signal, whether it was filed or why not (so a genuinely clean axis reads as deliberately clean rather than as if the tool output was ignored).
• Dedup + theme-group + cross-axis reconcile before scoring. One synthesis agent merges findings that are the same root cause (incl. the same issue surfaced under two axes) and collapses same-class themes (e.g. several god-functions) into one scored finding that lists its members — so a single issue isn't counted multiple times and one theme can't tank an axis. It is also handed the refuted ledger and drops any survivor that is the same claim a sibling axis's verifier already refuted with evidence — because the per-axis verifiers run independently, the same finding can be refuted under one axis yet survive under another, and the survivor would otherwise score against its axis. Cross-axis convergence is taken from this agent's semantic merge judgment (which findings it ruled the same issue), not from exact file:line string-matching (which almost never coincides for a real cross-axis issue). Scoring runs on the merged, reconciled set.
• Deterministic scoring AND rendering in JS. Counts → score, overall mean, weakest axis, and cross-axis convergence are computed in the workflow script; the workflow also renders the report markdown itself and returns a files map (filename → contents), including a machine-readable results.json (structured findings + scores for trend/external use). The main agent writes those verbatim — no hand-transcription, so the report can't drift from the data.

Everything else — scope resolution, the worktree, the automated tool checks, saving raw tool output, and PR-comment posting — stays in the main loop (this command), because those are one-time I/O and shared-state actions that belong under the main agent's direct control.

Opt-in note: invoking Workflow is explicitly part of this command's instructions (step 5 below), which is what authorizes the tool call. Do not ask the user to re-confirm.