code-review
starsforks
How to install code-review?
developersglobal/ai-agent-skills/code-review
$npx -y skills add DevelopersGlobal/ai-agent-skills --skill code-reviewStructured code review focusing on correctness, security, and maintainability. Correctness before style. Every reviewer comment must be actionable.
SKILL.md
| 1 | ## Overview |
| 2 | |
| 3 | Code review is the last line of defense before code reaches production. This skill structures the review process to catch real issues — not just style preferences — and ensures every comment is actionable and proportionate. |
| 4 | |
| 5 | ## When to Use |
| 6 | |
| 7 | - Before merging any pull request |
| 8 | - When reviewing AI-generated code |
| 9 | - When auditing existing code for quality |
| 10 | |
| 11 | ## Process |
| 12 | |
| 13 | ### Step 1: Understand the Change |
| 14 | |
| 15 | 1. Read the PR description fully — understand the intent before reading code. |
| 16 | 2. Check: Does the implementation match the stated intent? |
| 17 | 3. Identify the risk level: data mutation? auth changes? public API? |
| 18 | |
| 19 | **Verify:** You understand what the PR is trying to accomplish. |
| 20 | |
| 21 | ### Step 2: Correctness Review |
| 22 | |
| 23 | 4. Does the code do what it claims to do? |
| 24 | 5. Are there off-by-one errors, null dereferences, or race conditions? |
| 25 | 6. Are all error cases handled? |
| 26 | 7. Do tests cover the happy path AND key failure paths? |
| 27 | |
| 28 | **Verify:** You can trace the execution path for the primary use case and 2 failure cases. |
| 29 | |
| 30 | ### Step 3: Security Review |
| 31 | |
| 32 | 8. Apply [security-hardening skill](../security-hardening/SKILL.md) to any auth/input/data changes. |
| 33 | 9. Does this change open any OWASP Top 10 vulnerabilities? |
| 34 | 10. Are any secrets or PII handled correctly? |
| 35 | |
| 36 | ### Step 4: Maintainability Review |
| 37 | |
| 38 | 11. Will the next developer understand this code without the author present? |
| 39 | 12. Are functions doing one thing? |
| 40 | 13. Are names descriptive and accurate? |
| 41 | 14. Is complexity proportionate to the problem? |
| 42 | |
| 43 | ### Step 5: Provide Actionable Feedback |
| 44 | |
| 45 | 15. Every comment must be one of: |
| 46 | - **Blocker**: Must be fixed before merge |
| 47 | - **Suggestion**: Optional improvement |
| 48 | - **Question**: Needs clarification (not necessarily a problem) |
| 49 | 16. Blockers must be specific: *"This SQL query is vulnerable to injection via `{username}` — use parameterized queries."* |
| 50 | 17. Never leave vague comments like *"this doesn't look right"* without explaining why. |
| 51 | |
| 52 | ## Common Rationalizations (and Rebuttals) |
| 53 | |
| 54 | | Excuse | Rebuttal | |
| 55 | |--------|----------| |
| 56 | | "I'll review it quickly" | A rushed review is not a review. Take the time or ask someone who can. | |
| 57 | | "The tests pass so it's fine" | Tests prove the code works for tested inputs, not that it's secure or maintainable. | |
| 58 | | "I'll comment on style later" | Style comments without blocker separation waste everyone's time. Label them. | |
| 59 | |
| 60 | ## Verification |
| 61 | |
| 62 | - [ ] Correctness verified for primary and failure paths |
| 63 | - [ ] Security review applied to sensitive changes |
| 64 | - [ ] All comments labeled (blocker/suggestion/question) |
| 65 | - [ ] Tests reviewed for meaningful coverage |
| 66 | - [ ] No vague or unactionable comments |
| 67 | |
| 68 | ## References |
| 69 | |
| 70 | - [security-hardening skill](../security-hardening/SKILL.md) |
| 71 | - [references/security-checklist.md](../../references/security-checklist.md) |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
