BeWith Test Review (unit-test quality, on-demand, inline)

Review the quality of the tests touched by the user-specified scope — a local diff or a GitHub PR — directly in this conversation. This is a narrow, single-purpose review: it judges test quality only, not production code, bugs, git history, or plan compliance. It evaluates only the tests that already exist — its job is to reduce and sharpen them, never to recommend adding tests or report missing coverage.

The rubric itself (the 15 principles, the verdict discipline, severity tiers) lives in the test-quality-rubric skill, not here — this skill is the process around applying it to a specific diff or PR.

When to apply

• User says "review my tests," "check these unit tests," "are these good tests," "review the test quality on this PR," or similar — before opening a PR or on an existing one.
• Never run this proactively. Only when explicitly asked.

Process

1. Resolve the scope and get the test diff

• Local diff (default): prefer the branch's actual merge-base against the repo's default remote branch (git merge-base HEAD origin/HEAD, falling back to origin/main); compute git diff <base>...HEAD. If the user names specific files/folders, scope to those.
• GitHub PR: use gh pr view <ref> --json title,url,headRefName,number and gh pr diff <ref>. If gh is missing or not authenticated, tell the user plainly and offer to fall back to a local-diff review if a matching branch is checked out.
• If the scope can't be resolved automatically — git not installed, not a git repository, detached HEAD, no origin remote, origin/HEAD unset with no origin/main to fall back to, or a merge-base that resolves but yields an empty diff — say plainly which step failed and ask the user to either name the test files/folders to review or paste the test diff directly. Review exactly what they provide, treating all of it as touched. Never guess a base ref, and never silently widen to the whole working tree or the entire test suite.
• Filter to test files. Keep only files that are tests (e.g. *.test.*, *.spec.*, files under __tests__/, or whatever the repo's convention is) plus test helpers/fixtures they pull in. If the diff touches no test files, say so plainly and stop — there is nothing to review.

2. Load the rubric

Invoke the test-quality-rubric skill before reviewing anything, and read it in full (including its references/rubric-examples.md). Don't review from memory of a previous pass or paraphrase the rubric from recall — the skill is the single source of truth for what counts as a finding and which verdict it gets.

3. Review inline against the rubric

Do this yourself, here — no subagent.

Read scope and report scope are different. Read as widely as you need: the whole test file, its siblings in the suite, and the helpers and fixtures they share. Redundancy, consolidation and cross-test leakage are only visible in that context, and you cannot judge a touched test without it. Report only on lines this diff introduced or touched — an untouched pre-existing test is never a finding in its own right; it can only serve as evidence about a touched one, and you cite it as such.

Judge tests as strictly as production code — a bad test is worse than no test: it creates false confidence and busywork on every future change without ever catching a regression.

Every finding ends in exactly one of the three verdicts from test-quality-rubric: Delete, Merge into <file:line>, or Rewrite: <the concrete change>. Only report findings you have actually verified in the diff — if a test is fine, say so; do not invent findings to have something to report.

If the repo has test-specific guidance in its own CLAUDE.md or rules/*.mdc (only where such a rule's globs match a touched test file, or alwaysApply: true), honor it and cite it — but the rubric stands on its own and needs no written rule behind it. Never fabricate a guideline citation.

4. Report

Render findings grouped by severity (using the tiers from test-quality-rubric), reusing the tiering/emoji convention from a11y-review:

### Test Review — {ScopeName}

**Summary**
{N} touched tests reviewed → **delete {D}**, merge {M}, rewrite {R}, keep {K} as-is.
{X} blocking issue(s) and {Y} serious issue(s). [Optional: Z minor.]

#### 🔴 P1 — Blockers
- **Short title** — `file:line`
  **Why:** what makes this test low-value / unreadable / harmful
  **Verdict:** `Delete` | `Merge into file:line` | `Rewrite: <the concrete change>`

#### 🟠 P2 — Serious
[same structure]

#### 🟡 P3 — Minor (optional)
[same structure, or omit if none]

• The Summary's four counts are required, and delete leads. They must add up to {N}, and they are what the user reads first — never bury the deletion count inside the findings or replace it with prose.
• Every finding carries exactly one Verdict. A Delete verdict stands alone — no "…or alternatively rewrite it as", which reads as permission to keep it.
• Group the interaction-assertion findings and mass deletions: one finding may carry a Delete verdict over a list of lines — don't emit a near-identical finding per line.
• If a tier is empty, write None or state it's clear in the Summary — don't fabricate filler.
• Every finding must cite file:line and concrete evidence — no vague findings.
• {ScopeName} is the branch/diff description or PR#<number>.

5. Publish to GitHub (opt-in, only on explicit request)

By default, stop after rendering the report. Never offer to post it, and never post it proactively.

If — in this turn or a later one — the user explicitly asks to post/publish/submit the findings (or a subset) to GitHub, dispatch the code-review-publish agent:

• Pass it the PR reference (owner/repo + number) and the exact surviving findings, plus the summary line.
• If the scope was a local diff with no PR behind it, tell the user there's nothing to publish rather than dispatching the agent to guess a PR.
• It publishes every finding it's given verbatim — it does not re-filter or re-review. Any filtering the user wants (e.g. "just the P1s") happens here, before dispatch, not inside that agent.

Rules

• Report-only by default. Never edit files, never post GitHub PR comments, never open a review unless the user explicitly asks afterward — see step 5.
• Tests only. If the diff touches no test files, stop and say so — don't drift into reviewing production code.
• Never fabricate a guideline citation — the rubric needs none, and any repo rule you cite must be quoted.
• Every reported finding must cite file:line and concrete evidence.

Cross-refs

• test-quality-rubric skill — the rubric itself (principles, verdicts, severity). Load it in step 2; don't duplicate it here.
• Uses agents/code-review-publish.md only when the user explicitly asks to publish findings to GitHub after the fact — never dispatched as part of the review itself.