keykovar/skill-fe-code-review

Revisión de Código Frontend (FE Code Review)

Reglas Predeterminadas

• Usa el idioma del usuario. Si el usuario escribe en español, responde en español.
• Traduce los encabezados de secciones, etiquetas de estado y recomendaciones al idioma del usuario. Mantén las etiquetas en inglés cuando sea útil, por ejemplo Bloqueante: Debe modificarse.
• Para solicitudes en español, usa la plantilla en español para el modo seleccionado. No uses encabezados de sección solo en inglés como Overall Conclusion, Review Scope, Test Gaps o Final Recommendation.
• Por defecto, la revisión es de solo lectura.
• No modifiques archivos, formatees archivos, hagas commit, push, reset, instales paquetes, cambies de rama ni ejecutes comandos destructivos a menos que el usuario lo solicite explícitamente.
• Una solicitud para revisar, evaluar la calidad de la revisión o generar un informe de revisión autoriza únicamente la salida en el chat. No crees ni actualices archivos de informe, plan, lista de tareas, Markdown o archivos de código a menos que el usuario solicite explícitamente ese artefacto de archivo o cambios de código. Los modos de cliente llamados Agente, Construir, Escribir o similares no anulan este límite.
• Basa los hallazgos en código real, diffs, rutas de llamadas, flujo de datos, versiones de paquetes y contratos de ejecución.
• No infieras semántica solo a partir de los nombres.
• No presentes la inspección estática como verificación en tiempo de ejecución.
• No informes problemas vagos. Explica la condición desencadenante, el impacto, la causa raíz, la corrección sugerida y el método de verificación.
• Si no se encuentra un problema claro, dilo directamente y enumera los riesgos residuales o las áreas no verificadas.

Descubrimiento del Alcance

Inspecciona el alcance solicitado. Si el usuario no especifica uno, revisa todos los cambios no confirmados. Recopila el inventario una sola vez.

Cuando el alcance solicitado son todos los cambios no confirmados, scripts/collect-review-context.mjs está disponible dentro del límite autorizado del Skill/workspace y Node.js está disponible, ejecútalo en lugar de emitir comandos de inventario de Git por separado:

node <directorio-del-skill>/scripts/collect-review-context.mjs --workspace "$PWD"

El script es de solo lectura y devuelve la raíz del repositorio, HEAD, estado, estadísticas y parches no preparados, parches preparados, archivos no rastreados, git diff --check y la presencia de CodeGraph. Siempre recopila el árbol de trabajo no confirmado completo. No lo ejecutes para revisiones solo de área de preparación, commit, commit de fusión, rama, PR, rango o ámbito de ruta, porque leería cambios fuera del alcance solicitado. Usa los comandos de Git delimitados coincidentes para esos alcances. Para una revisión de todo lo no confirmado, reutiliza la salida del recopilador y no vuelvas a ejecutar comandos equivalentes. Si el script no se puede ejecutar dentro del límite autorizado, recopila la misma evidencia manualmente en un lote de solo lectura cuando el cliente lo admita:

git status --short
git diff --stat
git diff --find-renames
git diff --cached --find-renames
git ls-files --others --exclude-standard

Establece e informa la línea base de comparación antes de revisar:

• Cambios no confirmados: HEAD versus el árbol de trabajo, incluidos los archivos preparados, no preparados y no rastreados relevantes.
• Cambios preparados (staged): HEAD versus el índice.
• Commit: su padre versus el commit.
• Rama o PR: base de fusión versus el destino, a menos que el usuario especifique otro rango.
• Commit de fusión: primer padre versus el commit de fusión, a menos que el usuario especifique otro padre o línea base.

Si los archivos de paquete o configuración cambiaron, inspecciona el impacto en las dependencias y la compilación. Siempre resume el alcance solicitado, la línea base de comparación, los archivos modificados, los archivos preparados, los archivos no preparados, los archivos no rastreados y los comandos de validación que se ejecutaron o omitieron.

Para la Revisión de Corrección, también identifica el informe de revisión o los hallazgos anteriores y el diff de la corrección. Mantén el rango de características original separado del rango de corrección posterior.

Si .codegraph/ existe en la raíz del repositorio y CodeGraph está disponible, úsalo antes de búsquedas amplias con grep/find para comprender símbolos, rutas de llamadas y el radio de explosión.

Usa la evidencia en este orden:

1. Código fuente del repositorio, diffs, rutas de llamadas, pruebas, configuración, archivos de bloqueo y documentación del proyecto.
2. Tipos de dependencias instaladas y fuente para la versión local resuelta.
3. Documentación oficial a través de un canal cuyo contrato de herramienta permita la revisión de código, solo cuando el comportamiento de una biblioteca o framework sensible a la versión aún no se pueda establecer localmente.

El contrato actual de la herramienta oficial Context7 MCP excluye la revisión de código. No uses Context7 mientras realizas esta habilidad, directa o indirectamente. Esto incluye pedirle a un subagente, delegado, proxy, envoltorio u otra herramienta o sesión que lo llame en nombre de la revisión. No eludas la restricción reformulando, descomponiendo, sanitizando o reetiquetando el trabajo de revisión como una pregunta de documentación. Si una conclusión depende de semántica externa y no hay una fuente autorizada y permitida disponible, márcala como No se puede verificar e identifica la evidencia faltante.

Al usar cualquier servicio de documentación externo, envía solo la biblioteca pública, versión, API o pregunta de comportamiento sanitizado necesaria para la verificación. Nunca envíes código fuente privado, diffs, rutas de repositorio, datos internos de API, credenciales, tokens, datos de usuario o identificadores propietarios.

Evidencia Condicional de Ejecución en Navegador

Usa Playwright u otra herramienta de automatización del navegador disponible solo cuando se cumplan todas estas condiciones:

• El comportamiento modificado es observable en el navegador y la evidencia de ejecución puede confirmar o refutar materialmente un hallazgo, como enrutamiento, formularios, estado de UI asíncrona, comportamiento de almacenamiento o cookies, hidratación, enfoque, desplazamiento, desbordamiento responsivo o ordenamiento de solicitudes.
• Existe un punto de entrada concreto, como una ruta local, URL, interacción o caso de prueba, y el resultado observable esperado es explícito a partir del requisito, el comportamiento de línea base o un contrato de prueba existente.
• Un entorno de prueba local o aislado adecuado ya se puede ejecutar sin instalar dependencias, cambiar la configuración del proyecto o escribir artefactos generados en el repositorio.
• El estado inicial es controlado y repetible, o se puede reconstruir antes de cada ejecución sin depender de datos de producción o una cuenta real.
• La ruta está aislada y se puede ejercitar sin acceso a producción, pagos reales, datos de usuario reales, acciones destructivas o efectos secundarios externos irreversibles.

Mantén la verificación del navegador como de solo lectura con respecto al repositorio, los sistemas de producción y las cuentas reales. El estado aislado del navegador local puede cambiar cuando el escenario lo requiera, pero restablécelo cuando sea práctico y no trates ese cambio de estado como verificación de datos del producto.

Registra el entorno, el tipo de URL, el punto de entrada, el navegador y la ventana gráfica, el estado inicial y cómo se reproduce, el resultado esperado, las acciones, el resultado observado y el resumen relevante de la consola o la red. Enmascara credenciales, tokens, datos personales, cuerpos de solicitud y contenido de respuesta sensible. Si se requiere evidencia de ejecución pero no se cumple la condición, usa No se puede verificar y menciona el entorno, estado, expectativa o capacidad no disponible.

La automatización del navegador solo prueba la ruta ejercitada en el entorno registrado. Una comprobación de navegador exitosa no prueba el comportamiento en todos los navegadores o ventanas gráficas y no reemplaza la verificación real de WebView, puente nativo, dispositivo, backend, implementación, monitoreo o producción.

Selección de Modo

• Usa la Revisión Rápida por defecto para cambios diarios, PRs pequeños, correcciones de errores y refactorizaciones locales.
• Usa la Revisión Profunda para pagos, autenticación, enrutamiento/navegación, puente WebView, RTC/audio/video, SSR/hidratación, i18n, estado global/almacenamiento, caché/persistencia, configuración de compilación/implementación, actualizaciones de dependencias, módulos compartidos, código sensible al rendimiento, ramas de lanzamiento, comportamiento entre módulos o refactorizaciones grandes.
• Usa la Revisión de Corrección cuando el usuario solicite volver a revisar correcciones, verificar hallazgos anteriores, comprobar si los comentarios de revisión se resolvieron o detectar regresiones introducidas por las correcciones.

Carga exactamente una referencia de modo antes de revisar:

• Revisión Rápida: references/quick-review.md
• Revisión Profunda: references/deep-review.md
• Revisión de Corrección: references/fix-review.md

Para la Revisión de Corrección, usa los hallazgos anteriores de la conversación actual cuando estén disponibles. De lo contrario, solicita al usuario que proporcione el informe de revisión anterior, la lista de problemas o una ruta legible. No inventes hallazgos anteriores ni afirmes que un problema está resuelto sin una línea base utilizable.

Detección de Tecnología

Inspecciona los archivos del proyecto y carga solo las referencias coincidentes:

• React: carga references/react.md para React, React DOM, Next.js, Remix, JSX/TSX o hooks.
• Vue: carga references/vue.md para Vue, Nuxt, Pinia, archivos .vue o Composition API.
• TypeScript: carga references/typescript.md para proyectos TypeScript o contratos TypeScript modificados.
• JavaScript: carga references/javascript.md para proyectos JavaScript o código con mucho peso en la forma de ejecución.
• Híbrido/WebView: carga references/hybrid-webview.md para puentes, contratos nativos, WebView, shell de aplicación, almacenamiento, teclado, área segura, audio o video.
• Riesgo de lanzamiento: carga references/release-risk.md para Revisión Profunda, ramas de lanzamiento, indicadores de características, implementación, monitoreo, reversión o flujos de alto riesgo.

Disciplina de Evidencia para Revisión Rápida/Corrección

Aplica estas reglas de ejecución requeridas a la Revisión Rápida y la Revisión de Corrección. Reducen la exploración repetida sin reducir la cobertura requerida:

• Usa un viaje de ida y vuelta de solo lectura y acotado por grupo de evidencia cuando el cliente admita el procesamiento por lotes: archivos de Skill/referencia seleccionados; recopilador de contexto inicial o su alternativa manual; fuente modificada y línea base más búsquedas de consumidores directos; y validación aplicable restante. Divide un grupo solo para evitar un resultado demasiado grande o cuando el primer resultado expone un nuevo contrato no resuelto. No concatenes archivos grandes no relacionados simplemente para reducir el número de comandos.
• Congela y reutiliza el inventario Git inicial. En una revisión de solo lectura, no repitas consultas de estado, nombre-estado, estadísticas, diff preparado, archivos no rastreados o diff sin cambios al final. Un evaluador anfitrión, no el modelo revisor, realiza cualquier comparación de integridad posterior a la ejecución independiente.
• Lee cada instrucción seleccionada, diff, archivo de línea base y rango de código fuente superpuesto una vez. Prefiere una lectura numerada por línea que cubra el rango necesario. Antes de cualquier lectura o búsqueda repetida, identifica la pregunta de evidencia no resuelta específica; omite el comando cuando la salida existente ya lo responda.
• Una vez que se conocen los archivos modificados y las rutas afectadas directamente, no realices búsquedas amplias de rg desde . o un inventario de archivos del repositorio sin filtrar con rg --files. Limita las búsquedas al propietario modificado, los símbolos nombrados y las rutas directamente afectadas; expande solo cuando una coincidencia concreta exponga otro consumidor o contrato.
• Detecta la tecnología a partir de los tipos de archivos modificados, importaciones y, como máximo, una lectura de manifiesto relevante. Inspecciona la configuración de paquetes, bloqueo, compilación o TypeScript en mayor profundidad solo cuando haya cambiado o cuando un hallazgo dependa de su versión resuelta o contrato de compilador/compilación. No investigues configuración o archivos de bloqueo ausentes solo para completar una lista de verificación genérica.
• Busca una vez las pruebas directamente relevantes usando rutas que se sabe que existen o una consulta de glob de nombre de archivo acotada. Si esa búsqueda no establece ninguna prueba aplicable, registra la brecha; no vuelvas a intentar con nombres de directorio de prueba adivinados o patrones alternativos en todo el repositorio sin nueva evidencia.
• Combina expresiones independientes o comprobaciones deterministas que ejerciten el mismo contrato de comportamiento en un viaje de ida y vuelta de validación. No vuelvas a ejecutar el diff solo para preparar la explicación final.
• Cuando el usuario o evaluador declare explícitamente que un HEAD sintético representa la línea base del problema original, verifica el HEAD actual y el diff de corrección, luego usa esa línea base declarada. Registra los objetos de commit original no disponibles como un límite de evidencia en lugar de sondear cada objeto cuando el cierre no dependa de ellos.
• Continúa más allá de estos grupos siempre que haya conflicto de evidencia, una condición modificada permanezca sin clasificar, un contrato directamente afectado no esté resuelto o un hallazgo aún carezca de su desencadenante e impacto. Estas son reglas de integridad, no un límite estricto de comandos o tokens.
• Deja de explorar cuando la línea base y el diff solicitados estén establecidos, cada entrada del libro de condiciones modificadas en el alcance esté contabilizada, cada hallazgo informado tenga suficiente evidencia, la validación requerida esté completada o explícitamente acotada, y el contrato de salida seleccionado se pueda completar de manera consistente. No amplíes las búsquedas simplemente para aumentar la confianza subjetiva.

Análisis de Comportamiento Antes/Después

Realiza este análisis en todos los modos. Compara el comportamiento, no solo las líneas modificadas:

1. Identifica el comportamiento antes del cambio y el comportamiento deseado después.
2. Detecta comportamiento eliminado, debilitado o preservado involuntariamente.
3. Verifica ramas faltantes, guardas, alternativas, limpieza, cancelación, reintentos y manejo de errores.
4. Antes de priorizar los hallazgos, construye un libro de condiciones modificadas interno y compacto para cada condición, guarda, alternativa, valor predeterminado y retorno temprano que se haya agregado, cambiado, movido, dividido o retenido dentro de un bloque de decisión modificado en el diff solicitado. Una guarda textualmente sin cambios permanece en el alcance cuando su flujo de control circundante, comportamiento de retorno o escrituras de estado cambiaron. Compara qué valores de ejecución toman cada rama antes y después; no generes el libro por defecto.
5. En ese libro, distingue la ausencia (null o undefined) de valores falsy válidos como 0, false o una cadena vacía. Para escrituras de estado detrás de esas ramas, rastrea las transiciones desde un valor truthy o no vacío anterior a cada valor falsy válido a través de los consumidores directamente afectados; no inspecciones solo el valor actual de forma aislada.
6. Contabiliza cada entrada del libro antes de finalizar: clasifícala como preservación de comportamiento, una brecha de evidencia o un hallazgo. Usa preservación de comportamiento solo después de verificar que el comportamiento preservado en sí mismo sigue siendo correcto para el contrato de ejecución visible y las transiciones de estado. Si un bloque de decisión modificado retiene un defecto material, repórtalo e identifícalo como un defecto retenido en lugar de una regresión introducida por el diff. No omitas una condición modificada afectada simplemente porque otro hallazgo tiene mayor severidad.
7. Rastrea los llamadores, consumidores, eventos, contratos de API, almacenamiento, caché y formas de datos de ejecución afectados.
8. Confirma el comportamiento...