| name | develop-review |
| description | Reviews source code or a diff - correctness, least-code, type-safety, security, test adequacy - as severity-rated findings with fixes. Loads a stack reference (e.g. typescript). Use for code review. |
| argument-hint | <stack> |
Reviewing source code
Critique a diff for defects and least-code; output prioritized findings with concrete fixes. Apply review-principles (the shared critique rules) and dev-principles (the simplest correct change wins). Pairs with develop-write the way design-review pairs with design-draft.
Use for code review of a PR or change. For verifying behavior against acceptance criteria see qa-review; for applying cleanups see develop-clean; for critiquing a UI/design see design-review.
Stack guidance
Load references/typescript.md for the target language's review checklist (add more stacks as reference files); with no file for the user's language, apply the steps below and say so.
Steps
- Frame the review. Understand the change's intent and scope from the description and diff, and run the build and tests before opining - the real bugs do not show in a static read.
- Correctness first. Logic errors, off-by-one, null/empty/boundary handling, error paths, concurrency and races, resource leaks. These are the highest-value findings.
- Least-code and reuse. Is there a simpler form, an existing helper to compose, or code to delete? Flag added complexity, abstractions, or dependencies that do not earn their place (
dev-principles).
- Safety rail (lazy, not negligent). Escape hatches (
any-equivalents, unchecked casts, force-unwraps), unvalidated input at trust boundaries, missing error handling, and security - injection, secrets in code, broken authz (security-principles). Never wave these through for brevity.
- Tests. Does the change pin the new behavior and its edges with tests? Missing or weak tests are a finding (hand to
qa-test).
- Readability, at the right altitude. Naming, cohesion, comments that explain why. Separate must-fix from preference; lean on the formatter/linter for style, and do not block on taste.
- Output severity-rated findings, each with a concrete fix and a reason tied to a real cost. Sort by severity; no finding without a fix.
Severity
0 taste/preference, 1 minor, 2 should-fix, 3 must-fix (bug or risk), 4 blocker (broken or unsafe). Call out the top few.
Gotchas
- If a diff is too large to hold in your head, ask to split it rather than rubber-stamp it.
- Review is critique only; hand fixes back to the author or apply them via
develop-clean - do not silently rewrite.
