---
name: critique-review
description: Perform rigorous AI-assisted code review for pull requests, local diffs, commits, patches, and repository changes. Use when the user asks to review code, inspect a PR, find bugs or regressions, assess security and correctness, evaluate tests, prepare review comments, or act as a senior engineering reviewer before merge.
---

# Critique Review

Use this skill to review code like a senior engineer responsible for whether the change should ship. Prioritize correctness, security, maintainability, and test confidence over style preferences. Approve imperfect code when it clearly improves the codebase and carries an adequate verification story; request changes only for risks that matter.

Install from GitHub:

```bash
npx skills add https://github.com/repath500/critique --skill critique-review --copy --full-depth
```

Download this Markdown directly from:

```text
https://www.critique.sh/api/skills/critique-review
```

## Default Workflow

1. Establish scope.
   - Identify the base and head refs, PR number, commit range, patch file, or modified files.
   - Inspect the changed files and enough surrounding code to understand behavior, ownership boundaries, and existing patterns.
   - If reviewing a GitHub PR, read the PR title, body, diff, changed file list, review comments, and CI state when available.
2. Build a risk map before writing findings.
   - Note user-facing behavior changes, data model changes, auth or permission checks, migrations, network calls, concurrency, caching, money or billing paths, and generated or AI-authored code.
   - Check change size and shape: focused changes are easier to trust; mixed feature/refactor PRs, ~1000-line diffs, or broad cross-cutting edits need extra scrutiny and may need splitting.
   - Read tests related to changed behavior before deciding whether coverage is sufficient.
3. Verify claims.
   - Run targeted tests, typecheck, lint, or focused static searches when feasible.
   - If a claim cannot be verified, label it as a question or residual risk instead of a finding.
   - Do not report hypothetical issues that require unlikely assumptions.
4. Produce the review.
   - Findings first, ordered by severity.
   - Each finding must include file and line references, impact, why the current code fails, and a concrete fix direction.
   - Keep summaries short and place them after findings.
5. Stop at review unless asked to fix.
   - Do not edit files during a review-only request.
   - If the user asks to fix findings, make the smallest targeted change and re-run relevant checks.

## Review Axes

Cover these axes on every non-trivial review:

- Correctness: requirements, edge cases, error paths, race conditions, state transitions, time and locale behavior.
- Security: trust boundaries, authz/authn, tenant isolation, injection, secret handling, webhook verification, unsafe external data.
- Tests: behavior-focused coverage, regression tests for bug fixes, integration paths for risky logic, and whether tests would fail on the old bug.
- Architecture: fit with local patterns, dependency direction, module depth, needless coupling, mixed refactor/feature work, dead code.
- Performance and operations: N+1 queries, unbounded work, hot-path allocations, cache invalidation, retries, idempotency, migrations, deploy order.

## Review Standard

Treat a finding as actionable only when it meets all of these:

- It can cause a real bug, security issue, data loss, broken UX, regression, failed deploy, scaling problem, or meaningful maintainability cost.
- It is grounded in the changed code or behavior affected by the change.
- It is specific enough that the author can fix it without a long back-and-forth.

Severity:

- `P0`: Blocks merge; security breach, data corruption/loss, production outage, or guaranteed critical failure.
- `P1`: Must fix before merge; common crash, auth bypass, broken core flow, serious regression, or missing migration/test for risky behavior.
- `P2`: Should fix; edge-case bug, maintainability risk, performance issue, flaky behavior, or incomplete coverage with plausible impact.
- `P3`: Optional polish; clarity, small refactor, naming, or low-impact test improvement. Use sparingly.

Read `references/review-rubric.md` when the review touches security, data integrity, concurrency, migrations, AI-generated code, agent behavior, public API compatibility, or large mixed-purpose diffs.

## Evidence Gathering

Prefer the repository's own tools:

```bash
git diff --stat
git diff --name-only
git diff <base>...<head>
rg "<symbol or behavior>"
```

Use framework-specific checks when available, such as `pnpm test`, `pnpm lint`, `pnpm exec tsc --noEmit`, `npm test`, `pytest`, `go test ./...`, `cargo test`, or targeted package commands. Report any check that could not run and why.

For GitHub reviews, use available GitHub tools or `gh` to fetch metadata, patch context, comments, and CI. Do not assume flat comments represent unresolved review-thread state.

When using a separate reviewer agent, pass only the task, requirements, base/head refs, and raw diff context. Do not pass the main session's hidden reasoning or conclusions; the point is an independent read.

## Output Format

If there are findings:

```markdown
**Findings**
- [P1] Title
  File: `/absolute/path/or/repo/path.ext:123`
  Impact: ...
  Why: ...
  Fix: ...

**Open Questions**
- ...

**Checks**
- ...

**Verdict**
Request changes / Approve with notes / No objection

**Summary**
Brief change summary and residual risk.
```

If no issues are found:

```markdown
No blocking or actionable issues found.

Checks: ...
Verdict: No objection.
Residual risk: ...
```

Avoid long prose, praise, and generic advice. Never bury findings under a summary.