Las skills de Claude Code son archivos Markdown que le enseñan a Claude un procedimiento repetible. Se guardan en .claude/skills/<nombre>/SKILL.md y se llaman con /<nombre>, o Claude las usa sola cuando tu pedido coincide con su description.
Esta es la skill de revisión de código que uso a diario, completa y gratis para copiar.
La skill
Guárdala como .claude/skills/revisar/SKILL.md en tu repo (o en ~/.claude/skills/revisar/SKILL.md para tenerla en todos):
---
name: revisar
description: "Revisa el diff actual (o una rama) buscando bugs, problemas de seguridad y deuda, y entrega hallazgos priorizados. Úsala cuando el usuario pida \"revisa\", \"code review\" o \"qué opinas de estos cambios\"."
---
# Revisión de código
1. Obtén el diff: `git diff` + `git diff --staged`, o `git diff <base>...HEAD` si el usuario nombra una rama.
2. Lee el contexto necesario de cada archivo tocado (no solo las líneas del diff).
3. Busca, en este orden:
1. **Correctitud**: casos borde, null/undefined, async sin `await`, condiciones de carrera, off-by-one, manejo de errores que traga excepciones.
2. **Seguridad**: inyección (SQL, comandos, XSS), secretos en código, validación de entrada, autorización faltante en resolvers/endpoints, datos sensibles en logs.
3. **Datos y API**: migraciones irreversibles, cambios incompatibles de contrato (REST/GraphQL), N+1 en resolvers.
4. **Rendimiento**: renders innecesarios en React, efectos sin dependencias correctas, consultas en bucles.
5. **Mantenibilidad**: duplicación, nombres confusos, código muerto, tests faltantes para la lógica nueva.
4. Entrega una tabla ordenada por severidad:
| Sev. | Archivo:línea | Problema | Sugerencia |
|------|---------------|----------|------------|
| 🔴 alta / 🟡 media / ⚪ menor | ... | ... | ... |
5. Solo reporta lo que puedas justificar con un escenario concreto. Si no encuentras nada serio, dilo. No apliques cambios salvo que el usuario lo pida.
Tres detalles la hacen mejor que escribir "revisa mi código":
- Lee el archivo completo, no solo el diff. La mayoría de bugs reales están en cómo las líneas nuevas interactúan con las que no cambiaron.
- Un orden fijo. Correctitud y seguridad van antes que estilo, así lo importante no queda enterrado bajo comentarios de nombres.
- "Solo reporta lo que puedas justificar con un escenario concreto." Esa línea elimina casi todos los consejos genéricos que suelen dar las revisiones con IA.
Una prueba real
Armé un repo de prueba con un refactor de autenticación que mete tres fallos a propósito: un bypass de auth, el secreto JWT impreso en los logs y una inyección SQL. Lo pasé por la versión en inglés de esta misma skill (mismo contenido, traducido) en Claude Code 2.1.293.
Resultado: encontró los tres fallos, los puso primero como 🔴 alta, explicó para cada uno cómo se explota (por ejemplo, que Authorization: Bearer basura pasaba el middleware porque req.user = null seguía llamando a next()) y propuso el arreglo concreto (return res.status(401) antes de next(), consulta parametrizada con $1, borrar el console.log del secreto). No tocó el código, porque la skill dice que no lo haga salvo que se lo pidas.
Adáptala
- Agrega a la lista del paso 3 los errores típicos de tu stack (por ejemplo, "falta
keyen listas de React", "consultas GraphQL sin límite"). - Si quieres que se active sin escribir
/revisar, pon en ladescriptionlas frases que usas de verdad ("mira mis cambios", "¿algo mal aquí?"). - Mantén la tabla de severidad: se lee rápido y se pega tal cual en un PR.
Si te sirve, el Kit de Claude Code en español (US$9, no oficial) trae 5 skills más en el mismo estilo (/commit, /pr, /tests, /plan, /depurar), hooks de seguridad que bloquean rm -rf, force-push y secretos filtrados (con 27 tests), plantillas de CLAUDE.md para React, Node y GraphQL, y presets de permisos: https://luijhy.gumroad.com/l/kit-claude-code-es
Los hooks de seguridad solos están gratis aquí: https://github.com/kailucho/claude-code-hooks-seguridad
Top comments (2)
Lo primero que ajustaría es el paso 1. git diff muestra solo cambios en archivos que git ya sigue, y git diff --staged solo lo que agregaste con git add. Un archivo nuevo que todavía no agregaste, por ejemplo un middleware de auth recién creado, no aparece en ninguno de los dos, así que la skill lo revisa solo si Claude decide abrirlo por su cuenta.
Lo cerraría sumando git status --porcelain al paso 1 y pidiendo que lea completo cada archivo marcado con
??. También probaría la skill con un diff limpio, además del repo con tres fallos. La regla de "solo reporta lo que puedas justificar" se mide mejor cuando no hay nada que encontrar, porque ahí se ve si la tabla sale vacía o si aparecen hallazgos para llenarla."Solo reporta lo que puedas justificar con un escenario concreto" is the best line in this article, and I wish more code review tools had it.
Most AI reviews I've seen produce 20 findings, 15 of which are "this could be a bug in some edge case" or "consider refactoring this". They bury the real issues under noise.
Curious how you handle the case where the model can justify a finding but the justification is wrong (e.g., it invents an attack path that doesn't exist in your architecture). Does the skill have a "second pass" where the model verifies its own findings?