title: Thorough Code Review

description: Review a diff for correctness, design, security, and maintainability.

content:
Review the following change:

```
{{diff}}
```

Go in this order, reporting only real issues:
1. Correctness — bugs, broken edge cases, wrong assumptions.
2. Security — injection, authz, secrets, unsafe input.
3. Design — coupling, naming, fit with existing patterns.
4. Maintainability — clarity, tests, docs.

For each finding give: severity, the specific location, why it matters, and a concrete fix. Lead with the most important. If it's solid, say so plainly rather than inventing nits.

diff

description: The diff or code to review


title: Security-Focused Review

description: Audit a change specifically for security vulnerabilities.

content:
Review this code for security issues only:

```
{{code}}
```

Check for: injection (SQL/command/template), broken authn/authz, secrets in code or logs, unsafe deserialization, SSRF, path traversal, missing input validation, and unsafe defaults. For each issue: the exploit scenario, severity, and the fix. If you find nothing exploitable, state what you verified rather than padding the list.

code

description: The code to audit


title: Review for Performance

description: Spot performance problems in a change before they ship.

content:
Review this code for performance problems:

```
{{code}}
```

Look for: N+1 queries, unnecessary allocations in hot paths, accidental O(n^2), blocking I/O on critical paths, missing pagination/limits, and repeated work that could be cached. For each, estimate the impact and whether it matters at this code's expected scale. Don't micro-optimize cold paths.

description: The code to review


title: Review My Own PR

description: Self-review a change before requesting human review.

content:
Act as a demanding reviewer for my own change before I send it:

```
{{diff}}
```

Tell me what a sharp reviewer would push back on: unclear naming, missing tests, untested edge cases, scope creep, leftover debug code, or a simpler approach I missed. Be the critic I'd rather hear from now than in review. End with the single most important thing to fix first.

diff

description: Your change


title: Explain Review Feedback

description: Understand and act on review comments you received.

content:
I got this review feedback and want to understand it fully:

{{feedback}}

On this code:

```
{{code}}
```

Explain what the reviewer is really concerned about, why it matters, and show the change that addresses it. If the feedback is debatable, give me the counter-argument too so I can respond thoughtfully.

feedback

description: The review comment

code

description: The code in question


title: Check Naming and API Design

description: Critique the names and public interface of a module.

content:
Critique the naming and public API of this code:

```
{{code}}
```

For names: are they accurate, consistent, and at the right level of abstraction? For the API: is it hard to misuse, minimal, and consistent with the rest of the codebase? Suggest better names and signatures where warranted, and explain the principle behind each suggestion. Flag any name that lies about what it does.

description: The code to critique


title: Review for Backward Compatibility

description: Check whether a change breaks existing callers or data.

content:
Assess whether this change is backward compatible:

```
{{diff}}
```

Identify any break to: public function signatures, serialized data formats, config keys, API responses, or behavior existing callers depend on. For each break, propose either a non-breaking alternative or a migration path (deprecation window, version gate, data migration). State clearly whether this can ship without a major version bump.

diff

description: The change to assess


title: Concurrency Review

description: Review code for race conditions and concurrency bugs.

content:
Review this code for concurrency correctness:

```
{{code}}
```

Identify shared mutable state and the invariants on it. Look for: data races, check-then-act races, deadlock/lock-ordering issues, missing memory visibility, and unsafe lazy initialization. For each, describe the interleaving that triggers it and the fix. If it's a single-threaded context, confirm that and stop.

code

description: The code to review


title: Review for Test Quality

description: Assess whether a change is adequately tested.

content:
Review the test coverage of this change:

{{diff}}

Do the tests actually exercise the new behavior, including its edge cases and failure modes? Would they fail if the code regressed? Flag missing tests for risky paths, tautological assertions, and over-mocking that tests nothing. Distinguish code that genuinely needs more tests from code that's fine as-is. Be specific about what test to add.

diff

description: The change to review


title: Review a Database Migration

description: Catch problems in a schema migration before it ships.

content:
Review this database migration:

{{migration}}

Check for: locking or downtime on large tables, irreversibility, data loss, missing indexes for new query patterns, nullability and default surprises, and whether old and new application code can both run against the intermediate schema. Flag anything that can't be rolled back and propose a safer expand-then-contract sequence if needed.

migration

description: The migration to review


title: Review for Accessibility

description: Check a UI change for accessibility issues.

content:
Review this UI for accessibility:

{{code}}

Check: semantic markup and headings, keyboard operability and focus order, labels and names for controls, color contrast, alt text, ARIA used correctly (and not redundantly), and motion or auto-play concerns. For each issue, the impact on which users and the concrete fix. Prioritize blockers (unusable by keyboard or screen reader) over nits.

code

description: The UI markup or component


title: Assess Change Risk

description: Gauge how risky a change is and what to do about it.

content:
Assess the risk of shipping this change:

{{diff}}

Rate the blast radius (who and what breaks if it's wrong), the reversibility, and how well it's tested and observable. Identify the single riskiest line or assumption. Recommend a rollout that matches the risk: feature flag, canary, gradual ramp, or just ship. Tell me what to watch after deploy to catch a problem early.

diff

description: The change to assess


title: Review Error Handling

description: Check that failures are handled, not just the happy path.

content:
Review the error handling in this change:

{{diff}}

Check: are errors caught at the right level, or swallowed? Is failure surfaced with enough context to debug? Are resources cleaned up on the error path? Does a partial failure leave consistent state? Are errors that should propagate being hidden, and vice versa? Flag any empty catch, any error turned into a misleading default, and any path that fails silently. Be specific about what to change.

description: The change to review


title: Review for Maintainability

description: Judge how this code will age, not just whether it works.

content:
Review this code for maintainability:

{{code}}

Ask: will the next person understand it in six months? Is the intent clear, are the names honest, is the structure easy to change? Flag the parts that are clever instead of clear, the implicit assumptions, and the spots where a small future change would be painful. Distinguish real maintainability risks from style nits. Suggest the one change that most improves how this code will age.

code

description: The code to review


title: Review a Public API Change

description: Scrutinize a change to an interface others depend on.

content:
Review this change to a public API:

{{diff}}

This is a contract other code depends on. Check for breaking changes (signatures, behavior, error semantics, defaults), and whether they are necessary. Assess naming, consistency with the rest of the API, and whether the change is easy to use correctly and hard to misuse. Consider versioning and a deprecation path. Flag anything that locks us into a shape we will regret exposing.

diff

description: The API change


title: Spot Hidden Coupling

description: Find the implicit dependencies a change introduces.

content:
Review this change for hidden coupling:

{{diff}}

Look past the obvious: does it reach into another module's internals, depend on call order, share mutable global state, or assume something about a caller it shouldn't? Identify the implicit contracts that, if broken elsewhere, would break this. For each, say why it is risky and how to decouple. Distinguish acceptable coupling from the kind that will cause spooky action at a distance.

description: The change to inspect