sdd-es 2.0.0 → 2.6.0

package/skills/cache-audit/SKILL.md

@@ -0,0 +1,163 @@
+---
+description: Audita los archivos de agentes (.claude/agents/*.md) para detectar bloques estables susceptibles de cache_control y los 3 patrones que invalidan caché silenciosamente (timestamps dinámicos, UUIDs, contenido JSONL embebido). Produce una lista de oportunidades de caché ordenadas por impacto.
+model: haiku
+allowed-tools: Read, Bash
+---
+
+# Skill: Cache Audit
+
+## Propósito
+
+El prompt caching de Claude reduce el costo de tokens de entrada hasta un 90% para bloques de contexto que no cambian entre invocaciones. Sin embargo, tres patrones comunes invalidan el caché silenciosamente — el modelo re-paga el precio completo sin que nadie se dé cuenta.
+
+Esta skill detecta esos patrones en los archivos de agentes del proyecto activo y produce recomendaciones concretas.
+
+---
+
+## Lo que lees
+
+```bash
+# Agentes instalados en el proyecto (instalados localmente, no en el plugin)
+ls .claude/agents/ 2>/dev/null || echo "SIN_AGENTES_LOCALES"
+
+# Agentes del plugin (si existe {PLUGIN_DIR})
+ls {PLUGIN_DIR}/agents/ 2>/dev/null | head -20
+
+# Contenido de cada archivo de agente
+for f in .claude/agents/*.md {PLUGIN_DIR}/agents/*.md; do
+  [ -f "$f" ] || continue
+  echo "=== AGENTE: $f ==="
+  cat "$f"
+  echo "---"
+done
+```
+
+---
+
+## Los 3 invalidadores de caché
+
+### Invalidador 1 — Timestamps dinámicos en el system prompt
+
+Un timestamp que cambia en cada sesión rompe el caché de todo el bloque que lo contiene y todos los bloques siguientes.
+
+**Patrones a detectar:**
+```bash
+grep -n "\b[0-9]\{4\}-[0-9]\{2\}-[0-9]\{2\}\b" .claude/agents/*.md {PLUGIN_DIR}/agents/*.md 2>/dev/null
+```
+
+**Severidad:** ALTA — invalida el caché en cada nueva sesión (cada día).
+
+**Fix:** Mover el timestamp al final del prompt, en un bloque marcado como dinámico separado del bloque estable. O eliminarlo si no es necesario.
+
+---
+
+### Invalidador 2 — UUIDs / IDs únicos por sesión
+
+Hashes o IDs generados en cada invocación invalidan todo el bloque donde aparecen.
+
+**Patrones a detectar:**
+```bash
+grep -nE "[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}" \
+  .claude/agents/*.md {PLUGIN_DIR}/agents/*.md 2>/dev/null
+```
+
+**Severidad:** ALTA — invalida en cada invocación.
+
+**Fix:** Sacar el ID del bloque estable. Si el agente necesita el ID, inyectarlo como variable de entorno o como argumento de la invocación, no como parte del system prompt fijo.
+
+---
+
+### Invalidador 3 — Contenido JSONL o ledger embebido directamente
+
+Si el system prompt incluye el contenido del `consumo.jsonl` u otro archivo que cambia frecuentemente, el bloque se invalida en cada escritura del hook.
+
+**Patrones a detectar:**
+```bash
+grep -n "consumo\.jsonl\|\.jsonl\|\"ts\":\|\"agente\":\|\"bytes\":" \
+  .claude/agents/*.md {PLUGIN_DIR}/agents/*.md 2>/dev/null
+```
+
+**Severidad:** MEDIA — invalida con cada invocación de agente.
+
+**Fix:** En lugar de embeber el JSONL en el prompt, hacer que el agente lo lea con la tool `Read` cuando necesite esa información.
+
+---
+
+## Análisis de ratio estable/dinámico
+
+Para cada archivo de agente, calcular:
+
+```bash
+node -e "
+const fs = require('fs');
+const archivos = process.argv.slice(1);
+
+for (const f of archivos) {
+  if (!fs.existsSync(f)) continue;
+  const contenido = fs.readFileSync(f, 'utf8');
+  const lineas = contenido.split('\n');
+  const total = lineas.length;
+  
+  // Líneas sospechosas de ser dinámicas
+  const dinamicas = lineas.filter(l =>
+    /\d{4}-\d{2}-\d{2}/.test(l) ||           // fechas
+    /[0-9a-f]{8}-[0-9a-f]{4}/.test(l) ||     // UUIDs
+    /\"ts\":/.test(l) ||                       // JSONL
+    /consumo\.jsonl/.test(l)
+  ).length;
+  
+  const pct_estatico = Math.round((1 - dinamicas/total) * 100);
+  console.log(f + ': ' + pct_estatico + '% estático (' + dinamicas + '/' + total + ' líneas dinámicas)');
+}
+" .claude/agents/*.md {PLUGIN_DIR}/agents/*.md 2>/dev/null || echo "node no disponible"
+```
+
+---
+
+## Output que produces
+
+```
+╔══════════════════════════════════════════════════════════════════╗
+║           🔄 CACHE AUDIT — Oportunidades de Caché               ║
+╠══════════════════════════════════════════════════════════════════╣
+║  AGENTE              | % ESTÁTICO | INVALIDADORES | SEVERIDAD   ║
+║  ────────────────────┼────────────┼───────────────┼──────────── ║
+║  arquitecto          | 98%        | Ninguno       | ✅ OK       ║
+║  desarrollador-back  | 95%        | Ninguno       | ✅ OK       ║
+║  {agente con prob}   | 72%        | Timestamp L34 | ⚠️  MEDIO  ║
+║  {agente con prob}   | 45%        | UUID L12, L67 | 🔴 ALTO    ║
+╠══════════════════════════════════════════════════════════════════╣
+║  HALLAZGOS CONCRETOS                                             ║
+║                                                                  ║
+║  🔴 {agente}.md:12 — UUID detectado en bloque estable           ║
+║     Fix: mover a argumento de invocación o variable de entorno   ║
+║                                                                  ║
+║  ⚠️  {agente}.md:34 — Timestamp 2026-06-14 en system prompt     ║
+║     Fix: mover al final del prompt, separar en bloque dinámico   ║
+╠══════════════════════════════════════════════════════════════════╣
+║  💰 AHORRO POTENCIAL                                             ║
+║                                                                  ║
+║  Los agentes con >90% contenido estático son candidatos          ║
+║  para cache_control: la primera invocación escribe el caché      ║
+║  y las siguientes pagan ~10% del costo original de input.        ║
+║                                                                  ║
+║  Para activar: separar el system prompt en bloque estable        ║
+║  (primero) + bloque dinámico (al final). El modelo detecta       ║
+║  automáticamente el prefijo estable y lo cachea.                 ║
+╚══════════════════════════════════════════════════════════════════╝
+```
+
+---
+
+## Cuándo usar esta skill
+
+- Antes de `/sdd.implementar` en proyectos con >5 tareas (sesiones largas = más valor del caché)
+- Cuando `/sdd.estado consumo` reporta >1MB de bytes escritos (la sesión es larga)
+- Cuando un agente tarda más de lo esperado en responder (el caché podría no estar activo)
+- Desde `/sdd.optimizar tokens` (se ejecuta automáticamente como parte del ciclo)
+
+## Notas
+
+- El prompt caching es automático en Claude Code — no requiere cambios en el código del hook.
+- Lo que sí requiere intervención manual son los invalidadores: un UUID en línea 1 del prompt hace que el modelo no pueda cachear nada de lo que sigue.
+- Esta skill audita; no modifica archivos. Los fixes los aplica el usuario (o un agente dedicado con permiso de Edit).

package/skills/critica-diseno/SKILL.md

@@ -0,0 +1,193 @@
+---
+description: Auto-crítica del wireframe generado. Evalúa en 5 dimensiones con score 1-5. Si score < 4 y iteraciones < 3, refina el artefacto y repite. Adaptado de critique-theater de open-design.
+model: sonnet
+allowed-tools: Read, Write
+---
+
+# Skill: Crítica de Diseño
+
+## Propósito
+
+Después de generar el wireframe, esta skill lo evalúa en **5 dimensiones** y da un **score 1–5**. Si el score es bajo, refina el wireframe automáticamente y lo re-evalúa. El ciclo se repite hasta score ≥ 4 o 3 iteraciones.
+
+Inspirado en `critique-theater` de open-design (nexu-io).
+
+---
+
+## Lo que lees antes de empezar
+
+```bash
+# El wireframe generado
+cat .sdd/diseño/wireframe-pantalla-principal.html
+
+# El DESIGN.md activo (para verificar fidelidad)
+cat "$(cat .sdd/estado.json | node -e "
+  const d = JSON.parse(require('fs').readFileSync('/dev/stdin','utf8'));
+  console.log(d.design_system_path || '{PLUGIN_DIR}/design-systems/neutral-modern/DESIGN.md');
+")"
+
+# Las reglas anti-slop
+cat "{PLUGIN_DIR}/craft/anti-ai-slop.md"
+```
+
+---
+
+## Las 5 Dimensiones de Evaluación
+
+### Dimensión 1: Jerarquía Visual (1–5)
+¿El ojo del usuario sabe a dónde ir primero?
+
+| Score | Criterio |
+|-------|----------|
+| 5 | Jerarquía clara: un elemento domina, luego soporte, luego detalle |
+| 4 | Jerarquía buena con algún elemento secundario algo fuerte |
+| 3 | Dos elementos compiten por atención principal |
+| 2 | Múltiples elementos con el mismo peso visual |
+| 1 | Sin jerarquía — todo tiene el mismo peso |
+
+### Dimensión 2: Fidelidad al DESIGN.md (1–5)
+¿El wireframe usa los tokens del sistema activo?
+
+| Score | Criterio |
+|-------|----------|
+| 5 | Todos los colores, fuentes y componentes corresponden exactamente al DESIGN.md |
+| 4 | Pequeñas desviaciones (un color ligeramente diferente, borde-radius incorrecto) |
+| 3 | Usa el sistema general pero con elementos fuera del DESIGN.md |
+| 2 | Sistema visual mixto — algunos tokens del DESIGN.md, otros no |
+| 1 | Ignora el DESIGN.md activo completamente |
+
+### Dimensión 3: Funcionalidad del MVP (1–5)
+¿La pantalla permite hacer la acción principal del MVP?
+
+| Score | Criterio |
+|-------|----------|
+| 5 | El usuario puede realizar la acción principal en ≤3 clicks desde esta pantalla |
+| 4 | La acción principal está presente, quizás con un paso de más |
+| 3 | La acción existe pero no es el elemento más prominente |
+| 2 | La acción existe pero está perdida entre otros elementos |
+| 1 | La pantalla no permite realizar la acción principal |
+
+### Dimensión 4: Ausencia de AI-Slop (1–5)
+¿El wireframe evita los patrones genéricos de IA?
+
+| Score | Criterio |
+|-------|----------|
+| 5 | Cero violaciones de las 7 reglas cardinales + cero patrones P1 |
+| 4 | Sin violaciones P0, máximo 1 patrón P1 |
+| 3 | Sin violaciones P0, 2–3 patrones P1 |
+| 2 | 1 violación P0 |
+| 1 | 2+ violaciones P0 |
+
+### Dimensión 5: Innovación Contextual (1–5)
+¿El diseño tiene algo específico de este producto, o es completamente genérico?
+
+| Score | Criterio |
+|-------|----------|
+| 5 | El copy, los datos de ejemplo y los elementos reflejan exactamente el dominio del producto |
+| 4 | Mayoría de elementos son específicos del dominio, alguno genérico |
+| 3 | Mezcla: algunos elementos específicos, otros genéricos |
+| 2 | Solo el nombre del producto es específico — el resto es genérico |
+| 1 | El wireframe podría ser de cualquier producto |
+
+---
+
+## Flujo de Crítica
+
+### Iteración 1
+
+1. Lee el wireframe
+2. Evalúa las 5 dimensiones
+3. Calcula el score promedio: `(D1 + D2 + D3 + D4 + D5) / 5`
+4. Muestra el resultado:
+
+```
+CRÍTICA DEL DISEÑO (iteración 1/3)
+─────────────────────────────────
+Jerarquía visual:      [score]/5  [comentario breve]
+Fidelidad al sistema:  [score]/5  [comentario breve]
+Funcionalidad MVP:     [score]/5  [comentario breve]
+Ausencia de AI-slop:   [score]/5  [comentario breve]
+Innovación contextual: [score]/5  [comentario breve]
+─────────────────────────────────
+SCORE TOTAL: [promedio]/5
+
+[Si score ≥ 4]: ✅ El diseño está listo.
+[Si score < 4]: 🔄 Refinando... (iteración 1 → 2)
+```
+
+### Si score < 4 y iteraciones < 3
+
+Genera una versión mejorada del wireframe corrigiendo los problemas detectados:
+
+```
+Mejoras aplicadas:
+  → [problema D1 → solución aplicada]
+  → [problema D4 → corrección aplicada]
+```
+
+Luego re-evalúa. Repite el proceso.
+
+### Si score ≥ 4 (en cualquier iteración)
+
+```
+✅ DISEÑO APROBADO (score [X]/5, iteración [N]/3)
+
+El wireframe de [screen.name] está listo.
+```
+
+### Si iteración 3 y aún < 4
+
+```
+⚠️ Score final: [X]/5 (después de 3 iteraciones)
+
+El diseño es funcional pero tiene áreas de mejora.
+Puedes continuar o decirme qué cambiar manualmente.
+```
+
+Continúa de todos modos — no bloquea el pipeline.
+
+---
+
+## Output del wireframe refinado
+
+Si se hicieron mejoras, el wireframe refinado **reemplaza** el anterior usando la tool `Write`:
+- Ruta: `.sdd/diseño/wireframe-pantalla-principal.html` (sobreescribe el anterior)
+- Contenido: HTML completo refinado
+
+---
+
+## Guardar resultado de la crítica
+
+```bash
+cat > .sdd/diseño/critica-wireframe.md << 'CRITICA'
+# Crítica del Wireframe — [product.name]
+
+**Fecha**: [timestamp]
+**Iteraciones**: [N]
+**Score final**: [X]/5
+
+## Dimensiones
+
+| Dimensión | Score | Comentario |
+|-----------|-------|-----------|
+| Jerarquía visual | [N]/5 | [texto] |
+| Fidelidad DESIGN.md | [N]/5 | [texto] |
+| Funcionalidad MVP | [N]/5 | [texto] |
+| Ausencia AI-slop | [N]/5 | [texto] |
+| Innovación contextual | [N]/5 | [texto] |
+
+## Mejoras aplicadas
+
+[lista de mejoras si hubo iteraciones]
+CRITICA
+```
+
+---
+
+## Notas
+
+- **No hay evaluación de colores "bonitos"** — solo fidelidad al DESIGN.md
+- **No hay evaluación de creatividad** — solo funcionalidad y ausencia de slop
+- La dimensión "Innovación Contextual" evalúa especificidad del dominio, no creatividad artística
+- El score mínimo para continuar sin comentario es 4/5
+- Si el usuario quiere saltarse la crítica: `/sdd.diseñar --sin-critica` (disponible en el comando)

package/skills/descubrir-idea/SKILL.md

@@ -0,0 +1,133 @@
+---
+description: Discovery form de 5 preguntas para entender la idea del usuario antes de interpretar. Genera contexto estructurado que alimenta el Interpreter.
+model: opus
+allowed-tools: Write
+---
+
+# Skill: Descubrir Idea
+
+## Propósito
+
+Antes de generar ningún IR, necesitamos entender el contexto de la idea. Esta skill hace **5 preguntas clave** en lenguaje natural — sin jerga técnica — y guarda las respuestas en `.sdd/descubrimiento.md`.
+
+El objetivo no es un interrogatorio. Es una conversación breve (2–3 minutos) que permite al Interpreter generar un IR con confidence ≥ 0.8 en lugar de ≤ 0.6.
+
+---
+
+## Flujo
+
+### Paso 1: Presentación
+
+Antes de las preguntas, muestra esto:
+
+```
+Antes de entender tu idea en detalle, tengo 5 preguntas rápidas.
+No hay respuestas correctas — contesta lo que se te ocurra.
+```
+
+### Paso 2: Las 5 preguntas (una a la vez)
+
+Haz cada pregunta de forma conversacional. Espera la respuesta antes de hacer la siguiente.
+
+**Pregunta 1 — Superficie**
+```
+¿Dónde va a vivir esto?
+Por ejemplo: en un navegador web, en el celular, como programa de escritorio, o es algo más técnico (una API, una herramienta de línea de comandos)?
+```
+Acepta respuestas vagas: "web", "móvil", "app", "no sé" — todas son válidas.
+
+**Pregunta 2 — Audiencia**
+```
+¿Quién lo va a usar?
+Puede ser tú mismo, tus clientes, tu equipo, o el público en general.
+```
+No pidas detalles. Cualquier respuesta sirve.
+
+**Pregunta 3 — Tono**
+```
+¿Qué sensación quieres que tenga?
+Por ejemplo: profesional y sobrio, moderno y tecnológico, cálido y amigable, simple y directo...
+```
+Si el usuario no sabe, anota "no definido".
+
+**Pregunta 4 — Restricciones**
+```
+¿Hay algo importante que debamos tener en cuenta?
+Por ejemplo: presupuesto ajustado, necesita estar listo pronto, solo un desarrollador, no quieres depender de servicios de pago...
+```
+Si no hay restricciones, registra "ninguna mencionada".
+
+**Pregunta 5 — Inspiración**
+```
+¿Hay algún producto o app que te guste y que se parezca a lo que quieres hacer?
+No tiene que ser exactamente igual — solo para entender el estilo o la dirección.
+```
+Si el usuario no tiene referencia, anota "sin referencia".
+
+### Paso 3: Guardar contexto
+
+Después de las 5 respuestas, guarda en `.sdd/descubrimiento.md`:
+
+```markdown
+# Contexto de Descubrimiento
+
+**Fecha**: [fecha actual]
+**Idea original**: [texto que dio el usuario antes de la skill]
+
+## Respuestas
+
+**Superficie**: [respuesta 1]
+**Audiencia**: [respuesta 2]
+**Tono**: [respuesta 3]
+**Restricciones**: [respuesta 4]
+**Inspiración**: [respuesta 5]
+
+## Notas del sistema
+
+[Cualquier observación relevante: contradicciones, pistas, contexto adicional]
+```
+
+### Paso 4: Confirmar y pasar al Interpreter
+
+Muestra un resumen de una línea:
+```
+Entendido. Voy a interpretar tu idea teniendo esto en cuenta.
+```
+
+No pidas confirmación — pasa directo al Interpreter.
+
+---
+
+## Reglas
+
+- **Una pregunta a la vez** — nunca hagas 2 preguntas en el mismo mensaje
+- **Sin jerga técnica** — nunca uses "frontend", "backend", "API REST", "deployment", etc.
+- **Sin juzgar** — cualquier respuesta es válida, incluso "no sé"
+- **Máximo 5 preguntas** — nunca hagas preguntas de seguimiento
+- **Tono conversacional** — no formal, no robótico
+
+---
+
+## Ejemplos de respuestas aceptables
+
+**Pregunta 1 - Superficie:**
+- ✅ "web" → `web`
+- ✅ "en el celular" → `mobile`
+- ✅ "no sé, lo que sea más fácil" → `web` (default)
+- ✅ "quiero que se use desde el navegador" → `web`
+
+**Pregunta 2 - Audiencia:**
+- ✅ "mis clientes" → `clientes del negocio`
+- ✅ "yo solo" → `uso personal`
+- ✅ "cualquier persona" → `público general`
+
+**Pregunta 3 - Tono:**
+- ✅ "profesional" → `profesional`
+- ✅ "no sé, que se vea bien" → `moderno y limpio`
+- ✅ "como Airbnb" → `cálido, accesible`
+
+---
+
+## Output esperado
+
+`.sdd/descubrimiento.md` con las 5 respuestas estructuradas, listo para que `interpretar-idea` lo lea como contexto adicional.

package/skills/effort-router/SKILL.md

@@ -0,0 +1,128 @@
+---
+description: Dado el nombre de la fase SDD actual, recomienda effort (low/medium/high/max) y modelo (Haiku/Sonnet/Opus) para cada agente. Evita pagar Opus cuando Sonnet o Haiku son suficientes — ahorro típico del 60-75% en fases mecánicas.
+model: haiku
+allowed-tools: Read
+---
+
+# Skill: Effort Router
+
+## Propósito
+
+Los agentes de FORGE usan modelos fijos declarados en su frontmatter. Pero no toda fase requiere el mismo nivel de razonamiento. Esta skill lee la fase actual del proyecto y produce una tabla de configuración recomendada: qué modelo usar en cada agente y con qué nivel de `effort`, para evitar gastar Opus donde Haiku es suficiente.
+
+**Ahorro estimado por fase:**
+- Fases mecánicas (tests, docs, deploy): 75-80% vs. Opus en todo
+- Fases de verificación: 50-60%
+- Fases de decisión (spec, plan, análisis): 0% — estas SÍ necesitan Opus
+
+---
+
+## Lo que lees primero
+
+```bash
+# Fase actual y spec activa
+cat .sdd/estado.json 2>/dev/null | head -20 || echo "SIN_ESTADO"
+```
+
+---
+
+## Tabla de routing por fase
+
+### GRUPO A — Siempre Opus (decisiones críticas, no degradar)
+
+| Fase SDD | Agente principal | Effort | Modelo | Razón |
+|---|---|---|---|---|
+| `especificacion` | arquitecto | high | claude-opus-4-8 | Define restricciones del sistema entero |
+| `planificacion` | arquitecto, critico | high | claude-opus-4-8 | Decisiones de arquitectura irreversibles |
+| `analisis` (7 dimensiones) | critico, seguridad | high | claude-opus-4-8 | Auditoría de riesgos — falsos negativos son costosos |
+| `aclaracion` (cuando hay `[MARCADOR]`) | arquitecto | high | claude-opus-4-8 | Ambigüedades de spec → decisiones de arquitectura |
+
+### GRUPO B — Sonnet suficiente (trabajo técnico estándar)
+
+| Fase SDD | Agente principal | Effort | Modelo | Razón |
+|---|---|---|---|---|
+| `checklist` | (sin agente dedicado) | medium | claude-sonnet-4-6 | Verificación mecánica contra criterios conocidos |
+| `tareas` | (sin agente dedicado) | medium | claude-sonnet-4-6 | Descomposición mecánica de plan → tareas |
+| `implementacion` (backend/API) | desarrollador-backend, disenador-api | medium | claude-sonnet-4-6 | Implementación con spec clara |
+| `implementacion` (frontend) | desarrollador-frontend | medium | claude-sonnet-4-6 | Implementación con spec clara |
+| `verificacion` | verificador-implementacion | medium | claude-sonnet-4-6 | Cruzar CAs — bien definido |
+| `qa` | tester | medium | claude-sonnet-4-6 | Orquestar Playwright — mecánico pero con estado |
+| `snapshot` | (sin agente dedicado) | low | claude-sonnet-4-6 | Serializar estado actual |
+
+### GRUPO C — Haiku suficiente (operaciones mecánicas puras)
+
+| Fase SDD | Agente principal | Effort | Modelo | Razón |
+|---|---|---|---|---|
+| `aclaracion` (sin marcadores) | (sin agente dedicado) | low | claude-haiku-4-5-20251001 | Solo formatear preguntas conocidas |
+| `implementacion` (tests) | tester | low | claude-haiku-4-5-20251001 | Tests unitarios con spec y código claros |
+| `implementacion` (docs) | documentador | low | claude-haiku-4-5-20251001 | Documentar código ya escrito |
+| `deploy` | operaciones | low | claude-haiku-4-5-20251001 | Ejecutar scripts CI/CD predefinidos |
+| `canary` | operaciones | low | claude-haiku-4-5-20251001 | Igual que deploy |
+| `release` | (sin agente dedicado) | low | claude-haiku-4-5-20251001 | Actualizar versiones y CHANGELOG |
+| `retro` | (sin agente dedicado) | low | claude-haiku-4-5-20251001 | Formato de retrospectiva estructurado |
+
+---
+
+## Output que produces
+
+Dado el JSON de `.sdd/estado.json`, imprime el bloque de configuración recomendada:
+
+```
+╔══════════════════════════════════════════════════════════════╗
+║          🎯 EFFORT ROUTER — Configuración recomendada        ║
+╠══════════════════════════════════════════════════════════════╣
+║  Fase detectada: {FASE}                                      ║
+╠══════════════════════════════════════════════════════════════╣
+║  AGENTE               | MODELO          | EFFORT   | GRUPO  ║
+║  ─────────────────────┼─────────────────┼──────────┼─────── ║
+║  {agente}             | {modelo}        | {effort} | {A/B/C}║
+╠══════════════════════════════════════════════════════════════╣
+║  💰 AHORRO ESTIMADO vs. Opus-en-todo                         ║
+║                                                              ║
+║     Agentes en Grupo B:  {N} × ~60% ahorro por token        ║
+║     Agentes en Grupo C:  {N} × ~80% ahorro por token        ║
+║     Ahorro total estimado de la fase: ~{%}%                  ║
+╠══════════════════════════════════════════════════════════════╣
+║  ⚠️  ATENCIÓN                                                ║
+║                                                              ║
+║  Estos son defaults para la fase "{FASE}".                   ║
+║  Si la tarea actual tiene ambigüedad estructural →           ║
+║  sube a Opus para el agente afectado.                        ║
+╚══════════════════════════════════════════════════════════════╝
+```
+
+### Cálculo del ahorro estimado
+
+Precios de referencia (por millón de tokens):
+- Opus 4.8: $5 input / $25 output
+- Sonnet 4.6: $3 input / $15 output  ← 40% más barato en input, 40% en output
+- Haiku 4.5: $1 input / $5 output   ← 80% más barato en input, 80% en output
+
+Para la fase actual, suma los agentes activos y calcula el delta respecto a "todos Opus".
+
+**Ejemplo — fase `implementacion`:**
+```
+Grupo A (Opus):    0 agentes
+Grupo B (Sonnet):  3 agentes (backend, frontend, disenador-api) → ~40% ahorro c/u
+Grupo C (Haiku):   2 agentes (tester, documentador) → ~80% ahorro c/u
+
+Ahorro total estimado: ((3×0.40) + (2×0.80)) / 5 = ~56%
+```
+
+---
+
+## Cómo aplicar las recomendaciones
+
+Las recomendaciones son de sesión (no tocan los archivos `.md` de los agentes). Para aplicar en la sesión actual:
+
+1. Cuando Claude Code invoca un agente vía `/sdd.implementar`, puedes prefixar la invocación con el modelo sugerido si el runtime lo permite.
+2. Para cambios permanentes en el frontmatter del agente, edita `{PLUGIN_DIR}/agents/{nombre}.md` y cambia la línea `model:` del frontmatter.
+3. Para registrar que usaste el router en esta sesión, añadir al ledger: `/sdd.estado consumo`.
+
+---
+
+## Notas
+
+- Esta skill se invoca automáticamente desde `/sdd.optimizar` como PASO 2 cuando hay alertas de fan-out.
+- Para proyectos con presupuesto de tokens restringido, usa junto con `token-budget` para ver el impacto económico real.
+- La regla de oro: **si el agente toma una decisión que no se puede deshacer → Opus. Si ejecuta una decisión ya tomada → Sonnet o Haiku.**