Entregar hábitos de ingeniería al agente para que los ejecute

Para quién

Si ya planeas funciones y reparas defectos y solo quieres que el agente siga los mismos hábitos en vez de improvisar, esta skill encaja. Oficialmente: convertir los hábitos de ingeniería que ya conoces en skills que el agente puede ejecutar.

Tras instalar obtienes un conjunto de skills de barra. La página nombra /think, /check, /hunt. En Claude Code escribes los comandos de barra directamente. En Codex los llamas por el nombre de la skill instalada y sigues los mismos pasos. La página también menciona Cursor, Gemini CLI, Copilot, Amp, Kimi Code CLI, y otros agentes que leen el mismo directorio compartido pueden recoger estas ocho skills. Eso es una relación de lectura de directorio, no un conjunto exclusivo de nombres.

Encaja mejor quien tiene un repositorio objetivo que puede abrir y quiere primero un plan o una comprobación de solo lectura, en vez de decir implement de entrada. Notas oficiales:

https://github.com/tw93/waza

Primer intento en 3 minutos

Usa solo esta ruta oficial de instalación:

npx skills add tw93/Waza -a claude-code codex cursor -g -y

El comando deja una copia en el directorio de skills compartido ~/.agents/skills. Claude Code se engancha con un enlace simbólico. Codex, Cursor y otros agentes que leen ese directorio reconocen luego las skills como nombres como /check y /think. La página no da otro instalador como ruta principal.

Requisitos previos: esta máquina ya puede ejecutar el comando npx de arriba, y has abierto al menos un agente que lee ~/.agents/skills. La ubicación de instalación es este directorio compartido. No lo copies a mano a otra carpeta.

Para la primera tarea, elige una acción reversible, más analítica. Tras abrir el repositorio objetivo en Claude Code, escribe /check, o primero /think solo para el plan. En Codex, llama la misma comprobación o el mismo plan por nombre de skill. No digas implement en el primer intento. Señal de éxito: las skills aparecen con nombres como /check y /think, y /check puede dar un resultado a partir del contexto público del repositorio en vez de decir que la skill no está instalada.

Casos de uso

Caso 1: planear primero la función y luego decidir si implementar.

Oficialmente, planear una función se escribe: /think, aprobar el plan, luego decir implement X, luego /check, y solo entonces merge. La primera vez, detente en /think y lee el plan. La evidencia no escribe cómo se ve un botón de aprobar ni un comando concreto de merge. Se puede confirmar este orden, y que la implementación debe ocurrir después de aceptar el plan.

Caso 2: buscar primero la causa raíz y luego cambiar código.

Oficialmente, reparar un defecto se escribe: /hunt, luego reparar, luego /check, luego el seguimiento. La página escribe el seguimiento como release/publish/push/issue follow-through, pero no desarrolla esos pasos. La primera vez, ejecuta solo /hunt. Cuando la descripción de causa raíz encaje con el fenómeno, entonces cambia. /hunt está escrito para confirmar la causa raíz, no para empezar a cambiar de inmediato.

Ambos casos se apoyan en la misma ruta de instalación. /check puede seguir a un plan o a una reparación, pero la primera vez debes ejecutar la comprobación sola y confirmar que leyó contexto público.

Límites

Waza solo aporta hábitos generales de ingeniería. /check lee en tiempo de ejecución el contexto público del repositorio objetivo, incluidos README, manifiestos de paquetes, Makefile, flujos de integración continua y las restricciones de esta tarea. No lee rutas privadas, credenciales ni tokens. La página no escribe que pueda acceder a configuración privada o secretos.

El comando de instalación nombra los tres destinos claude-code, codex y cursor, y la copia cae en ~/.agents/skills. Otros agentes que leen ese directorio pueden recoger las skills, pero la página no da un ejemplo de disparo para cada nombre. Además de las barras de Claude Code y las llamadas por nombre en Codex, lo único confirmado para otros entornos es «si leen el directorio compartido, aparecen estas ocho skills».

La página no escribe un alcance de lenguajes, un cupo ni un tipo de repositorio obligatorio. Si falta el contexto público del repositorio objetivo, hasta dónde puede llegar /check no tiene un ejemplo de fallo aparte.