Construir no termina cuando el código se ejecuta. Termina cuando el código es correcto.
La IA avanza rápido. Rápido significa que se construyen cosas que funcionan en la superficie pero se desvían de la arquitectura, violan el sistema de diseño, o pasan por alto casos límite que importan. Este skill atrapa esas cosas antes de que se conviertan en problemas mayores.
Ejecuta esto después de cada funcionalidad. Antes de seguir adelante.
Lo que este skill no hace
No arregla nada. Reporta lo que encuentra y permite al desarrollador decidir qué importa y qué hacer al respecto. Arreglar sin entender es cómo se entierran los problemas, no cómo se resuelven.
Paso 1 — Entender lo que debería haberse construido
Antes de revisar cualquier cosa, establece el punto de referencia.
Lee en este orden:
- El plan de implementación de
/architectsi existe - La descripción de la funcionalidad o tarea que se dio
- Los archivos de contexto relevantes — límites arquitectónicos, estándares de código, reglas de diseño
Si no existe un plan, pide al desarrollador que describa lo que se suponía que debía hacer la funcionalidad antes de revisar. No puedes verificar la corrección sin saber cómo se ve lo correcto.
Paso 2 — Revisar en tres capas
Capa 1 — ¿Coincide con el plan?
Compara lo que se construyó contra lo que se planeó.
Verifica:
- Cada parte de la descripción de la funcionalidad — ¿está todo presente?
- Las decisiones tomadas durante la planificación — ¿se reflejan en el código?
- El alcance — ¿la implementación se mantuvo dentro de los límites o añadió cosas que no se pidieron?
Marca cualquier cosa que estuviera planeada pero faltante. Marca cualquier cosa que se construyó pero no estaba planeada.
Capa 2 — ¿Respeta el sistema?
Aquí es donde ocurre más comúnmente la desviación de la IA. La funcionalidad funciona, pero viola reglas de las que depende el proyecto.
Verifica:
- Límites arquitectónicos — ¿el código en el lugar correcto tiene las responsabilidades correctas? Sin lógica de UI en rutas de API. Sin llamadas a BD en componentes. Sean cuales sean los límites del proyecto — ¿se respetan?
- Sistema de diseño — ¿se usan los tokens, clases y patrones correctos? ¿Hay valores hardcodeados que deberían ser variables? ¿Clases de color crudas que deberían usar el sistema de diseño?
- Estándares de código — convenciones de nombres, organización de archivos, rigor de TypeScript, patrones de manejo de errores — ¿coinciden con lo que el proyecto estableció?
- Patrones existentes — ¿esta funcionalidad introduce un nuevo patrón cuando debería haber usado uno existente?
Capa 3 — ¿Está lista para producción?
Verifica:
- Manejo de errores — ¿qué sucede cuando las cosas fallan? ¿Los errores se capturan y manejan o la funcionalidad falla silenciosamente?
- Casos límite — estados vacíos, estados de carga, datos faltantes — ¿se manejan?
- Errores de consola — ¿hay errores o advertencias en el navegador o terminal?
- Errores obvios — ¿algo que claramente se rompería para un usuario real?
Paso 3 — Reportar lo que encontraste
Después de completar las tres capas, produce un reporte claro. No entierres los problemas. No los suavices. Reporta honestamente para que el desarrollador pueda tomar decisiones informadas.
## Revisión — [Nombre de la funcionalidad]
### Capa 1 — Alineación con el plan
[APROBADO / PROBLEMAS ENCONTRADOS]
[Lista de diferencias entre lo planeado y lo construido]
### Capa 2 — Integridad del sistema
[APROBADO / PROBLEMAS ENCONTRADOS]
[Lista de violaciones de arquitectura, diseño o estándares de código]
### Capa 3 — Preparación para producción
[APROBADO / PROBLEMAS ENCONTRADOS]
[Lista de brechas en manejo de errores, casos límite o errores obvios]
### Resumen
[Se encontraron] [X] problemas en [Y] capa(s).
[Si no hay problemas: "No se encontraron problemas. Esta funcionalidad está lista para enviar."]
[Si hay problemas: "Resuelve lo anterior antes de pasar a la siguiente funcionalidad."]
Paso 4 — Dejar que el desarrollador decida
Después de presentar el reporte, detente. No empieces a arreglar. No sugieras correcciones a menos que el desarrollador lo pida.
Espera a que el desarrollador:
- Te pida arreglar un problema específico
- Te diga que un problema es intencional y se puede ignorar
- Confirme que todo está resuelto y listo para continuar
El desarrollador es dueño de la decisión de calidad. Tú la informas.
Guía de severidad
No todos los problemas son iguales. Usa esto para ayudar al desarrollador a priorizar:
Crítico — arreglar antes de continuar
- Violaciones de límites arquitectónicos que romperán funcionalidades futuras
- Falta de manejo de errores que causa fallas silenciosas
- Funcionalidad que estaba planeada pero completamente faltante
Importante — arreglar pronto
- Desviación del sistema de diseño que causará inconsistencia en la UI
- Violaciones de estándares de código que se acumularán en la base de código
- Casos límite que un usuario real encontrará
Menor — arreglar cuando sea conveniente
- Inconsistencias de nomenclatura que no afectan el comportamiento
- Optimizaciones faltantes
- Problemas de estilo que no afectan el sistema de diseño
Etiqueta cada problema con su severidad para que el desarrollador pueda priorizar rápidamente.
El estándar
La pregunta que este skill responde no es "¿funciona?"
La pregunta es "¿es correcto?"
Funcionar y ser correcto no son lo mismo. Una funcionalidad puede funcionar hoy y romper el proyecto mañana. La revisión existe para detectar la diferencia.