Detalle del Skill

code-review-web

Code review focused specifically on web applications.

CoincidenciaPosibleRevisado para revisión de código
Fuenterampstackco/claude-skillsFuente externa
Instalaciones reportadas145Solo señal de popularidad

Revisar antes de usar

La revisión automática comprueba relevancia, no seguridad ni respaldo. Lee las instrucciones de la fuente antes de usar este Skill.

Vista previa guardada

SKILL.md

Este extracto es una copia guardada durante la revisión. La fuente externa contiene la versión completa y actual.

---
name: code-review-web
description: "Review web application code for bugs, security issues, performance problems, and stack-specific anti-patterns. Use this skill whenever the user wants to review code, debug a production issue, investigate a build failure, audit security, or check a PR before merging. Triggers on code review, review my code, debug, build error, broken, not working, why is X failing, check this code, security check, PR review, audit code, refactor. Also triggers when investigating 4xx or 5xx errors, deploy failures, environment variable issues, and CMS integration problems."
category: development
catalog_summary: "PR review, build error diagnosis, security and quality checks"
display_order: 1
---

# Code Review for Web

Review and debug web application code with a focus on the patterns that actually break production. Stack-agnostic principles in SKILL.md. Stack-specific patterns in references.

---

## When to use

- Reviewing a pull request before merging
- Debugging a production issue
- Investigating a build failure
- Auditing security or performance of existing code
- Investigating environment variable or configuration issues
- Triaging a "the site is broken" report

## When NOT to use

- Writing a new feature spec (use `pm-spec-writing`)
- Pre-launch QA against the running site (use `qa-testing`)
- Performance deep-dive on Core Web Vitals (use `performance-optimization`)
- Deep accessibility compliance review (use `accessibility-audit`)

---

## Required inputs

- The code, PR, error message, or symptom under review
- Access to logs (build logs, function logs, server logs) if debugging
- The stack (framework, hosting, database) - even at high level

If just a symptom is provided ("the site is broken"), the workflow's first step is gathering enough context to investigate.

---

## The framework: 5 review dimensions

Every code review covers five dimensions. Pick the depth based on the situation.

### 1. Correctness

Does the code do what it claims to do?

- Logic matches the intent stated in the spec or PR description
- Edge cases handled (empty states, error states, network failures)
- Off-by-one errors, null/undefined handling, async race conditions
- Tests exist for the change, or there's a reason they don't
- The change does not break existing functionality (regression risk)

### 2. Security

Does the code expose anything sensitive or open an attack surface?

- **Secrets handling.** No secrets, API keys, or service-role credentials in client-side code or version control
- **Auth checks.** Every mutation endpoint validates the caller before acting
- **Input validation.** User input sanitized before use in queries, file paths, or HTML
- **External requests.** Outbound URLs validated; no SSRF on user-controlled inputs
- **CSRF protection.** State-changing requests require a token or same-origin policy
- **Rate limiting.** Public-facing mutation endpoints have rate limits
- **HTTPS-only.** No HTTP in production code paths
- **Cookies.** Session cookies have `Secure`, `HttpOnly`, `SameSite` attributes set
- **Environment variables.** Server-only secrets are not prefixed with anything that exposes them to the client bundle

### 3. Performance

Will this code scale and stay fast?

- **Database queries.** No N+1 patterns. Joins or batch fetches preferred over loops with queries.
- **Pagination.** Large result sets paginated, never loaded entirely.
- **Caching.** Appropriate cache strategy for the data freshness needs.
- **Bundle size.** Client-side dependencies justified. Tree-shaking working.
- **Image handling.** Modern formats, lazy loading, explicit dimensions.
- **Background work.** Slow operations moved off the request path.
- **Cold start sensitivity.** Cold paths optimized if frequently triggered.

### 4. Reliability

What happens when this fails?

- **Error handling.** Caught and handled, not swallowed. Errors logged with context.
- **Retries.** Network calls have retry logic for transient failures.
Leer la fuente completa en GitHub (abre una página externa)
Contexto

Trabajo relacionado