Claude Skills by rarango10

Explica el ciclo de desarrollo asistido de este harness y enruta a la pieza que corresponde en cada paso. Usalo cuando la persona pregunte cómo se trabaja acá, cuál es el paso siguiente, qué skill le toca a lo que quiere hacer, o cuando pida arrancar una feature y no esté claro en qué punto del ciclo está. No produce ningún documento por su cuenta: nombra al skill que sí lo produce.

Use this before any creative or design work in this project - adding a feature, changing behavior, or shaping a new part of the app. Turns a raw idea into a clarified, approved design through clarifying questions and conversation, before any spec is written or any code is touched. Trigger this whenever the user proposes a new feature, asks 'how should we build X', or describes something to add/change and hasn't yet agreed on an approach.

Cierra una feature terminada: corre el comando de higiene completo sobre el estado final del repo, comprueba que todos los veredictos de dod-checker sigan siendo ciertos juntos, y hace el commit de cierre. Un rojo baja la tarea afectada a en curso y la devuelve al TDD. Es el paso 8 del ciclo. Usalo cuando la persona diga 'cerremos la feature', 'commiteemos', 'listo para commitear', 'ya terminamos X', o cuando todas las tareas estén en hecho y el ciclo e2e haya cerrado. No repara código, no to...

Siembra el CLAUDE.md de un proyecto para que el harness pueda trabajar ahí: parte de una plantilla y completa sus ranuras entrevistando, nunca decidiendo solo. Es el paso 0 del ciclo. Usalo cuando la persona diga 'armemos el contrato', 'preparemos el proyecto', 'iniciemos el harness acá', 'no hay CLAUDE.md', o cuando quiera arrancar una feature en un repo que todavía no tiene uno. Si ya existe un CLAUDE.md, no lo pisa: lo revisa contra lo que el harness necesita y propone los arreglos. Siembr...

Implementa UNA tarea del tasks.md de una feature, de punta a punta: la marca en curso, escribe el primer test en rojo, implementa lo mínimo para el verde, invoca a dod-checker sin preguntar, asienta el veredicto en el Registro y commitea con el id de la tarea en el mensaje. Es el paso 5 del ciclo. Usalo cuando la persona diga 'implementemos T3', 'hagamos T5', 'arranquemos con la implementación', 'seguimos con la que sigue', o cuando un tasks.md aprobado tenga tareas en pendiente. No escribe e...

Verifica que el spec de una feature esté completo y aprobado y, si lo está, lanza el workflow "tasks-fanout" que crea o itera su tasks.md. Pregunta antes de lanzar. No planifica ni escribe tasks.md por su cuenta. Es el único camino al plan de tareas: usalo cuando la persona diga "planeemos las tareas", "desglosemos las tareas", "armemos el plan de implementación", "generá el plan de implementación", "iteremos tasks.md", "revisemos las tareas del spec", o pregunte cuál es el siguiente paso des...

Escribe el spec de una feature en dos fases, cada una con su compuerta de aprobación: requirements.md con criterios de aceptación en notación EARS, y design.md con arquitectura, interfaces, modelos de datos, errores y estrategia de testing. El plan de tareas (tasks.md) NO lo hace este skill: es el paso siguiente y lo hace el skill planning-tasks. Usá este skill apenas haya un diseño aprobado en brainstorming, o cuando la persona diga 'escribamos el spec', 'documentemos los requisitos', 'hagam...

Verifica una feature ya implementada de punta a punta, en dos fases: escribe e2e-tests-plan.md con 3 casos (1 happy path y 2 de fallo) a partir del spec aprobado, y después orquesta la generación de los tests de Playwright y su corrida, hasta un e2e-test-report.md que rutea cada fallo. Usalo cuando la persona diga 'verifiquemos e2e', 'probemos de punta a punta', 'armemos los tests end to end', 'corramos el e2e', o cuando todas las tareas de un tasks.md ya estén en hecho y falte comprobar que ...