nadavushka-dev/nadavushka-plugs

Procesa un ticket del gestor de incidencias (p. ej. RND-123): para errores → reproduce y obtén la evidencia roja, luego el arreglo mínimo; para funcionalidades → implementa según el PRD. Usa de forma independiente o como paso 3 de autonomous-squad.

¿Qué es nadavushka-plugs?

Este skill está diseñado para que un agente de IA (como Claude Code) trabaje de manera estructurada sobre tickets de un gestor de incidencias. Primero, configura el contexto leyendo el archivo `squad-config.md` y, si no hay información del ticket en la conversación o no existe un worktree, invoca otros skills auxiliares (`squad:tkt-context`, `squad:tkt-evidence`) o crea el worktree. Para tickets de tipo error, el skill guía al agente a reproducir el bug y capturar una evidencia roja en el medio adecuado (test, curl, shell de base de datos, logs); si no se logra obtener ninguna evidencia, se clasifica como "qa clar". Luego, el agente aplica el cambio mínimo para corregir el error. Para funcionalidades, el agente debe seguir rigurosamente el PRD y, ante ambigüedades o conflictos, marcarlos como "prod clar". Finalmente, se realiza una revisión adversarial: se lanza un subagente independiente que evalúa el cambio, etiquetando cada hallazgo como "blocking" o "nit". Los bloqueos deben resolverse con evidencia en máximo dos rondas; de lo contrario, se escala a "dev clar". El skill soporta cualquier plataforma que ejecute skills tipo Claude Code y está pensado para entornos de desarrollo con tickets, worktrees y PRDs.

Compatible con✓Claude Code~Codex CLI~Cursor

npx skills add https://github.com/nadavushka-dev/nadavushka-plugs/tree/HEAD/squad/skills/tkt-work

Documentación

Entrada del usuario: $ARGUMENTS

Config

Antes de cualquier otra cosa: lee ${CLAUDE_SKILL_DIR}/../squad-config.md

Antes de empezar

No hay contexto del ticket en esta conversación → invoca el skill squad:tkt-context con la clave del ticket primero
No hay worktree para este ticket → créalo (ver Reglas)

¿Error?

Reproduce → rojo

Reproduce el error y captura el artefacto rojo en el medio del error (consulta el skill squad:tkt-evidence). "No se puede capturar pantalla" nunca es una razón para detenerse — cambia de medio (test / curl / shell de base de datos / log). Ningún artefacto rojo en ningún medio → qa clar.

Resuelve

Cambios mínimos para corregir el error

¿Funcionalidad?

El PRD debe seguirse al pie de la letra
Si es ambiguo, contradice o entra en conflicto con funcionalidades existentes → márcalo en un comentario, pasa a prod clar

Revisión adversarial (antes del verde / `squad:tkt-evidence`)

Lanza un subagente nuevo (no un fork). Dale: clave del ticket, diff, artefacto rojo (error) o PRD (funcionalidad). Su trabajo es romper el cambio, no aprobarlo. Cada hallazgo se etiqueta como blocking o nit.

Error: ¿el rojo reproduce el error reportado? ¿Causa raíz o síntoma? ¿Mínimo? ¿Regresiones cercanas?
Funcionalidad: ¿cada punto del PRD está cubierto y probado? ¿Algo más allá del PRD? ¿Conflictos con comportamiento existente? Blocking → arregla → vuelve a revisar. Descarta un hallazgo blocking solo con evidencia, no con argumentos. Si sigue siendo blocking después de 2 rondas → dev clar con la pregunta abierta. Nits → arréglalos o listalos en el PR.