breakdown -- descomposición convergente y orientada a la acción
El complemento convergente de /fanout. /fanout abre un problema (muchas respuestas válidas); /breakdown cierra uno (un enredo -> un siguiente paso). De una sola ejecución, sin subagentes, ~1x costo. Basado en el análisis de transcripciones de sesiones del mantenedor: la fricción más fuerte era "deja de explicar, solo hazlo", por lo que este skill está diseñado para ser ACCIÓN-PRIMERO y con mínima prosa. Si tu salida parece un amable tutorial, está mal -- recórtala.
Paso 1 -- obtener el enredo
Acepta el problema mediante una @mención, una ruta o texto pegado. Si es genuinamente vago,
pide una o dos frases -- una sola vez. Lee cualquier archivo referenciado hasta el final antes de descomponer.
Si el enredo es (o nombra) un artefacto del proyecto, TAMBIÉN lee el CHECKPOINT.md de ese proyecto
hasta el final primero (recibo/vista previa no es una lectura) -- el "objetivo real" y la "decisión bloqueante"
dependen del estado vivo del proyecto (plazos, compuertas de secuenciación, lo ya decidido), y una
descomposición ciega a ello apunta a la siguiente acción equivocada. Omite solo si realmente no hay proyecto.
Paso 2 -- genera exactamente estos cinco bloques, de forma escueta, en orden
Sin preámbulo. Sin "Tengo acceso a...". No replantees la pregunta de forma extensa.
- Objetivo real (una frase). Lo que realmente significa "terminado". Si el objetivo declarado difiere del real, dilo en una línea.
- Siguiente acción más pequeña (un paso concreto, físico, realizable en una sesión -- p. ej., "abre X y escribe los tres nombres de campo," no "diseña el esquema"). Luego OFRÉCETE a simplemente hacerlo ahora. No expliques extensamente primero.
- La única decisión bloqueante -- la bifurcación única que desbloquea la mayor parte, o "ninguna -- solo empieza."
- Plan completo (colapsado) -- la lista de verificación completa bajo un resumen de una línea, explícitamente desenfatizado: "ignora hasta que el paso 2 esté hecho."
- Primera trampa -- el modo de fallo más probable y su primera señal.
Reglas
- Un solo hilo en la ruta crítica. No enumeres flujos de trabajo paralelos.
- Lenguaje claro, sin códigos inventados (traduce cualquier etiqueta de archivo a palabras humanas).
- NO comiences el trabajo hasta que el usuario elija. /breakdown planifica; no ejecuta.
- No persistas nada por defecto. Si vale la pena conservarlo, ofrécete a escribirlo en la línea de "Siguiente paso" del CHECKPOINT del proyecto.