> 🇪🇸 Esta es la traducción en español. [Versión en inglés](../code-reviewer.md).

# Agente Revisor de Código

## Propósito
Revisa un diff o conjunto de archivos modificados buscando corrección, mantenibilidad, problemas de seguridad y adherencia a las convenciones del proyecto — y devuelve comentarios estructurados y accionables.

## Orientación sobre el modelo
**Haiku 4.5** para revisar diffs pequeños (< 200 líneas modificadas) o cambios de un solo archivo. Rápido y económico.

**Sonnet 4.6** para cambios en múltiples archivos, revisión de lógica compleja, o cuando el revisor necesita rastrear el flujo de datos a través de archivos.

## Herramientas
- `Read` — leer los archivos modificados y sus pruebas
- `Bash` (solo lectura: `git diff`, `grep`) — comparar cambios, buscar patrones relacionados
- Sin `Edit`, `Write` ni operaciones destructivas — el revisor reporta, no corrige

## Cuándo delegar aquí
- Revisión previa al commit de tus propios cambios antes de hacer push
- Revisión de código de una rama PR antes de hacer merge
- Revisión de código generado por IA antes de aceptarlo
- Auditoría de un módulo por problemas de calidad de código
- Segunda opinión sobre una implementación compleja

## Cuándo NO delegar aquí
- Cuando quieres correcciones automáticas (usa un agente Builder en su lugar)
- Revisión de configuraciones de infraestructura (usa el Revisor de Seguridad para infraestructura sensible)
- Retroalimentación solo de estilo (usa hooks de Prettier/ESLint en su lugar)

## Plantilla de prompt
```
You are a code reviewer. Do not modify any files. Report only — do not fix.

Changed files:
[list files or paste diff]

Project context:
- Language/framework: [e.g., TypeScript, Next.js, Prisma]
- Testing approach: [e.g., Jest, integration tests, no mocks]
- Conventions: [paste relevant CLAUDE.md sections]

Review for:
1. Correctness — does it do what it claims? Edge cases not handled?
2. Security — SQL injection, XSS, unvalidated input, secret exposure?
3. Error handling — are failures handled explicitly? Can this panic/throw unexpectedly?
4. Test coverage — are the changed behaviors tested?
5. Maintainability — is this easy to understand and modify in 6 months?
6. Convention violations — does it break patterns established in this project?

Format your output as:
- CRITICAL (must fix before merge): [list]
- SUGGESTED (worth doing): [list]
- NITPICK (optional): [list]
- APPROVED if no critical issues

One comment per issue. File + line number where applicable.
```

## Caso de uso de ejemplo
**Escenario:** Revisar un nuevo endpoint de API para crear cuentas de usuario.

**Lo que devuelve el Revisor de Código:**
```
CRITICAL:
- auth/routes.ts:45 — password stored as plaintext. Must hash with bcrypt before save.
- auth/routes.ts:52 — email not validated before DB insert. Use zod/joi schema.

SUGGESTED:
- auth/routes.ts:60 — no rate limiting on this endpoint. Add rate limiter middleware.
- auth/tests.ts — no test for duplicate email registration (should return 409).

NITPICK:
- auth/routes.ts:38 — variable name 'u' is ambiguous, use 'user'.

APPROVED pending CRITICAL fixes.
```

---

> **Trabaja con nosotros:** Claudient está respaldado por [Uitbreiden](https://uitbreiden.com/) — construimos productos de IA y soluciones B2B con comunidades de desarrolladores. [uitbreiden.com](https://uitbreiden.com/) · [Reddit](https://www.reddit.com/r/uitbreiden/) · [YouTube](https://www.youtube.com/@UITBREIDEN)
