SECURITY REVIEW
Not yet assessed
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
Testing · Security / AGENT SKILL
code-review
0
Review pull request changes for correctness, security, maintainability, and test coverage.
Reviews pull request diffs for correctness, security, maintainability, and test coverage. Use when the user asks for a code review of a change set, patch, or PR description.
Understand the trade-offs.
SKILL QUALITY
Not yet assessed
How clearly the skill guides your agent, how complete its workflow is, and how you can check the outcome.
No quality assessment is available for this catalog entry yet.
The full skill.
Original instructions from the publisher’s SKILL.md
# Code Review ## Instructions When reviewing a diff/PR, follow this flow: 1. **Clarify context (if missing)** - Ask for the repo name, language/framework, and what “done” means (e.g., “ready to merge” vs “early review”). - If the user did not provide a diff, ask them to paste the relevant patch or describe the files/behavior changed. 2. **Summarize the change** - Provide a 2–5 sentence summary of what changed and the most important impact. 3. **Identify issues with severity** - Report issues in this order: **Critical**, **Suggestion**, **Nice-to-have**. - For each issue, include: `severity`, `area` (correctness/security/performance/maintainability/tests/style), `location` (file path and the changed symbol/section when possible), and `why it matters`. - Prefer specific, actionable fixes over general guidance. 4. **Security review** - Check for common risks relevant to the language/framework: injection (SQL/NoSQL/command), XSS/CSRF, authz/authn mistakes, unsafe deserialization, SSRF, secrets in logs, and overly-permissive CORS. - If user input handling exists, validate, sanitize/escape appropriately, and enforce allow-lists where possible. 5. **Correctness & robustness** - Look for broken invariants, edge cases, race conditions, timezone/locale bugs, error handling, and inconsistent data types. - Verify new/modified code paths are exercised by the change. 6. **Maintainability** - Check naming, complexity, duplication, API boundaries, and whether abstractions match existing patterns. - Flag “spaghetti logic” or overly broad functions/modules. 7. **Tests & quality gate** - Identify missing/weak tests that would have caught the issues you found. - If the repo has test tooling detectable from the diff (e.g., `jest`, `vitest`, `pytest`, `go test`, `npm test`), suggest the most likely command(s) to run. - If you cannot infer a command reliably, list what to test instead (unit/integration/E2E) without guessing exact commands. 8. **Close-out recommendation** - End with a short decision suggestion: “Approve”, “Request changes”, or “Needs follow-up” based on Critical items. ## Output Template Use this structure by default: ```text Summary - ... Critical - [file/path] <what> — <why> — Fix: <specific change> Suggestion - [file/path] <what> — <why> — Fix: <specific change> Nice-to-have - [file/path] <what> — <why> — Improvement: <specific change> Test plan (what to run / what to add) - ... Recommendation - Approve / Request changes / Needs follow-up ``` ## Standards - If the repo contains a style guide or security guidelines (commonly `docs/STYLE.md`, `STYLE_GUIDE.md`, `SECURITY.md`, or `CONTRIBUTING.md`), align findings and fix suggestions to those documents.