agentleFS
WomenDefiningAIWomenDefiningAI/claude-code-skills/skills/code-reviewer/SKILL.md

code-reviewer

Skill10 starsChanged 13 months agoMITView on GitHub

Research-backed code review skill with OWASP Top 10 security checks, SAST tool integration (SonarQube, CodeQL, Snyk), performance pattern detection, and automated quality standards enforcement. Auto-invoked for code review, security audit, PR analysis, and bug checking. Implements 2025 best practices with 92% faster vulnerability remediation.

182 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use git-doc-updater, git-precommit and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • u9401066Skill

    git-doc-updater

    Auto-check and update key documentation before Git commits to keep docs in sync with code. Triggers: docs, 文檔, 更新文檔, sync docs, release, 發布.

    Also in 5 projects that use this

  • u9401066Skill

    git-precommit

    Orchestrate pre-commit workflow including Memory Bank sync, README/CHANGELOG/ROADMAP updates. Triggers: GIT, gc, push, commit, 提交, 準備 commit, 要提交了, git commit, pre-commit, 推送.

    Also in 5 projects that use this

  • JeffallanSkill

    shopify-expert

    Builds and debugs Shopify themes (.liquid files, theme.json, sections), develops custom Shopify apps (shopify.app.toml, OAuth, webhooks), and implements Storefront API integrations for headless storefronts. Use when building or customizing Shopify themes, creating Hydrogen or custom React storefronts, developing Shopify apps, implementing checkout UI extensions or Shopify Functions, optimizing performance, or integrating third-party services. Invoke for Liquid templating, Storefront API, app development, checkout customization, Shopify Plus features, App Bridge, Polaris, or Shopify CLI workflows.

    Also in 5 projects that use this

  • JeffallanSkill

    spec-miner

    Reverse-engineering specialist that extracts specifications from existing codebases. Use when working with legacy or undocumented systems, inherited projects, or old codebases with no documentation. Invoke to map code dependencies, generate API documentation from source, identify undocumented business logic, figure out what code does, or create architecture documentation from implementation. Trigger phrases: reverse engineer, old codebase, no docs, no documentation, figure out how this works, inherited project, legacy analysis, code archaeology, undocumented features.

    Also in 6 projects that use this

  • +4 more from u9401066
  • +4 more from Jeffallan

The file

Show its rules and text

We split this skill into the rules it gives an agent

29 rules. 0 are common, 19 are distinctive, and 10 are very specific to this project.

  • 0

    Common

    Most of the 155 edited versions we read keep these.

  • 19

    Distinctive

    This author's own choices. Worth a look.

  • 10

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before committing critical changes

    line 54
  2. Distinctive:

    After implementing security-sensitive features

    line 56
  3. Distinctive:

    When integrating SAST tool results

    line 57
  4. Distinctive:

    If reviewing specific files: Read those files

    line 68
  5. Distinctive:

    If reviewing PR/changes: Use git diff to see changes

    line 69
  6. Distinctive:

    If reviewing entire feature: Identify affected files via grep/glob

    line 70
  7. Very specific:

    Use the scripts in scripts/ directory:

    line 74
  8. Very specific:

    Use templates from resources/templates/ to create structured output:

    line 184
  9. Very specific:

    Comprehensive Review: Use resources/templates/code-review-report.md

    line 185
  10. Very specific:

    Security Audit: Use resources/templates/security-review-template.md

    line 186
  11. Very specific:

    Performance Review: Use resources/templates/performance-review-template.md

    line 187
  12. Very specific:

    Quick Check: Use resources/templates/quick-checklist.md

    line 188
  13. Very specific:

    Read sonar-report.json or access SonarQube API

    line 228
  14. Distinctive:

    Critical/High: Must fix before merge

    line 246
  15. Distinctive:

    Use CodeQL's suggested fixes when available

    line 249
  16. Very specific:

    Run snyk test for dependency vulnerabilities

    line 264
  17. Very specific:

    Run snyk code test for code-level issues

    line 265
  18. Very specific:

    Check for available patches: snyk wizard

    line 270
  19. Distinctive:

    ESLint: Must pass with 0 errors (warnings acceptable if documented)

    line 290
  20. Distinctive:

    Use this framework to categorize all findings:

    line 297
  21. Distinctive:

    Action: STOP. Must fix immediately before proceeding.

    line 307
  22. Distinctive:

    Action: Create blocker ticket. Fix before next deployment.

    line 318
  23. Distinctive:

    Action: Create ticket. Fix within current sprint.

    line 328
  24. Distinctive:

    Use severity classification to prioritize

    line 376
  25. Distinctive:

    Don't let perfection block progress

    line 377
  26. Distinctive:

    Check if the approach is fundamentally sound

    line 381
  27. Distinctive:

    Before approving any code review:

    line 391
  28. Distinctive:

    Update test coverage metrics

    line 429
  29. Distinctive:

    Create tickets for medium/low priority issues

    line 432

“Common” is measured: kept by at least 6 in 10 of the 155 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
<!-- Created by: Madina Gbotoe (https://madinagbotoe.com/) Version: 1.0 Created: November 3, 2025 License: Creative Commons Attribution 4.0 International (CC BY 4.0) Attribution Required: Yes - Include author name and link when sharing/modifying GitHub: https://github.com/mgbotoe/claude-code-share/tree/main/claude-code-skills/code-reviewer Purpose: Code Reviewer Skill - Research-backed code review with OWASP 2025, SAST integration, and DevSecOps best practices Research Backing: - OWASP Code Review Guide 2025 - OWASP Top 10 2021 (Current Standard) - CWE Top 25 (2024) - Empirical Study: arxiv.org/html/2311.16396v2 (135,560 code reviews analyzed) - NIST Secure Software Development Framework - DevSecOps automation research (92% faster remediation with continuous review) -->

Code Reviewer Skill

Comprehensive code review skill implementing 2025 research-backed best practices with automated security checks, performance analysis, and quality standards enforcement.

Core Philosophy

Balanced Quality + Security Approach:

  • 50% Security focus (OWASP Top 10, vulnerabilities, authentication)
  • 30% Code quality (maintainability, standards, duplication)
  • 20% Performance (N+1 queries, algorithm complexity, bundle size)

Research Finding: Teams with continuous code review fix vulnerabilities 92% faster than traditional batch reviews.


When to Use This Skill

Auto-invoked when user mentions:

  • "review this code"
  • "check for bugs"
  • "security audit"
  • "analyze this PR"
  • "code review"
  • "check code quality"
  • "review my changes"
  • "find vulnerabilities"
  • "performance check"

Manual invocation:

  • Before committing critical changes
  • Pre-deployment validation
  • After implementing security-sensitive features
  • When integrating SAST tool results

Core Review Workflow

NEW TO CODE REVIEW? See EXAMPLES.md for complete walkthrough examples showing good vs bad reviews.

Phase 1: Automated Analysis (Run First)

Step 1: Identify Code to Review

  • If reviewing specific files: Read those files
  • If reviewing PR/changes: Use git diff to see changes
  • If reviewing entire feature: Identify affected files via grep/glob

Step 2: Run Automated SAST Tools (If Available)

Use the scripts in scripts/ directory:

# Quick security audit
bash scripts/quick-audit.sh

# Or run individual tools:
npm audit                    # Dependency vulnerabilities
npm run lint                 # ESLint code quality
npx prettier --check .       # Code formatting

# Advanced (if installed):
sonar-scanner               # SonarQube
codeql database analyze     # CodeQL
snyk test                   # Snyk security

Step 3: Parse SAST Results

  • Categorize findings by severity (Critical/High/Medium/Low)
  • Filter false positives (document reasoning)
  • Cross-reference with manual checks

Phase 2: Manual Security Analysis

Check OWASP Top 10 2021 (Current Standard):

  1. A01:2021 – Broken Access Control
    • Are authentication checks on all protected routes?
    • Is user input validated before authorization decisions?
    • Are direct object references protected (IDOR prevention)?
  2. A03:2021 – Injection (SQL, NoSQL, Command)
    • Are parameterized queries used instead of string concatenation?
    • Is user input sanitized before database queries?
    • Are ORMs used correctly (no raw queries with user input)?
  3. A03:2021 – Cross-Site Scripting (XSS)
    • Is user input escaped before rendering in HTML?
    • Are Content Security Policy headers configured?
    • Is dangerouslySetInnerHTML avoided or properly sanitized?
  4. A07:2021 – Identification and Authentication Failures
    • Are passwords hashed with bcrypt/argon2 (not MD5/SHA1)?
    • Is session management secure (httpOnly cookies, CSRF tokens)?
    • Is rate limiting implemented on login endpoints?
  5. A02:2021 – Cryptographic Failures
    • Is sensitive data encrypted at rest and in transit?
    • Are API keys/secrets stored in environment variables (not hardcoded)?
    • Is HTTPS enforced for all external communication?

See REFERENCE.md for complete OWASP Top 10 checklist

Phase 3: Performance Pattern Detection

Check for Common Performance Issues:

  1. N+1 Query Problem
    // 🔴 BAD: N+1 queries
    users.forEach(user => {
      db.query("SELECT * FROM posts WHERE user_id = ?", user.id)
    })
    
    // ✅ GOOD: Single query with JOIN
    db.query("SELECT * FROM users LEFT JOIN posts ON users.id = posts.user_id")
  2. O(n²) or Worse Algorithms
    • Nested loops over large datasets
    • Inefficient sorting/searching
    • Recursive functions without memoization
  3. Missing Database Indexes
    • Queries on unindexed columns
    • WHERE clauses without supporting indexes
    • JOIN operations on unindexed foreign keys
  4. Memory Leaks
    • Event listeners not cleaned up
    • Closures holding large objects
    • Unbounded caches
  5. Large Bundle Sizes
    • Importing entire libraries instead of specific functions
    • Unoptimized images
    • Missing code splitting

See REFERENCE.md for performance pattern catalog

Phase 4: Code Quality Standards

Check TypeScript/JavaScript Standards:

  • No any types without justification comment
  • Proper error handling (no empty catch blocks)
  • No console.log statements (use proper logging)
  • Functions < 50 lines (extract if larger)
  • Cyclomatic complexity < 10
  • No commented-out code
  • Import order follows convention (React → Third-party → Internal → Relative)

Check Naming Conventions:

  • Files: kebab-case (user-service.ts)
  • Components: PascalCase (UserProfile.tsx)
  • Functions/Variables: camelCase (getUserData)
  • Constants: UPPER_SNAKE_CASE (MAX_RETRIES)

See REFERENCE.md for complete standards checklist

Phase 5: Generate Review Report

Use templates from resources/templates/ to create structured output:

  • Comprehensive Review: Use resources/templates/code-review-report.md
  • Security Audit: Use resources/templates/security-review-template.md
  • Performance Review: Use resources/templates/performance-review-template.md
  • Quick Check: Use resources/templates/quick-checklist.md

Example report format:

# Code Review Report

**Verdict:** ✅ APPROVED | ⚠️ APPROVED WITH RESERVATIONS | ❌ REQUIRES REVISION
**Files Reviewed:** [List]
**Review Date:** [ISO Date]

## Critical Issues (Must Fix Before Merge)
[None or list with code snippets]

## High Priority Issues (Fix Within 48h)
[None or list with recommendations]

## Medium Priority Issues (Fix This Sprint)
[None or list]

## Low Priority / Suggestions
[Optional improvements]

## Strengths & Good Practices
[What was done well]

## Metrics
- **Lines Changed:** X
- **Files Modified:** Y
- **Estimated Risk:** Low/Medium/High
- **Test Coverage:** Z%

Integration with SAST Tools

SonarQube Integration

If SonarQube results available:

  1. Read sonar-report.json or access SonarQube API
  2. Focus manual review on issues SonarQube missed:
    • Business logic vulnerabilities
    • Context-specific security issues
    • Authorization logic
  3. Validate SonarQube findings (check false positives)

Key SonarQube Metrics to Review:

  • Security Hotspots: Require manual validation
  • Code Smells: Maintainability issues (threshold: Grade A or B)
  • Duplications: Keep < 3%
  • Coverage: Target > 80%

CodeQL Integration

If CodeQL scan available:

  1. Review CodeQL alerts in GitHub Security tab
  2. Prioritize alerts by severity:
    • Critical/High: Must fix before merge
    • Medium: Fix within sprint
    • Low: Backlog
  3. Use CodeQL's suggested fixes when available
  4. Manual review for:
    • Authentication flows
    • Authorization decisions
    • Cryptographic operations

CodeQL Strengths (88% accuracy):

  • SQL injection detection
  • Path traversal vulnerabilities
  • Command injection
  • Insecure deserialization

Snyk Integration

If Snyk results available:

  1. Run snyk test for dependency vulnerabilities
  2. Run snyk code test for code-level issues
  3. Prioritize by:
    • Critical: Fix immediately
    • High: Fix within 7 days
    • Medium: Fix within 30 days
  4. Check for available patches: snyk wizard

Snyk Strengths:

  • Dependency vulnerabilities (real-time CVE database)
  • License compliance
  • Container security
  • Infrastructure as Code (IaC) scanning

ESLint + Prettier + npm audit

Basic Security Stack (Always Run):

# Run these three commands ALWAYS
npm audit --audit-level=high    # Dependency vulnerabilities
npm run lint                    # Code quality (ESLint)
npx prettier --check .          # Code formatting

Interpretation:

  • npm audit: Fix all high/critical vulnerabilities
  • ESLint: Must pass with 0 errors (warnings acceptable if documented)
  • Prettier: Auto-fix with npx prettier --write .

Severity Classification

Use this framework to categorize all findings:

🔴 Critical (Blocks Deployment)

  • SQL injection vulnerabilities
  • XSS vulnerabilities (unescaped user input)
  • Authentication bypass
  • Hardcoded secrets/API keys
  • Remote code execution (RCE) risks
  • Sensitive data logged in plain text

Action: STOP. Must fix immediately before proceeding.

🟠 High (Fix Within 48 Hours)

  • Missing authentication checks
  • Insecure session management
  • CSRF vulnerabilities
  • Missing rate limiting on sensitive endpoints
  • Weak cryptography (MD5, SHA1)
  • N+1 query problems in critical paths
  • Memory leaks in production code

Action: Create blocker ticket. Fix before next deployment.

🟡 Medium (Fix This Sprint)

  • Missing input validation (non-critical fields)
  • Inefficient algorithms (O(n²) on small datasets)
  • Missing database indexes (< 1000 rows)
  • Code duplication (> 5 occurrences)
  • Missing error handling
  • Accessibility violations (WCAG AA)

Action: Create ticket. Fix within current sprint.

🔵 Low (Backlog / Nice-to-Have)

  • Code style violations (if not enforced by linter)
  • Missing comments on complex code
  • Minor performance optimizations
  • Refactoring opportunities
  • Documentation improvements

Action: Optional. Add to backlog for future improvement.


Key Metrics to Track

From 2025 Research:

  1. Mean Time to Remediate (MTTR)
    • Target: < 7 days for high severity issues
    • Critical issues: < 24 hours
  2. Defect Density
    • Formula: (# of bugs) / (1000 lines of code)
    • Target: < 1.0 defects per 1000 LOC
  3. Review Coverage
    • Target: 100% of changed lines reviewed
    • Critical paths: 100% manual review (not just automated)
  4. False Positive Rate
    • CodeQL: ~5% (best in class)
    • SonarQube: ~8-10%
    • Snyk: ~8%
    • Track your project's rate to calibrate trust

Common Pitfalls to Avoid

  1. Over-reliance on Automation
    • Automated tools catch 60-70% of security issues
    • Manual review essential for business logic, authorization, context-specific issues
  2. Ignoring Performance for Security
    • A secure but unusable app is not secure (DoS via performance)
    • Balance security checks with performance impact
  3. Blocking Every Minor Issue
    • Use severity classification to prioritize
    • Don't let perfection block progress
  4. Missing the Forest for the Trees
    • Step back and review overall architecture
    • Check if the approach is fundamentally sound
  5. Not Checking Test Coverage
    • Untested code = unreviewed code
    • Require tests for all security-critical paths

Quick Reference Checklist

Before approving any code review:

Security:

  • No SQL injection vulnerabilities (parameterized queries)
  • No XSS vulnerabilities (user input escaped)
  • Authentication checks on protected routes
  • Secrets in environment variables (not hardcoded)
  • HTTPS enforced for external APIs
  • CSRF protection on state-changing endpoints

Performance:

  • No N+1 query patterns
  • No O(n²) or worse algorithms on large datasets
  • Database indexes present for queried columns
  • No memory leaks (event listeners cleaned up)
  • Images optimized and lazy-loaded

Code Quality:

  • TypeScript strict mode compliance (no any without justification)
  • Error handling present (no empty catch blocks)
  • No console.log statements
  • Functions < 50 lines
  • Test coverage > 80%
  • No commented-out code

Documentation:

  • Complex logic has explanatory comments
  • Public APIs have JSDoc comments
  • README updated if behavior changed
  • Environment variables documented

Next Steps After Review

If APPROVED (✅):

  1. Merge the PR
  2. Monitor deployment for issues
  3. Update test coverage metrics

If APPROVED WITH RESERVATIONS (⚠️):

  1. Create tickets for medium/low priority issues
  2. Merge if critical/high issues are fixed
  3. Schedule follow-up review

If REQUIRES REVISION (❌):

  1. Provide detailed feedback with code snippets
  2. Block merge until critical issues resolved
  3. Offer to pair-program on fixes if needed

Supporting Files

For detailed information, see:

  • EXAMPLES.md - Complete end-to-end code review examples (good, bad, security-focused)
  • REFERENCE.md - Complete OWASP Top 10 checklist, performance patterns, CWE references
  • FORMS.md - Review report templates overview and guidance
  • resources/templates/ - Ready-to-use review templates
    • code-review-report.md - Comprehensive review template
    • security-review-template.md - Security-focused audit template
    • performance-review-template.md - Performance analysis template
    • quick-checklist.md - 3-minute rapid review checklist
  • resources/examples/ - Real-world review examples
    • good-review-example.md - What a thorough review looks like
    • bad-review-example.md - What to avoid (rubber stamp reviews)
  • scripts/ - Automated SAST tool integration scripts
    • quick-audit.sh - Quick security audit (Linux/Mac)
    • quick-audit.bat - Quick security audit (Windows)

Research Citations:


Remember: Code review is not about finding fault—it's about ensuring quality, security, and maintainability. Be constructive, specific, and always suggest solutions alongside identifying problems.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.