Fanout — pase selectivo de ideación divergente
Base empírica: la evaluación en dos fases del mantenedor. El fanout otorga una ventaja pequeña pero consistente en tareas de diseño divergente y ninguna en trabajo convergente de causa raíz. Vale la pena ~7x tokens solo cuando la tarea es abierta Y de alto riesgo. Este skill existe para que la mejora esté disponible bajo demanda sin dispararse nunca en trabajo rutinario.
Paso 0 — compuerta antes de ejecutar (obligatorio)
Comprueba la tarea contra el selector. Ambas deben ser verdaderas:
- ¿Abierta? Múltiples respuestas válidas ("diseño / nombre / enfoque / hipótesis para X"). Si la tarea es "por qué se rompió X", "¿funcionó la corrección?", "cuál es la causa raíz", o cualquier cosa con una única respuesta comprobable -> esto es CONVERGENTE. Dile al usuario que el disparo único es la herramienta más adecuada aquí, y pregúntale si desea continuar de todos modos antes de ejecutar. No ejecutes en silencio sobre tareas convergentes.
- ¿Suficientemente alto riesgo para ~7x tokens? Una regla fundamental / forma de API / nombre / estrategia, no algo descartable. Si parece de bajo riesgo, dilo y confírmalo.
Si la compuerta es ambigua, expón tu interpretación y pregunta. Una vez que pase, continúa.
Paso 1 — obtener el problema
Acepta el enunciado del problema desde: un archivo @mencionado, una ruta de archivo o texto pegado en el mensaje del usuario. Si solo se da un tema vago, pide primero una o dos frases de encuadre del problema — los marcos necesitan algo concreto.
Paso 1.5 — ORIENTAR si el objetivo es un artefacto del proyecto (obligatorio)
Un /fanout <ruta de archivo> parece preorientado, pero NO lo está: los marcos razonan solo con el artefacto y contradecirán con confianza el estado vivo del proyecto si no se lo proporcionas. Antes del Paso 2, si el problema es (o menciona) un archivo dentro de una carpeta de proyecto — una especificación, documento de decisión, hilo CHECKPOINT, archivo de código — lee primero ese CHECKPOINT.md del proyecto hasta el final (y su CLAUDE.md si el hook no lo ha mostrado). El recibo de SessionStart es un recuento de bytes/líneas, NO el archivo — una vista previa no es una lectura. Luego extrae las restricciones fundamentales (plazos, compuertas de financiación/secuenciación, decisiones vigentes, lo que ya se ha intentado/descartado, números concretos) y pégalos textualmente en CADA indicación de marco Y en la del crítico, de la misma manera que el texto del artefacto. Un marco que recibe el artefacto pero no el estado del proyecto es un fallo documentado (un fanout real sobre una especificación de costos produjo un encuadre "prematuro, hazlo después del punto de equilibrio" que el CHECKPOINT del proyecto contradecía directamente). Omite este paso SOLO cuando el problema es genuinamente libre de proyecto (una pregunta abstracta pegada, un ejercicio de nombres/formas de API sin estado vivo detrás).
Paso 2 — DIVERGENCIA (5 llamadas de agente en paralelo, un mensaje)
Dispara 5 agentes general-purpose EN PARALELO (un solo mensaje, 5 llamadas de herramienta). Dale a cada uno el mismo problema y UNA perspectiva distinta. Instrucción de cada agente: "Analiza SOLO desde tu perspectiva asignada. Genera 4-6 enfoques/ideas DISTINTOS; para cada uno, nombra los modos de fallo (trampas) que conlleva y explica el mecanismo. Sé específico, nombra mecanismos, no uses rodeos, no clasifiques, no evalúes tus propias ideas. Mantenlo conciso (esto alimenta un pase crítico)." Devuelve la salida directamente (sin escribir archivos a menos que el usuario haya pedido guardarlos).
Las 5 perspectivas (textuales):
- ARQUITECTURA / SISTEMAS — piensa en máquinas de estados, flujos de datos y dónde se transforma o pierde información; qué hace el sistema en la capa inferior al comportamiento visible; cómo se rompe bajo concurrencia, fallos o escala.
- ADVERSARIAL / ABOGADO DEL DIABLO — asume que cada opción tiene un fallo fatal y encuéntralo; ¿qué asume silenciosamente cada una? ¿Qué sería cierto si la respuesta obvia es un señuelo?
- PRIMEROS PRINCIPIOS — despoja hasta el mecanismo subyacente, reconstruye desde restricciones reales, desconfía de la convención; ¿qué es realmente necesario frente a meramente habitual?
- PRACTICANTE / OPERADOR — has ejecutado esto en producción y te han despertado por ello a las 3am; preocúpate por fallos en campo, casos extremos, desgaste operativo, observabilidad, la brecha entre el diseño y la realidad de la guardia.
- FORÁNEO GENERALISTA — sin contexto de dominio; lo que tiene sentido intuitivo; desconfía de la jerga que esconde razonamientos circulares; la trampa obvia en retrospectiva que los expertos internos podrían pasar por alto.
Paso 3 — CRÍTICO (1 llamada de agente)
Una vez que los 5 hayan respondido, dispara UN agente general-purpose con las 5 salidas + el problema. Instrucción: "1) PUNTÚA cada enfoque en novedad/viabilidad/ajuste (0-10). 2) AGRUPA entre marcos por estrategia subyacente; señala dónde 2+ marcos convergieron (esa convergencia es señal). 3) UNIÓN DE TRAMPAS: la unión desduplicada de trampas distintas, expresadas mecánicamente, de los 5 marcos, cada una con su mecanismo. 4) PROFUNDIZA LAS 3 PRINCIPALES: versión más nítida, mecanismo, trampas a evitar, el supuesto más riesgoso del que depende + la forma más barata de probar ese supuesto antes de comprometerse, y un primer paso concreto. Secciones de salida: ## Puntuadas, ## Agrupaciones, ## Unión de trampas, ## Las 3 principales profundizadas, ## Síntesis (4-6 frases: la dirección más fuerte + las trampas que más la amenazan)."
Paso 4 — presentar
Muestra al usuario las secciones ## Las 3 principales profundizadas, ## Unión de trampas y ## Síntesis del crítico en el chat. Resume la convergencia (qué direcciones alcanzaron varios marcos de forma independiente). NO vuelques las 5 salidas de marcos en bruto a menos que te lo pidan.
Por defecto no persistas nada (los archivos temporales sobrantes son su propio desorden). Si el usuario quiere el registro completo, ofrécete a guardar la salida del crítico + los marcos en una ruta que él nombre.
Notas
- Solo herramienta Agent nativa — NO invoques un
claude -panidado desde el shell para los marcos (los lanzamientos CLI anidados no son fiables bajo capas de permisos/seguridad; la herramienta Agent es la ruta soportada). - Esto es de un solo disparo por invocación (n=1). Si el usuario quiere una verificación de varianza, puede invocar /fanout de nuevo — pero el pequeño tamaño del efecto rara vez lo justifica.
- Nunca se active automáticamente. Solo las formas explícitas de superficie descritas en la descripción.