/pr-review

name: pr-review
description: >-
  Review a pull request or analyze local changes before submitting. Checks the diff against what
  the ticket asked for, then for correctness bugs, and reports only findings that survive a
  concrete failure scenario and verification against the file. Findings post as inline
  suggestions, and silence is a valid result. Invoke when the user gives a PR number, asks for a
  code review, wants changes analyzed before submitting, or says "pr review", "review self",
  "review my changes", or "pr-review self". Focus areas: code, security, breaking, testing, size,
  performance.

PR Review

Report only findings that survive verification. A fabricated finding forces the reader to re-check everything. Usage: "Review PR #123", "review my changes".

Output

Copy this shape in every mode. Delivery is decided in step 6 and never changes what you write.

Request changes. The overflow rule clips two card variants the ticket never mentions, and the
alert dismissal reads an option name nothing writes.

**Critical: the dismissal expiry is read from an option nothing writes**
- File: `inc/class-alerts.php:88`
- Issue: The save path writes `alert_dismissed_until`, so this read always falls back to 0 and the alert never stays dismissed.
- Fix:
```suggestion
	$until = (int) get_option( 'alert_dismissed_until', 0 );

**Important: `.card` overflow clips every card variant**

• File: `css/blocks.css:31`
• Issue: `.card--profile` and `.card--stat` hang their badge outside the box; this rule cuts it off.
• Fix:

.card--event { overflow: hidden; }

**Minor: `card--event` is missing from the variant table**

• File: `css/blocks.css:31`
• Apply: `docs/components/cards.md` (not in this diff)
• Issue: The table is how the next developer finds a variant, so an absent one gets rebuilt by hand.
• Fix: Add a `card--event` row beside the existing `card--profile` row.

Unverified: the 781px stacking, since no browser ran here.

Rules for the shape:

- A review is three parts: one verdict line, findings most severe first, one closing
  `Unverified:` line. Every sentence lives in one of these slots. A sentence with no slot is
  deleted, not relocated.
- Each label holds one line. `Issue:` is one short sentence: the input or state, then the wrong
  result. Write "the last pass reads `$posts[3]` of a 3-item array and fatals on null", not
  "`count()` is a valid index only up to `count() - 1`, so the loop runs one pass too many and
  reads an undefined offset, throwing a fatal whenever posts exist". The proof stays in your
  head; the `Fix:` carries the mechanism.
- Severity: `Critical` ships a bug, security hole, or data loss. `Important` blocks the merge.
  `Minor` is the author's call. Approve when the change improves code health, even if imperfect.
- `File:` is where the problem shows, on every finding. `Apply:` is where the change goes,
  omitted when that is the same line.
- `Fix:` is a ```suggestion``` block replacing exactly the `Apply:` line (or the `File:` line
  when there is no `Apply:`), or one named concrete action. No line to replace, no block.
- `Unverified:` names what could not be checked, including shared selectors, classes, hooks, or
  config keys the diff touches that you could not clear.

## Workflow

1. **Gate.** Closed, merged, draft, already reviewed with no new commits, automated (dependency
   bumps, lockfiles, generated files), or purely mechanical (formatting, a uniform rename,
   comments only): reply `Skipping review:` with the reason and stop.
2. **Target.** A PR number: review that PR in this session. "self" or "my changes": spawn the
   specialist (below). A prompt naming a base and head: you are the spawned specialist or an
   automated routine, so review that diff here, with no dialogue, and never spawn. None of
   these: ask.
3. **Context.** In parallel: `gh pr view <n> --json title,body,baseRefName,changedFiles`,
   `gh pr diff <n>`, `gh pr checks <n>`, and `gh issue view <n>` for any issue the PR or its
   commits reference. Local diff: against the default branch, plus uncommitted changes. No
   `gh`: ask for the diff and say what you could not see. Over 1,000 lines: suggest a split.
4. **Spec axis.** Follow the Teamwork link in the PR body, then a GitHub issue the PR or its
   commits reference, then the PR body. Quote the requirement line for each spec finding.
   When none of these carries requirements, say so in one line and skip this axis. Never
   invent a requirement.
5. **Correctness axis.** Bugs in the changed lines and in the unchanged lines of any function
   the diff touches. Three lenses direct the investigation. Their answers reach the output only
   as findings that survive step 6, or on the `Unverified:` line, never as narration.
   - **Blast radius.** For every selector, class, hook, filter, or config key the diff touches,
     search the theme, plugin, and content for the other things carrying it.
   - **Silent failure.** For every poll, retry, timeout, fallback, or `catch`, find the branch
     that runs when it gives up and what that branch logs. A bounded loop that expires without
     a warning is a defect.
   - **Removed behavior.** For every line the diff deletes or replaces, name the invariant it
     enforced, then find where the new code re-establishes it. Nowhere is a candidate.
6. **Verify, then deliver.** Re-read each finding against the file and vote:
   - **CONFIRMED**: you can name the inputs or state that trigger it and the wrong result.
     Quote the line.
   - **PLAUSIBLE**: the mechanism is real, the trigger is uncertain (timing, environment,
     config). State what would confirm it in the `Issue:` line.
   - **REFUTED**: factually wrong or guarded elsewhere. Quote the line that proves it, then
     drop the finding.

   Report CONFIRMED and PLAUSIBLE findings only. Read every ```suggestion``` block as the
   literal replacement for its `Apply:` line. Then check each findi