Jump to

Skill · Code review for web

Code review for web.

Review and debug for the patterns that actually break production.

Review and debug web application code with a focus on the patterns that actually break production. Every review covers five dimensions (correctness, security, performance, reliability, maintainability), with the depth set by the situation: a quick scan for a small PR, a full review for a major change, a deep dive for an incident.

Stack-agnostic principles, plus a catalog of the bug patterns that recur across stacks and a hypothesis-driven debugging workflow for when production is on fire.

Audience: engineers reviewing a PR before merge, debugging a production issue, investigating a build failure, or auditing existing code for security and quality.

View the skill on GitHubBrowse the full catalog

The framework

Five dimensions, depth set by the situation.

Every review covers all five. Pick the depth: a quick scan for a small PR, a full pass for a major change, a deep dive for an incident.

  1. 01Correctness: does the code do what it claims? Logic matches intent, edge and error cases handled, no off-by-one or async races, tests exist, and no regression risk to existing functionality.
  2. 02Security: secrets never in client code or version control, auth checked on every mutation, input validated, CSRF protection and rate limits on public mutations, and server-only secrets kept out of the client bundle.
  3. 03Performance: no N+1 queries, large result sets paginated, an appropriate cache strategy, justified client dependencies, optimized images, and slow work moved off the request path.
  4. 04Reliability: errors caught and logged with context rather than swallowed, retries on transient network calls, explicit timeouts, graceful degradation, and idempotent mutations.
  5. 05Maintainability: names that say what the code does, comments that explain why, small single-purpose functions, no duplication, justified dependencies, and named constants over magic values.

What recurs across stacks

Six families of production bug.

These patterns recur across stacks and are worth checking on every review, because they are the ones that reach production.

  1. 01

    Build and deploy

    Build-time data fetches that timeout at scale, environment variables that work locally but were never added to production, and preview-versus-production env mismatches.

  2. 02

    URL and domain

    A canonical pointing at a staging or preview URL, an API URL that loops back after a DNS cutover, and mixed-content HTTPS issues.

  3. 03

    Cache invalidation

    Stale content after a deploy, a CDN serving an old asset under the same filename, and cache headers too aggressive for content that changes.

  4. 04

    Database and data

    N+1 queries, a missing LIMIT on a large-table scan, connection-pool exhaustion from parallel build-time fetches, and a migration without a backfill.

  5. 05

    External integrations

    Bot mitigation blocking legitimate server-to-server calls, and an API rate limit that only trips at production traffic.

  6. 06

    Security

    Unprotected revalidation or admin endpoints, PII in URLs that lands in logs and referrers, and secrets exposed in the client bundle.

Reference files

Three references that go alongside the SKILL.md.

  • references/review-template.md

    A markdown template for formal code reviews.

  • references/nextjs-patterns.md

    Stack-specific patterns for Next.js: App Router, ISR, Server Components, and common bugs.

  • references/wordpress-headless-patterns.md

    Stack-specific patterns for headless WordPress integrations.

Browse all reference files on GitHub

Bridges to other skills

When the goal is not the code itself.

Code review reads the source. These cover the spec before it, the running-site checks beside it, and the deep single-dimension passes.

  • Before the code

    pm-spec-writing

    Writing the feature spec comes first; code review checks the implementation against it. The spec defines what to build, the review checks how it was built.

  • The running site

    qa-testing

    Pre-launch QA verifies the rendered, running site. Code review reads the source for bugs the running checks would not catch, like a swallowed error or an exposed secret.

  • Core Web Vitals depth

    performance-optimization

    A review flags an N+1 query or an unoptimized image; the deep Core Web Vitals investigation is a performance job. The review spots it, that skill fixes it in depth.

  • WCAG depth

    accessibility-audit

    Deep accessibility compliance is its own audit. Code review covers correctness, security, and reliability; the WCAG pass is a dedicated review.

Open source under MIT

Read the SKILL.md on GitHub.

The skill source lives in the rampstackco/claude-skills repository alongside dozens of other skills covering the full lifecycle of brand and product work. This page is a structured overview; the SKILL.md is the source. MIT licensed.

View SKILL.mdBrowse the full catalog

Frequently asked questions.

What are the five review dimensions?
Correctness (does the code do what it claims), security (does it expose anything or open an attack surface), performance (will it scale and stay fast), reliability (what happens when it fails), and maintainability (will the next person understand it in six months). Every review covers all five, and the depth is set by the situation: a quick scan for a small PR, a full review for a major change, and a deep dive for a production incident.
What is the most common review failure?
'Looks good to me' on a 500-line PR. If a review of a large PR takes five minutes, the review did not happen. The other common traps are reviewing without running the code (some bugs only surface at runtime, so pull the branch and run it), over-indexing on style (bikeshedding formatting while missing logic bugs), skipping security review on 'internal' features (internal becomes external faster than expected), and treating build warnings as decoration, since they often become production errors after a dependency update.
How do I debug a production issue?
Read the full error message, including the whole stack trace, because the first line is often not the actual cause. Check the hosting build and function logs, where the exact failing line usually is. Identify the last working version, reproduce locally to confirm it is a code issue rather than an environment one, check environment variables (especially after a deploy or DNS change), and force a cache invalidation before concluding it is a code bug. Make the minimal fix, because big refactors during incidents create more incidents, then verify in production rather than trusting that the deploy succeeded.
What are the common web bug patterns?
Build-time data fetches that timeout at scale, environment variables that work locally but were never added to production, a canonical tag pointing at a staging or preview URL, stale content after a deploy because a cache was not invalidated, N+1 queries and connection-pool exhaustion, images not loading after an upload because the CDN cached the old filename, and secrets exposed in the client bundle. These recur across stacks, which is why the skill checks them on every review rather than waiting for them to surface in production.
How is this different from qa-testing and performance-optimization?
Code review reads the source for bugs, security issues, and stack-specific anti-patterns. QA testing verifies the rendered, running site after a deploy. Performance optimization is the deep Core Web Vitals investigation, and accessibility audit is the deep WCAG review. Use code review for the code itself; use the others for the running result, a specific metric, or a compliance standard. The review spots an unoptimized image or a missing label; the specialist skills take each finding the rest of the way.