@saulwade/swl-ses 2.3.0 → 2.4.1

package/habilidades/proceso-dynamic-workflows/SKILL.md

@@ -1,138 +1,138 @@
----
-name: proceso-dynamic-workflows
-description: >
-  Patrones canónicos de dynamic workflows en Claude Code (Workflow tool / ultracode):
-  classify-and-act, fan-out-and-synthesize, adversarial-verification, generate-and-filter,
-  tournament. Cubre los 3 modos de falla que justifican orquestar (agentic laziness,
-  self-preferential bias, goal drift), cuándo NO usar workflows, token budgets, revisión
-  cross-modelo, y el anti-patrón de envolver skills auto-iterantes en /loop|/cron. Cargar
-  cuando se diseñe una orquestación multi-agente, se decida si una tarea amerita workflow,
-  o se quiera empaquetar un workflow como plantilla reutilizable en un skill.
-when_to_use: >
-  Usar cuando el usuario diga "ultracode", "workflow", "orquesta esto", "fan-out", "panel
-  de revisores", "tournament", o cuando una tarea sea larga, masivamente paralela o
-  adversarial y un solo context window sufra laziness/goal-drift.
-herramientasPermitidas: [Read, Grep, Glob]
-exclusiones:
-  - "No cargar para tareas de codificación normales de un solo paso — la mayoría NO necesitan un workflow; el harness por defecto basta y un workflow gasta muchos más tokens."
-  - "No cargar para el detalle de evaluator-optimizer del nemesis — eso vive en nemesis-evaluacion-json y el comando /swl:nemesis."
-  - "No cargar para escribir el .js de un workflow concreto — este skill da los patrones; el script se escribe con el Workflow tool directamente."
----
-
-# Dynamic workflows: patrones, modos de falla y cuándo orquestar
-
-Síntesis del blog oficial de Anthropic *"A harness for every task: dynamic workflows
-in Claude Code"* + patrones validados en swl-ses (nemesis evaluator-optimizer,
-`/swl:verificar --until-converge`, `/swl:autoresearch`). Un dynamic workflow deja que
-Claude escriba su propio harness (JS que coordina subagentes con ventanas aisladas).
-
-## Cuándo cargar
-
-- Se va a diseñar una orquestación multi-agente o decidir si una tarea amerita workflow.
-- La tarea es larga, masivamente paralela, o adversarial (review, research, migración, triage).
-- Se quiere empaquetar un workflow como plantilla reutilizable en un skill.
-
-## Cuándo NO cargar
-
-- Tarea de codificación normal de 1-2 archivos — el harness por defecto basta. Un workflow
-  gasta significativamente más tokens; la mayoría de tareas de coding NO necesitan un panel
-  de 5 revisores.
-- Ya estás dentro del detalle del nemesis (`nemesis-evaluacion-json`).
-- Solo necesitas escribir el `.js` — usa el Workflow tool directo con los patrones de abajo.
-
-## Los 3 modos de falla que JUSTIFICAN orquestar
-
-Un solo context window largo degrada de tres formas — nombrarlas guía cuándo separar Claudes:
-
-1. **Agentic laziness** — Claude se detiene antes de terminar una tarea multi-parte y la
-   declara hecha con progreso parcial (ej. 20 de 50 ítems de un security review). Mitiga:
-   fan-out (un subagente por ítem, ventana limpia) + `/goal` (requisito de completitud duro).
-2. **Self-preferential bias** — Claude prefiere sus propios resultados al verificarlos contra
-   un rubric. Mitiga: **adversarial-verification** con subagente separado, y mejor aún
-   **revisión cross-modelo** (el reviewer es OTRO modelo). Es el mismo principio que
-   `gobernanza.md § Separación revisor/ejecutor`.
-3. **Goal drift** — pérdida gradual de fidelidad al objetivo tras muchos turnos y compaction
-   (cada resumen es lossy; se pierde "no hagas X"). Mitiga: subagentes con goal aislado y
-   constraints explícitas por invocación; `/goal` como ancla.
-
-## Los 5 patrones canónicos
-
-| Patrón | Cuándo | Forma |
-|--------|--------|-------|
-| **Classify-and-act** | Rutear según tipo de tarea/ítem | Clasificador → ramas distintas (al inicio o al final para decidir output) |
-| **Fan-out-and-synthesize** | Muchos sub-pasos; cada uno se beneficia de ventana limpia sin cross-contaminación | N agentes en paralelo → barrier → synthesize merge. **Default** para descomponer |
-| **Adversarial-verification** | Evitar self-preferential bias | Por cada agente, un agente separado verifica su output contra rubric. Diversificar lentes |
-| **Generate-and-filter** | Espacio de ideas amplio (taste-based) | Generar N → filtrar por rubric/verificación → dedupe → solo las mejores probadas |
-| **Tournament** | Solución taste-based con criterio | N agentes compiten con enfoques distintos → juez pairwise hasta ganador |
-
-`pipeline()` (sin barrier entre stages) es el default; usa barrier (`parallel()` entre
-stages) SOLO cuando el stage N necesita TODOS los resultados del N-1 (dedup global,
-early-exit por conteo cero, comparación cruzada).
-
-## Revisión cross-modelo (combate self-preferential bias estructuralmente)
-
-El reviewer adversarial en el MISMO modelo aún arrastra sesgo. La mejora: **executor en un
-modelo, reviewer en otro** (Claude ejecuta → Gemini/Codex/otro revisa). Patrón de ARIS
-(`mcp-servers/gemini-review`): MCP que expone `review`/`review_reply`, devuelve JSON con
-`threadId` + `response` → rastro auditable de un veredicto independiente.
-
-En swl-ses esto es **opt-in** vía `/swl:nemesis --cross-model` (ver el comando): si hay un
-MCP reviewer configurado, la verificación se rutea a un modelo externo; si no, degrada al
-reviewer same-model sin fallar (regla `arreglar-al-detectar.md` / no-fallback-silencioso →
-se anuncia la degradación). Mejoras del reviewer (de ARIS `auto-review-loop`):
-- **Reviewer memory**: el reviewer arrastra sus sospechas entre rondas (un solo `threadId`),
-  no parte de cero cada iteración.
-- **Debate protocol**: el executor puede rebatir; el reviewer falla el veredicto final —
-  *"it can drive, never acquit"* (el loop conduce, el jurado decide).
-- **POSITIVE_THRESHOLD compuesto**: `score ≥ N` **AND** `verdict ∈ {ready, almost}` — un
-  score alto con verdict "not ready" NO detiene el loop.
-
-## Anti-patrón: no envolver un skill auto-iterante en /loop · /cron · /schedule
-
-Si un skill YA itera internamente (review→fix→re-review con memoria de reviewer en un
-`threadId`), envolverlo en `/loop`, `/schedule` o `CronCreate` lo re-entra desde cero cada
-tick → `threadId` nuevo, memoria del reviewer reseteada → dispara el veredicto por
-wall-clock en vez de por cambio de artefacto: cero señal nueva, costo de tokens completo.
-Aplica a `/swl:autoresearch`, `/swl:verificar --until-converge`, nemesis `--remediar`. Si
-hay que agendar algo, agenda **la espera externa que lo precede** (ej. experimentos listos →
-entonces corre el loop UNA vez), no el loop mismo.
-
-## Token budgets, /goal y model routing
-
-- **Token budget en workflows**: el global `budget` (o "use 10k tokens" en el prompt) pone
-  cap duro. Alinea con `scripts/lib/budget-enforcer.js` de swl-ses.
-- **/goal + /loop**: para workflows repetibles (triage, research, verificación), `/goal` da
-  requisito de completitud y `/loop` la cadencia. NO sobre skills auto-iterantes (arriba).
-- **Dynamic model routing**: un agente clasificador investiga la complejidad real del scope
-  y rutea a Sonnet vs Opus por tarea (más fino que el Model-Tier estático del frontmatter).
-
-## Workflows como plantillas en skills
-
-Un `.js` de workflow puede vivir en `recursos/` de un skill y referenciarse en su SKILL.md
-como **plantilla** (no script verbatim) — Claude lo adapta al caso. Plantillas incluidas:
-
-- `recursos/template-adversarial-verify.js` — fan-out de hallazgos + verificación adversarial
-  por hallazgo (filtra los reales).
-- `recursos/template-triage.js` — clasifica ítems de un backlog, dedupe contra lo ya
-  trackeado, y rutea (fix automático vs escalar a humano) con patrón quarantine.
-
-## Quarantine (triage de contenido no confiable)
-
-En triage que lee contenido público/no confiable, los agentes lectores quedan **barred** de
-acciones de alto privilegio; esas las ejecutan agentes distintos que actúan sobre la info ya
-saneada. Coherente con `seguridad-agentes.md § Prompt injection` y el quarantine de SWL.
-
-## Gotchas
-
-- **Workflows gastan más tokens** — úsalos cuando la tarea de verdad necesita más cómputo
-  (adversarial, masivamente paralela), no por reflejo.
-- **Subagentes heredan el contexto del padre** (CLAUDE.md + reglas globales). En proyectos
-  rule-heavy pueden saturar al arrancar (autocompact thrashing). Pasa scope acotado y evita
-  hacer que el subagente explore el codebase completo (ver `harness-claude-code`).
-- **Barrier injustificado** mata wall-clock: si no hay dependencia cross-ítem entre stages,
-  usa `pipeline()`, no `parallel()` entre stages.
-
-## Origen
-
-Adoptado 2026-06-05 desde análisis de `temp/` (blog Anthropic dynamic-workflows +
-ARIS `auto-review-loop`/`mcp-servers`). Ver APRENDIZAJES.md Tipo D 2026-06-05.
+---
+name: proceso-dynamic-workflows
+description: >
+  Patrones canónicos de dynamic workflows en Claude Code (Workflow tool / ultracode):
+  classify-and-act, fan-out-and-synthesize, adversarial-verification, generate-and-filter,
+  tournament. Cubre los 3 modos de falla que justifican orquestar (agentic laziness,
+  self-preferential bias, goal drift), cuándo NO usar workflows, token budgets, revisión
+  cross-modelo, y el anti-patrón de envolver skills auto-iterantes en /loop|/cron. Cargar
+  cuando se diseñe una orquestación multi-agente, se decida si una tarea amerita workflow,
+  o se quiera empaquetar un workflow como plantilla reutilizable en un skill.
+when_to_use: >
+  Usar cuando el usuario diga "ultracode", "workflow", "orquesta esto", "fan-out", "panel
+  de revisores", "tournament", o cuando una tarea sea larga, masivamente paralela o
+  adversarial y un solo context window sufra laziness/goal-drift.
+herramientasPermitidas: [Read, Grep, Glob]
+exclusiones:
+  - "No cargar para tareas de codificación normales de un solo paso — la mayoría NO necesitan un workflow; el harness por defecto basta y un workflow gasta muchos más tokens."
+  - "No cargar para el detalle de evaluator-optimizer del nemesis — eso vive en nemesis-evaluacion-json y el comando /swl:nemesis."
+  - "No cargar para escribir el .js de un workflow concreto — este skill da los patrones; el script se escribe con el Workflow tool directamente."
+---
+
+# Dynamic workflows: patrones, modos de falla y cuándo orquestar
+
+Síntesis del blog oficial de Anthropic *"A harness for every task: dynamic workflows
+in Claude Code"* + patrones validados en swl-ses (nemesis evaluator-optimizer,
+`/swl:verificar --until-converge`, `/swl:autoresearch`). Un dynamic workflow deja que
+Claude escriba su propio harness (JS que coordina subagentes con ventanas aisladas).
+
+## Cuándo cargar
+
+- Se va a diseñar una orquestación multi-agente o decidir si una tarea amerita workflow.
+- La tarea es larga, masivamente paralela, o adversarial (review, research, migración, triage).
+- Se quiere empaquetar un workflow como plantilla reutilizable en un skill.
+
+## Cuándo NO cargar
+
+- Tarea de codificación normal de 1-2 archivos — el harness por defecto basta. Un workflow
+  gasta significativamente más tokens; la mayoría de tareas de coding NO necesitan un panel
+  de 5 revisores.
+- Ya estás dentro del detalle del nemesis (`nemesis-evaluacion-json`).
+- Solo necesitas escribir el `.js` — usa el Workflow tool directo con los patrones de abajo.
+
+## Los 3 modos de falla que JUSTIFICAN orquestar
+
+Un solo context window largo degrada de tres formas — nombrarlas guía cuándo separar Claudes:
+
+1. **Agentic laziness** — Claude se detiene antes de terminar una tarea multi-parte y la
+   declara hecha con progreso parcial (ej. 20 de 50 ítems de un security review). Mitiga:
+   fan-out (un subagente por ítem, ventana limpia) + `/goal` (requisito de completitud duro).
+2. **Self-preferential bias** — Claude prefiere sus propios resultados al verificarlos contra
+   un rubric. Mitiga: **adversarial-verification** con subagente separado, y mejor aún
+   **revisión cross-modelo** (el reviewer es OTRO modelo). Es el mismo principio que
+   `gobernanza.md § Separación revisor/ejecutor`.
+3. **Goal drift** — pérdida gradual de fidelidad al objetivo tras muchos turnos y compaction
+   (cada resumen es lossy; se pierde "no hagas X"). Mitiga: subagentes con goal aislado y
+   constraints explícitas por invocación; `/goal` como ancla.
+
+## Los 5 patrones canónicos
+
+| Patrón | Cuándo | Forma |
+|--------|--------|-------|
+| **Classify-and-act** | Rutear según tipo de tarea/ítem | Clasificador → ramas distintas (al inicio o al final para decidir output) |
+| **Fan-out-and-synthesize** | Muchos sub-pasos; cada uno se beneficia de ventana limpia sin cross-contaminación | N agentes en paralelo → barrier → synthesize merge. **Default** para descomponer |
+| **Adversarial-verification** | Evitar self-preferential bias | Por cada agente, un agente separado verifica su output contra rubric. Diversificar lentes |
+| **Generate-and-filter** | Espacio de ideas amplio (taste-based) | Generar N → filtrar por rubric/verificación → dedupe → solo las mejores probadas |
+| **Tournament** | Solución taste-based con criterio | N agentes compiten con enfoques distintos → juez pairwise hasta ganador |
+
+`pipeline()` (sin barrier entre stages) es el default; usa barrier (`parallel()` entre
+stages) SOLO cuando el stage N necesita TODOS los resultados del N-1 (dedup global,
+early-exit por conteo cero, comparación cruzada).
+
+## Revisión cross-modelo (combate self-preferential bias estructuralmente)
+
+El reviewer adversarial en el MISMO modelo aún arrastra sesgo. La mejora: **executor en un
+modelo, reviewer en otro** (Claude ejecuta → Gemini/Codex/otro revisa). Patrón de ARIS
+(`mcp-servers/gemini-review`): MCP que expone `review`/`review_reply`, devuelve JSON con
+`threadId` + `response` → rastro auditable de un veredicto independiente.
+
+En swl-ses esto es **opt-in** vía `/swl:nemesis --cross-model` (ver el comando): si hay un
+MCP reviewer configurado, la verificación se rutea a un modelo externo; si no, degrada al
+reviewer same-model sin fallar (regla `arreglar-al-detectar.md` / no-fallback-silencioso →
+se anuncia la degradación). Mejoras del reviewer (de ARIS `auto-review-loop`):
+- **Reviewer memory**: el reviewer arrastra sus sospechas entre rondas (un solo `threadId`),
+  no parte de cero cada iteración.
+- **Debate protocol**: el executor puede rebatir; el reviewer falla el veredicto final —
+  *"it can drive, never acquit"* (el loop conduce, el jurado decide).
+- **POSITIVE_THRESHOLD compuesto**: `score ≥ N` **AND** `verdict ∈ {ready, almost}` — un
+  score alto con verdict "not ready" NO detiene el loop.
+
+## Anti-patrón: no envolver un skill auto-iterante en /loop · /cron · /schedule
+
+Si un skill YA itera internamente (review→fix→re-review con memoria de reviewer en un
+`threadId`), envolverlo en `/loop`, `/schedule` o `CronCreate` lo re-entra desde cero cada
+tick → `threadId` nuevo, memoria del reviewer reseteada → dispara el veredicto por
+wall-clock en vez de por cambio de artefacto: cero señal nueva, costo de tokens completo.
+Aplica a `/swl:autoresearch`, `/swl:verificar --until-converge`, nemesis `--remediar`. Si
+hay que agendar algo, agenda **la espera externa que lo precede** (ej. experimentos listos →
+entonces corre el loop UNA vez), no el loop mismo.
+
+## Token budgets, /goal y model routing
+
+- **Token budget en workflows**: el global `budget` (o "use 10k tokens" en el prompt) pone
+  cap duro. Alinea con `scripts/lib/budget-enforcer.js` de swl-ses.
+- **/goal + /loop**: para workflows repetibles (triage, research, verificación), `/goal` da
+  requisito de completitud y `/loop` la cadencia. NO sobre skills auto-iterantes (arriba).
+- **Dynamic model routing**: un agente clasificador investiga la complejidad real del scope
+  y rutea a Sonnet vs Opus por tarea (más fino que el Model-Tier estático del frontmatter).
+
+## Workflows como plantillas en skills
+
+Un `.js` de workflow puede vivir en `recursos/` de un skill y referenciarse en su SKILL.md
+como **plantilla** (no script verbatim) — Claude lo adapta al caso. Plantillas incluidas:
+
+- `recursos/template-adversarial-verify.js` — fan-out de hallazgos + verificación adversarial
+  por hallazgo (filtra los reales).
+- `recursos/template-triage.js` — clasifica ítems de un backlog, dedupe contra lo ya
+  trackeado, y rutea (fix automático vs escalar a humano) con patrón quarantine.
+
+## Quarantine (triage de contenido no confiable)
+
+En triage que lee contenido público/no confiable, los agentes lectores quedan **barred** de
+acciones de alto privilegio; esas las ejecutan agentes distintos que actúan sobre la info ya
+saneada. Coherente con `seguridad-agentes.md § Prompt injection` y el quarantine de SWL.
+
+## Gotchas
+
+- **Workflows gastan más tokens** — úsalos cuando la tarea de verdad necesita más cómputo
+  (adversarial, masivamente paralela), no por reflejo.
+- **Subagentes heredan el contexto del padre** (CLAUDE.md + reglas globales). En proyectos
+  rule-heavy pueden saturar al arrancar (autocompact thrashing). Pasa scope acotado y evita
+  hacer que el subagente explore el codebase completo (ver `harness-claude-code`).
+- **Barrier injustificado** mata wall-clock: si no hay dependencia cross-ítem entre stages,
+  usa `pipeline()`, no `parallel()` entre stages.
+
+## Origen
+
+Adoptado 2026-06-05 desde análisis de `temp/` (blog Anthropic dynamic-workflows +
+ARIS `auto-review-loop`/`mcp-servers`). Ver APRENDIZAJES.md Tipo D 2026-06-05.

package/habilidades/proceso-dynamic-workflows/recursos/template-adversarial-verify.js

@@ -1,65 +1,65 @@
-// PLANTILLA (no ejecutar verbatim) — Workflow tool de Claude Code.
-// Patrón: fan-out de hallazgos -> verificación adversarial por hallazgo -> filtrar reales.
-// Combate self-preferential bias y agentic laziness. Adapta DIMENSIONS, rubrics y schemas.
-//
-// Uso: el agente lee esta plantilla, la ajusta al caso concreto y la pasa al Workflow tool.
-
-export const meta = {
-  name: 'adversarial-verify',
-  description: 'Revisa por dimensiones y verifica cada hallazgo adversarialmente antes de aceptarlo',
-  phases: [{ title: 'Review' }, { title: 'Verify' }],
-}
-
-// Dimensiones de revisión — una por lente independiente (no se contaminan entre sí).
-const DIMENSIONS = [
-  { key: 'correctness', prompt: 'Revisa SOLO correctness del scope. Devuelve hallazgos.' },
-  { key: 'security', prompt: 'Revisa SOLO seguridad del scope. Devuelve hallazgos.' },
-  { key: 'dry', prompt: 'Revisa SOLO duplicación/DRY del scope. Devuelve hallazgos.' },
-]
-
-const FINDINGS = {
-  type: 'object', additionalProperties: false,
-  properties: {
-    findings: {
-      type: 'array',
-      items: {
-        type: 'object', additionalProperties: false,
-        properties: {
-          title: { type: 'string' }, file: { type: 'string' }, line: { type: 'string' },
-          severity: { type: 'string', enum: ['critico', 'mayor', 'menor'] },
-        },
-        required: ['title', 'file', 'severity'],
-      },
-    },
-  },
-  required: ['findings'],
-}
-
-const VERDICT = {
-  type: 'object', additionalProperties: false,
-  properties: {
-    isReal: { type: 'boolean' },
-    reason: { type: 'string' },
-  },
-  required: ['isReal', 'reason'],
-}
-
-// pipeline (sin barrier): cada dimensión verifica sus hallazgos en cuanto su review termina.
-const results = await pipeline(
-  DIMENSIONS,
-  (d) => agent(d.prompt, { label: `review:${d.key}`, phase: 'Review', schema: FINDINGS }),
-  (review, d) =>
-    parallel(
-      (review?.findings || []).map((f) => () =>
-        // Verificador adversarial: prompt orientado a REFUTAR (default refutado si dudoso).
-        agent(
-          `Intenta REFUTAR este hallazgo contra el código real (cita archivo:linea). ` +
-          `Si no puedes probarlo, isReal=false: ${JSON.stringify(f)}`,
-          { label: `verify:${f.file}`, phase: 'Verify', schema: VERDICT }
-        ).then((v) => ({ ...f, verdict: v }))
-      )
-    )
-)
-
-const confirmados = results.flat().filter(Boolean).filter((f) => f.verdict?.isReal)
-return { confirmados }
+// PLANTILLA (no ejecutar verbatim) — Workflow tool de Claude Code.
+// Patrón: fan-out de hallazgos -> verificación adversarial por hallazgo -> filtrar reales.
+// Combate self-preferential bias y agentic laziness. Adapta DIMENSIONS, rubrics y schemas.
+//
+// Uso: el agente lee esta plantilla, la ajusta al caso concreto y la pasa al Workflow tool.
+
+export const meta = {
+  name: 'adversarial-verify',
+  description: 'Revisa por dimensiones y verifica cada hallazgo adversarialmente antes de aceptarlo',
+  phases: [{ title: 'Review' }, { title: 'Verify' }],
+}
+
+// Dimensiones de revisión — una por lente independiente (no se contaminan entre sí).
+const DIMENSIONS = [
+  { key: 'correctness', prompt: 'Revisa SOLO correctness del scope. Devuelve hallazgos.' },
+  { key: 'security', prompt: 'Revisa SOLO seguridad del scope. Devuelve hallazgos.' },
+  { key: 'dry', prompt: 'Revisa SOLO duplicación/DRY del scope. Devuelve hallazgos.' },
+]
+
+const FINDINGS = {
+  type: 'object', additionalProperties: false,
+  properties: {
+    findings: {
+      type: 'array',
+      items: {
+        type: 'object', additionalProperties: false,
+        properties: {
+          title: { type: 'string' }, file: { type: 'string' }, line: { type: 'string' },
+          severity: { type: 'string', enum: ['critico', 'mayor', 'menor'] },
+        },
+        required: ['title', 'file', 'severity'],
+      },
+    },
+  },
+  required: ['findings'],
+}
+
+const VERDICT = {
+  type: 'object', additionalProperties: false,
+  properties: {
+    isReal: { type: 'boolean' },
+    reason: { type: 'string' },
+  },
+  required: ['isReal', 'reason'],
+}
+
+// pipeline (sin barrier): cada dimensión verifica sus hallazgos en cuanto su review termina.
+const results = await pipeline(
+  DIMENSIONS,
+  (d) => agent(d.prompt, { label: `review:${d.key}`, phase: 'Review', schema: FINDINGS }),
+  (review, d) =>
+    parallel(
+      (review?.findings || []).map((f) => () =>
+        // Verificador adversarial: prompt orientado a REFUTAR (default refutado si dudoso).
+        agent(
+          `Intenta REFUTAR este hallazgo contra el código real (cita archivo:linea). ` +
+          `Si no puedes probarlo, isReal=false: ${JSON.stringify(f)}`,
+          { label: `verify:${f.file}`, phase: 'Verify', schema: VERDICT }
+        ).then((v) => ({ ...f, verdict: v }))
+      )
+    )
+)
+
+const confirmados = results.flat().filter(Boolean).filter((f) => f.verdict?.isReal)
+return { confirmados }

package/habilidades/proceso-dynamic-workflows/recursos/template-triage.js

@@ -1,65 +1,65 @@
-// PLANTILLA (no ejecutar verbatim) — Workflow tool de Claude Code.
-// Patrón: classify-and-act + quarantine. Clasifica ítems de un backlog, dedupe contra lo
-// ya trackeado, y rutea: fix automático (bajo riesgo) vs escalar a humano (alto riesgo).
-// Quarantine: el agente que LEE contenido no confiable NO ejecuta acciones de alto privilegio.
-//
-// `args` = lista de ítems del backlog (issues, reportes, etc.). Adapta schemas y umbrales.
-
-export const meta = {
-  name: 'triage',
-  description: 'Clasifica un backlog, dedupe contra lo trackeado y rutea fix-vs-escalar (con quarantine)',
-  phases: [{ title: 'Clasificar' }, { title: 'Actuar' }],
-}
-
-const items = Array.isArray(args) ? args : []
-
-const CLASIFICACION = {
-  type: 'object', additionalProperties: false,
-  properties: {
-    categoria: { type: 'string', enum: ['bug', 'feature', 'duplicado', 'ruido'] },
-    yaTrackeado: { type: 'boolean' },
-    riesgo: { type: 'string', enum: ['bajo', 'alto'] },
-    resumen: { type: 'string' },
-  },
-  required: ['categoria', 'yaTrackeado', 'riesgo', 'resumen'],
-}
-
-const ACCION = {
-  type: 'object', additionalProperties: false,
-  properties: {
-    accion: { type: 'string', enum: ['fix-aplicado', 'escalado-humano', 'descartado'] },
-    detalle: { type: 'string' },
-  },
-  required: ['accion', 'detalle'],
-}
-
-// Stage 1 (quarantine): clasificador LEE el ítem (posible contenido no confiable) pero NO
-// tiene permiso de actuar — solo emite estructura. Stage 2 actúa sobre data ya saneada.
-const triaged = await pipeline(
-  items,
-  (item) =>
-    agent(
-      `Clasifica este ítem del backlog. NO ejecutes ninguna acción: solo describe. ` +
-      `Marca yaTrackeado=true si ya existe ticket. Ítem: ${JSON.stringify(item)}`,
-      { label: 'clasificar', phase: 'Clasificar', schema: CLASIFICACION }
-    ),
-  (clf, item) => {
-    if (!clf || clf.yaTrackeado || clf.categoria === 'ruido' || clf.categoria === 'duplicado') {
-      return { accion: 'descartado', detalle: clf?.resumen || 'sin señal' }
-    }
-    if (clf.riesgo === 'alto') {
-      // Alto riesgo: escalar a humano, no auto-actuar.
-      return agent(
-        `Redacta un escalamiento conciso para humano sobre: ${clf.resumen}`,
-        { label: 'escalar', phase: 'Actuar', schema: ACCION }
-      )
-    }
-    // Bajo riesgo: el agente que ACTÚA es distinto del que leyó contenido no confiable.
-    return agent(
-      `Aplica el fix de bajo riesgo para: ${clf.resumen}. Devuelve qué hiciste.`,
-      { label: 'fix', phase: 'Actuar', schema: ACCION }
-    )
-  }
-)
-
-return triaged.filter(Boolean)
+// PLANTILLA (no ejecutar verbatim) — Workflow tool de Claude Code.
+// Patrón: classify-and-act + quarantine. Clasifica ítems de un backlog, dedupe contra lo
+// ya trackeado, y rutea: fix automático (bajo riesgo) vs escalar a humano (alto riesgo).
+// Quarantine: el agente que LEE contenido no confiable NO ejecuta acciones de alto privilegio.
+//
+// `args` = lista de ítems del backlog (issues, reportes, etc.). Adapta schemas y umbrales.
+
+export const meta = {
+  name: 'triage',
+  description: 'Clasifica un backlog, dedupe contra lo trackeado y rutea fix-vs-escalar (con quarantine)',
+  phases: [{ title: 'Clasificar' }, { title: 'Actuar' }],
+}
+
+const items = Array.isArray(args) ? args : []
+
+const CLASIFICACION = {
+  type: 'object', additionalProperties: false,
+  properties: {
+    categoria: { type: 'string', enum: ['bug', 'feature', 'duplicado', 'ruido'] },
+    yaTrackeado: { type: 'boolean' },
+    riesgo: { type: 'string', enum: ['bajo', 'alto'] },
+    resumen: { type: 'string' },
+  },
+  required: ['categoria', 'yaTrackeado', 'riesgo', 'resumen'],
+}
+
+const ACCION = {
+  type: 'object', additionalProperties: false,
+  properties: {
+    accion: { type: 'string', enum: ['fix-aplicado', 'escalado-humano', 'descartado'] },
+    detalle: { type: 'string' },
+  },
+  required: ['accion', 'detalle'],
+}
+
+// Stage 1 (quarantine): clasificador LEE el ítem (posible contenido no confiable) pero NO
+// tiene permiso de actuar — solo emite estructura. Stage 2 actúa sobre data ya saneada.
+const triaged = await pipeline(
+  items,
+  (item) =>
+    agent(
+      `Clasifica este ítem del backlog. NO ejecutes ninguna acción: solo describe. ` +
+      `Marca yaTrackeado=true si ya existe ticket. Ítem: ${JSON.stringify(item)}`,
+      { label: 'clasificar', phase: 'Clasificar', schema: CLASIFICACION }
+    ),
+  (clf, item) => {
+    if (!clf || clf.yaTrackeado || clf.categoria === 'ruido' || clf.categoria === 'duplicado') {
+      return { accion: 'descartado', detalle: clf?.resumen || 'sin señal' }
+    }
+    if (clf.riesgo === 'alto') {
+      // Alto riesgo: escalar a humano, no auto-actuar.
+      return agent(
+        `Redacta un escalamiento conciso para humano sobre: ${clf.resumen}`,
+        { label: 'escalar', phase: 'Actuar', schema: ACCION }
+      )
+    }
+    // Bajo riesgo: el agente que ACTÚA es distinto del que leyó contenido no confiable.
+    return agent(
+      `Aplica el fix de bajo riesgo para: ${clf.resumen}. Devuelve qué hiciste.`,
+      { label: 'fix', phase: 'Actuar', schema: ACCION }
+    )
+  }
+)
+
+return triaged.filter(Boolean)