{"title":"Thorough Code Review","description":"Review a diff for correctness, design, security, and maintainability.","tags":["review","diff","quality"],"content":"Review the following change:\n\n```\n{{diff}}\n```\n\nGo in this order, reporting only real issues:\n1. Correctness — bugs, broken edge cases, wrong assumptions.\n2. Security — injection, authz, secrets, unsafe input.\n3. Design — coupling, naming, fit with existing patterns.\n4. Maintainability — clarity, tests, docs.\n\nFor 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.","variables":[{"name":"diff","description":"The diff or code to review","required":true,"multiline":true}]}
{"title":"Security-Focused Review","description":"Audit a change specifically for security vulnerabilities.","tags":["security","audit","owasp"],"content":"Review this code for security issues only:\n\n```\n{{code}}\n```\n\nCheck 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.","variables":[{"name":"code","description":"The code to audit","required":true,"multiline":true}]}
{"title":"Review for Performance","description":"Spot performance problems in a change before they ship.","tags":["performance","review"],"content":"Review this code for performance problems:\n\n```\n{{code}}\n```\n\nLook 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.","variables":[{"name":"code","description":"The code to review","required":true,"multiline":true}]}
{"title":"Review My Own PR","description":"Self-review a change before requesting human review.","tags":["self-review","pr"],"content":"Act as a demanding reviewer for my own change before I send it:\n\n```\n{{diff}}\n```\n\nTell 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.","variables":[{"name":"diff","description":"Your change","required":true,"multiline":true}]}
{"title":"Explain Review Feedback","description":"Understand and act on review comments you received.","tags":["feedback","mentorship"],"content":"I got this review feedback and want to understand it fully:\n\n{{feedback}}\n\nOn this code:\n\n```\n{{code}}\n```\n\nExplain 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.","variables":[{"name":"feedback","description":"The review comment","required":true},{"name":"code","description":"The code in question","required":true,"multiline":true}]}
{"title":"Check Naming and API Design","description":"Critique the names and public interface of a module.","tags":["naming","api-design","ergonomics"],"content":"Critique the naming and public API of this code:\n\n```\n{{code}}\n```\n\nFor 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.","variables":[{"name":"code","description":"The code to critique","required":true,"multiline":true}]}
{"title":"Review for Backward Compatibility","description":"Check whether a change breaks existing callers or data.","tags":["compatibility","breaking-change","migration"],"content":"Assess whether this change is backward compatible:\n\n```\n{{diff}}\n```\n\nIdentify 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.","variables":[{"name":"diff","description":"The change to assess","required":true,"multiline":true}]}
{"title":"Concurrency Review","description":"Review code for race conditions and concurrency bugs.","tags":["concurrency","races","review"],"content":"Review this code for concurrency correctness:\n\n```\n{{code}}\n```\n\nIdentify 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.","variables":[{"name":"code","description":"The code to review","required":true,"multiline":true}]}
{"title":"Review for Test Quality","description":"Assess whether a change is adequately tested.","tags":["tests","review"],"content":"Review the test coverage of this change:\n\n{{diff}}\n\nDo 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.","variables":[{"name":"diff","description":"The change to review","required":true,"multiline":true}]}
{"title":"Review a Database Migration","description":"Catch problems in a schema migration before it ships.","tags":["database","migration","review"],"content":"Review this database migration:\n\n{{migration}}\n\nCheck 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.","variables":[{"name":"migration","description":"The migration to review","required":true,"multiline":true}]}
{"title":"Review for Accessibility","description":"Check a UI change for accessibility issues.","tags":["accessibility","a11y","ui","review"],"content":"Review this UI for accessibility:\n\n{{code}}\n\nCheck: 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.","variables":[{"name":"code","description":"The UI markup or component","required":true,"multiline":true}]}
{"title":"Assess Change Risk","description":"Gauge how risky a change is and what to do about it.","tags":["risk","review","rollout"],"content":"Assess the risk of shipping this change:\n\n{{diff}}\n\nRate 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.","variables":[{"name":"diff","description":"The change to assess","required":true,"multiline":true}]}
{"title":"Review Error Handling","description":"Check that failures are handled, not just the happy path.","tags":["error-handling","review"],"content":"Review the error handling in this change:\n\n{{diff}}\n\nCheck: 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.","variables":[{"name":"diff","description":"The change to review","required":true,"multiline":true}]}
{"title":"Review for Maintainability","description":"Judge how this code will age, not just whether it works.","tags":["maintainability","review"],"content":"Review this code for maintainability:\n\n{{code}}\n\nAsk: 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.","variables":[{"name":"code","description":"The code to review","required":true,"multiline":true}]}
{"title":"Review a Public API Change","description":"Scrutinize a change to an interface others depend on.","tags":["api","compatibility","review"],"content":"Review this change to a public API:\n\n{{diff}}\n\nThis 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.","variables":[{"name":"diff","description":"The API change","required":true,"multiline":true}]}
{"title":"Spot Hidden Coupling","description":"Find the implicit dependencies a change introduces.","tags":["coupling","review"],"content":"Review this change for hidden coupling:\n\n{{diff}}\n\nLook 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.","variables":[{"name":"diff","description":"The change to inspect","required":true,"multiline":true}]}