check

Descripción general de check skill

Qué hace check skill

check skill es un flujo de trabajo de revisión y validación para diffs de código, PRs, triage de issues, preparación de releases, pushes y auditorías de proyecto. Es ideal para quienes necesitan una respuesta rápida pero rigurosa a: “¿Esto es seguro para publicar, qué está roto y qué debo corregir antes de hacer merge?”

Mejor encaje para este skill

Usa check skill cuando necesites revisar un cambio concreto, ya sea antes de hacer merge, antes de un release o al validar artefactos generados y acciones de seguimiento. Es especialmente útil cuando quieres que el agente inspeccione primero el worktree, evite cambios locales ocultos y separe los problemas corregibles de los elementos que requieren confirmación humana.

Qué diferencia a check

check skill no es un prompt genérico de “mira este código”. Incluye barreras de seguridad explícitas para worktrees sucios o con archivos no rastreados, un flujo claro de revisión primero y enrutamiento a revisores especialistas cuando hay riesgos de arquitectura o seguridad. Eso lo hace más sólido que un prompt puntual para check for Code Review, porque reduce la incertidumbre sobre cuándo inspeccionar, qué inspeccionar y cuándo detenerse.

Cómo usar check skill

Instalar y activar check

Instálalo con:

npx skills add tw93/Waza --skill check

Luego invócalo cuando tengas un objetivo de revisión concreto: un diff, una rama, un PR, un candidato a release, un rango de commits o una solicitud de auditoría del repositorio. Para check usage, dale al agente un alcance específico, como “revisa los últimos 3 commits”, “comprueba este PR antes del merge” o “audita la preparación del release tras actualizar dependencias”.

Dale al skill la entrada correcta

La mejor entrada para check no es “¿esto está bien?”, sino una tarea acotada con contexto. Buenos ejemplos:

• “Comprueba este PR en busca de regresiones de seguridad y arquitectura antes del merge.”
• “Revisa el worktree actual y dime qué bloquea el release.”
• “Audita los archivos generados y dime si coinciden con los cambios en el código fuente.”

Incluye la rama, el rango de commits, el release previsto y cualquier restricción como “no modifiques archivos” o “inspecciona solo el contexto público del repo”. Eso ayuda al skill a evitar un comportamiento de revisión amplio y difuso.

Lee primero estos archivos

Empieza por SKILL.md y luego revisa references/project-context.md y references/persona-catalog.md para entender la profundidad de la revisión, el enrutamiento a especialistas y las expectativas de release. Usa agents/reviewer-security.md y agents/reviewer-architecture.md cuando el diff afecte límites de confianza, APIs, imports o la estructura de módulos. references/public-reply.md es importante cuando el flujo incluye seguimiento con mantenedores sobre issues o PRs.

Consejos prácticos de flujo de trabajo

Antes de revisar, el skill espera una comprobación de seguridad del worktree con git status --short --branch -uall. Eso importa porque los cambios sucios o no rastreados pueden alterar el significado de la revisión. Si quieres un mejor resultado con check guide, dile al agente si solo debe informar hallazgos, si puede corregir problemas seguros y qué comando de verificación debe usarse después de los cambios.

Preguntas frecuentes sobre check skill

¿check solo sirve para revisión de código?

No. check skill también cubre preparación de releases, pushes, artefactos publicados, triage de issues y PRs, y auditorías de todo el proyecto. Encaja mejor que un prompt normal cuando la tarea incluye juicio de “antes de publicar”, no solo lectura de código.

¿Cuándo no debería usar check?

No uses check para exploración abierta de ideas, depuración de causa raíz o edición de texto. El skill está diseñado para diffs concretos y revisión operativa, no para lluvia de ideas ni feedback narrativo.

¿check es apto para principiantes?

Sí, si puedes nombrar el objetivo y el resultado esperado. Los principiantes obtienen mejores resultados cuando dicen exactamente qué cambió, qué quieren que se revise y si desean solo hallazgos o también correcciones seguras. Sin eso, check install puede ser fácil, pero check usage se vuelve demasiado amplio para ser fiable.

¿En qué se diferencia de un prompt normal?

Un prompt normal suele pedir una revisión subjetiva. check añade un recorrido disciplinado: preflight de seguridad, control de alcance, expectativas de verificación y enrutamiento a especialistas para seguridad o arquitectura. Eso lo hace más fiable para check for Code Review que una solicitud de revisión improvisada.

Cómo mejorar check skill

Prepara un brief de revisión más preciso

Las entradas más útiles son: qué cambió, por qué cambió, qué no debe romperse y qué tipo de revisión quieres. Por ejemplo: “revisa solo la ruta de autenticación”, “céntrate en los artefactos de release” o “comprueba si este refactor cambia las APIs públicas”. Eso acota la búsqueda y mejora la señal.

Expón las restricciones difíciles

Cuéntale al skill las reglas de empaquetado, los archivos generados, las rutas protegidas y los comandos de verificación obligatorios. Si el repo tiene una fuente de verdad para build o release, menciónala desde el principio. Eso reduce la falsa confianza y ayuda a check skill a detectar desajustes, artefactos faltantes o seguimientos inseguros.

Itera a partir de hallazgos, no de elogios

Después de la primera pasada, responde con los hallazgos exactos que quieres que se vuelvan a comprobar o con el parche que aplicaste. El skill mejora cuando pides una segunda revisión sobre una sola área de riesgo a la vez, como seguridad, arquitectura o preparación de release. Si la salida parece demasiado amplia, acota el alcance en lugar de pedir “más detalle”.