review

Code Review

Reviews against the full Darkroom quality checklist defined in the reviewer agent.

Focus areas: TypeScript strictness, React patterns, accessibility, performance, security, file structure.

Current State

• Branch: !git branch --show-current 2>/dev/null || echo "unknown"
• Staged files: !git diff --staged --stat 2>/dev/null || echo "nothing staged"
• Unstaged files: !git diff --stat 2>/dev/null || echo "nothing unstaged"

Get Changes

# Unstaged changes
git diff

# Staged changes
git diff --staged

# Specific file
git diff path/to/file

Cross-model review (when the Codex bridge is available)

This skill runs as the Claude reviewer agent — often Claude reviewing a diff Claude just wrote, the self-preferential-bias case. Run an independent review from a different model family in parallel and reconcile (the reviewer has Bash, so call the bridge directly):

bun "$HOME/.claude/src/scripts/codex-run.ts" review

Codex reads the same diff and returns HIGH / MEDIUM / LOW findings. Adjudicate every finding before it drives a fix — Codex produces false positives and stale findings, so its output is a set of claims, not a verdict. Tag each one:

• confirmed — you reproduced or traced it in the diff. Only confirmed findings drive a fix or land as Critical.
• rejected — a false positive or stale claim; note the one-line reason you rejected it.
• unverified — you couldn't check it cheaply; surface it as a Suggestion for a human, don't act on it.

Then fold the confirmed findings into the verdict below — map HIGH→Critical, MEDIUM→Warning, LOW→Suggestion. Agreement with your own review raises confidence. The bridge is gated and fails open: if Codex is unavailable, proceed with the Claude review alone.

Output Format

## Summary
[1-2 plain-English sentences: what this change does, then your overall read]

## Critical Issues
- [Must fix before merge]

## Warnings
- [Should fix, but not blocking]

## Suggestions
- [Nice to have improvements]

## Verdict
[APPROVED / NEEDS CHANGES / BLOCKED]

Remember

• Be constructive, not just critical
• Explain WHY something is an issue
• Comments in plain English — explain the issue and its impact like you're talking to a teammate, not citing a rulebook. No jargon dump.
• Suggest specific fixes
• If you find a pattern worth remembering, save it via auto-memory (personal) or /share-learning (team-wide).
• Escalate to /verify when the diff touches auth, payments, crypto, input validation, or a breaking public API — this skill is the fast checklist pass; /verify runs three adversarial agents (issue-finder, disprover, judge) and is the gate for security-sensitive or financial code.

Variant: Summarize Inbound PR Comments

When the user asks "what did reviewers say" or wants a digest of feedback on the active PR (not a self-review of local diff):

1. Resolve the active PR for the current branch.
2. Fetch review comments (file/line-anchored) and discussion comments (issue-level).
3. Group by severity — blocking, suggestion, nit, open question.
4. Return an action list ordered by priority.

Commands

# Resolve the active PR
gh pr view --json number,url,headRefName,reviews,comments

# Inline review comments (file/line anchored)
gh api repos/{owner}/{repo}/pulls/PR_NUMBER/comments \
  --jq '.[] | {user: .user.login, body, path, line}'

# Discussion comments (issue-level, not file-anchored)
gh api repos/{owner}/{repo}/issues/PR_NUMBER/comments \
  --jq '.[] | {user: .user.login, body, created_at}'

# Review states (APPROVED / CHANGES_REQUESTED / COMMENTED)
gh pr view --json reviews --jq '.reviews[] | {user: .author.login, state, body}'

Output Format

## Summary
[1-2 sentence overview of feedback]

## Blocking (must address)
- [reviewer]: [path:line] — [issue + suggested fix]

## Suggestions (should address)
- [reviewer]: [path:line] — [issue]

## Nits (optional)
- [reviewer]: [path:line] — [issue]

## Open questions
- [unresolved threads needing a reply]

Guardrails

• Quote actual reviewer text. Do not paraphrase in ways that change meaning.
• Group by severity, not by reviewer.
• If a reviewer didn't mark severity explicitly, infer from language ("must", "should", "consider", "nit:").