code-review

Use this skill when asked to review, audit, critique, or improve any piece of code.

---

Review Order

Always work through these layers in order. Never skip a layer even if earlier ones look fine.

• Correctness - Does it do what it claims? Are edge cases handled?
• Security - Injection, unvalidated input, exposed secrets, unsafe deserialization.
• Reliability - Error handling, null safety, resource cleanup, race conditions.
• Performance - Unnecessary loops, missing indexes, N+1 queries, unbounded memory.
• Readability - Naming, function length, cyclomatic complexity, dead code.
• Style - Conventions consistent with the surrounding codebase.

---

Output Format

Structure your review as follows:

---

Rules

• Never rewrite the entire file unprompted. Fix what was asked about.
• Every Critical and Warning item must include a concrete corrected snippet - not just a description.
• If you are uncertain whether something is a bug or intentional design, say so explicitly.
• Do not flag style issues as Critical. Severity must be accurate.
• If the code is in a specific language, apply language-idiomatic standards (e.g. Result types in Rust, Option chaining in Swift, context.Context propagation in Go).

---

Language-Specific Gotchas

See language-notes.md for common pitfalls per language to check during review.

---

Severity Definitions

Level	Meaning
Critical	Will cause a bug, crash, or security issue in production
Warning	Degrades quality, reliability, or maintainability
Suggestion	Improvement only - no functional impact