/coder-eval-code-review-full

allowed-tools: Bash(*), Read(*), Grep(*), Glob(*), Write(tmp/code-review-*/*), Agent
description: Review the codebase across critical quality axes

Context

You are performing a structured codebase review of the `coder_eval` project.

Optional argument: $ARGUMENTS — space-separated tokens that control review scope and axis selection. See **Scope Selection** below. If empty, review the full codebase across all 8 axes.

Scope Selection

`$ARGUMENTS` accepts a space-separated set of tokens. Default scope is `all`. Default axes are all 8.

**Scope tokens** (pick one):

• `all` — full codebase (walk `src/coder_eval/`). Default.
• `local` — uncommitted changes + untracked files. Resolve via `git status --porcelain` plus `git diff` for tracked changes; read untracked files directly.
• `staged` — only files in `git diff --staged --name-only`.
• `branch` — files changed on the current branch vs `main` (`git diff main...HEAD --name-only`).
• `unpushed` — commits on the current branch not on `origin` (`git log @{u}..HEAD --name-only --pretty=format: | sort -u`).
• `pr:<N>` — files in GitHub PR #N **at the PR's actual HEAD, not the local working tree**. The local checkout may differ from (or be unaware of) the PR's branch. Resolve as follows:

1. `git fetch origin pull/<N>/head:pr-<N>` — creates a local ref `pr-<N>` at the PR's HEAD (works for fork PRs too via the GitHub `pull/<N>/head` refspec). 2. `gh pr view <N> --json baseRefName -q .baseRefName` → store as `<base>`. 3. `git fetch origin <base>:refs/remotes/origin/<base>` — ensure base is current. 4. File list: `git diff origin/<base>...pr-<N> --name-only`. 5. **Sub-agents read file contents via `git show pr-<N>:<path>`, NOT via Read on the working tree.** Include this instruction in every sub-agent prompt for `pr:<N>` scope.

**Axis filter** (optional, combinable with any scope):

• `axis:<comma-list>` — restrict to the listed axis numbers (e.g. `axis:4,6`).

**Action flags** (optional, combinable with any scope):

• `--post-comment` — after writing the report, post `99-pr-comment.md` to the relevant PR via `gh pr review <N> --comment --body-file <path>`. Treat this token as explicit authorization to perform the shared-state action; do not re-confirm with the user. The PR number is resolved as follows:

1. If scope is `pr:<N>`, use that N directly. 2. Otherwise (`branch` / `local` / `staged` / `unpushed` / `all`), interpret the flag as "post to *this* PR" — the PR associated with the current branch. Resolve via `gh pr view --json number,title,author,headRefName,baseRefName,state` (no arg = current branch). If that succeeds and the PR is `OPEN`, use its number. If `gh pr view` fails (no PR for the branch) or the PR is closed/merged, abort before running any tools with a clear error: "--post-comment requires either `pr:<N>` scope or an open PR for the current branch; got `<branch>` with no open PR" — and suggest pushing the branch + opening a PR first, or invoking with `pr:<N>` explicitly.

When this resolves successfully for a non-`pr:<N>` scope, also stash the PR metadata (title/author/headRef/baseRef) for the PR-comment file header — same as the `pr:<N>` path — so the comment is framed as a PR review regardless of which scope drove it.

**Examples**:

• `pr:253` — review PR #253 across all 8 axes (writes the PR comment as a file; does not post).
• `pr:253 --post-comment` — review PR #253 and post the comment to GitHub.
• `branch --post-comment` — review the current branch's diff vs `main` and post to *this* branch's PR.
• `local --post-comment` — review uncommitted + untracked changes and post to this branch's PR.
• `branch axis:4` — security-only review of current branch's changes vs `main`.
• `local` — review everything uncommitted and untracked.
• (empty) — full review of the whole codebase, all axes.

**Two rules for non-`all` scopes**:

1. **Read freely beyond the diff; file findings only inside it.** Reviewing a change in `orchestrator.py` requires reading its callers, the types it touches, and the tests for it. Sub-agents treat the scoped file list as the *target for findings* — they may read any file in the repo for context, but a finding MUST be against a file in scope. This catches bugs that only become visible when you read the surrounding code.

2. **Some axes don't scope cleanly — adjust the question they answer.** Architecture (Axis 5) and Harness Quality (Axis 8) are whole-system properties. For non-`all` scopes, those axes answer "does this change make the architecture / harness *worse*?" — not "is the architecture good in absolute terms." File a finding only if an in-scope change introduces or worsens an axis-5/8 issue.

Review Principles

All analysis must evaluate against the core principles defined in `.claude/shared/review-rubric.md` → **"Review Principles"** (bug-free code, KISS, DRY without over-applying it, not over-engineered, simplicity, no unnecessary comments, CLAUDE.md adherence). Read that section; do not work from memory. The per-axis **Severity Standard** below is specific to this command and is defined locally — it is NOT governed by the shared rubric.

Severity Standard

Every finding MUST be tagged 🔴 Critical / 🟠 High / 🟡 Medium / 🔵 Low. Calibrate by **impact if shipped**, not by fix difficulty. When torn between two levels, pick the lower one. The anchors below define each axis's bar — match a finding to the closest example before assigning.

Per-axis severity anchors

| Axis | 🔴 Critical | 🟠 High | 🟡 Medium | 🔵 Low | |------|------------|--------|----------|-------| | **1. Code Quality** | Dead code on a live path that misleads readers into wrong assumptions (e.g. an unused branch in the orchestrator that looks load-bearing) | Cyclomatic complexity > 20 in a hot module (`orchestrator`, `checker`, `sandbox`); duplicated logic across 4+ sites; machinery disproportionate to the goal — a new enum/flag/alias layer for behavior derivable