npm - @tacuchi/agent-workflow-cli - Versions diffs - 11.0.1 → 12.0.0 - Mend

@tacuchi/agent-workflow-cli 11.0.1 → 12.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (447) hide show

package/skills/agent-workflow/specialties/analyze-conclude/references/incident-classification.md DELETED Viewed

@@ -1,61 +0,0 @@
-# Clasificación del incidente — severidad, impacto, comunicación
-Aplica a `analyze-conclude` con `## Modality: incident` (legacy: `## Modalidad: incidente`). Toda CONCLUSIONS.md de incidente debe declarar severidad, impacto cliente cuantificado y timeline de comunicación. Sin estos campos, las conclusiones son incompletas.
-## Severidad
-| Nivel | Criterio | Ejemplos | Comunicación esperada |
-|---|---|---|---|
-| **SEV1** | Crítico — sistema o flujo principal caído >1h, datos comprometidos, multas regulatorias | Login down >1h, BD principal corrupta, leak de PII | Status page + email a clientes + regulador (si aplica) en <30 min de detección |
-| **SEV2** | Degradado — feature secundaria caída, flujo principal degradado >15min y <1h | Latencia 5x normal en endpoint clave, una región caída | Status page + Slack interno; email cliente si dura >30 min |
-| **SEV3** | Limitado — afecta <10% usuarios o feature no-crítica | Bug en pantalla específica, error intermitente bajo volumen | Slack interno; sin comunicación externa salvo cliente afectado pregunte |
-| **SEV4** | Cosmético / interno — sin impacto en producción visible | Job batch atrasado pero recuperable, alerta interna falsa | Solo Slack del equipo; no requiere post-mortem formal salvo aprendizaje notable |
-Declarar la severidad en el **Resumen** y justificar en una línea: "SEV2 — flujo de pago degradado 35 min para 8% de usuarios".
-## Impacto cliente — cuantitativo
-Cada CONCLUSIONS.md de incidente documenta dentro de **Conclusiones** una `**CN**: Impacto` con las siguientes magnitudes (si no aplica una, decir "no aplica"; nunca dejar vacío):
-| Métrica | Cómo cuantificar |
-|---|---|
-| **Duración total** | Desde primer evento hasta servicio restaurado (no desde detección — el cliente sintió desde el primer evento) |
-| **Usuarios afectados** | Número absoluto (preferido) o estimación con metodología clara (ej. "5% de usuarios activos del día = ~12k") |
-| **Transacciones impactadas** | Perdidas, duplicadas, en estado inconsistente — separadas. Cantidad + valor monetario si aplica |
-| **Datos comprometidos** | Sí/no/qué tipo. Si sí, declarar acción de notificación regulatoria |
-| **Costo financiero** | Refunds, créditos, penalidades, costo de remediación. Estimación con rango si no es preciso |
-| **Reputación / soporte** | Tickets abiertos relacionados, menciones en redes, NPS si se mide |
-Si los datos no están disponibles inmediatamente, CONCLUSIONS.md **declara** que se actualizará con números finales en una fecha objetivo.
-## Timeline de comunicación
-Bloque obligatorio dentro de la conclusión `**CN**: Timeline` — registra **cuándo y a quién** se comunicó:
-| Evento | Canal | Audiencia | Hora (UTC) | Quién |
-|---|---|---|---|---|
-| Detección interna | Slack #incidents | Equipo on-call | HH:MM | sistema/persona |
-| Activación incident commander | Llamada/Slack | Equipo extendido | HH:MM | IC asignado |
-| Primer aviso interno | Slack #general | Toda la org | HH:MM | IC |
-| Primer aviso externo | Status page | Clientes | HH:MM | Comms / IC |
-| Aviso regulador (SEV1 con datos) | Email/portal regulatorio | <ente> | HH:MM | Compliance |
-| Resolución comunicada externamente | Status page + email | Clientes | HH:MM | Comms |
-| Post-mortem público (si compromete confianza) | Blog/email | Clientes | YYYY-MM-DD | Comms |
-### Reglas de comunicación
-- **SEV1**: status page actualizada cada 30 min hasta resolución. Cliente dueño de los datos comprometidos contactado directamente <2h.
-- **SEV2**: status page actualizada al menos 2 veces (inicio + resolución). Email a clientes si dura >30 min.
-- **SEV3**: Slack interno + ticket si cliente lo reporta. Sin proactivo externo.
-- **Honestidad**: no minimizar en comunicación pública. "Estamos investigando un incidente que afecta a algunos usuarios" es preferible a silencio o promesas vacías.
-## Trazabilidad de acciones
-Cada `**RN**` (Recomendación) preventiva cumple:
-- **Owner nombrado** (persona o equipo, no "alguien").
-- **Fecha objetivo** en formato YYYY-MM-DD.
-- **Criterio de "hecho"** medible (ej. "alerta dispara con dataset de prueba" no "mejorar alerting").
-- **Priorizada**: P1 = bloqueo de SEV similar futuro; P2 = reduce probabilidad; P3 = mejora detección/respuesta.
-CONCLUSIONS.md de incidente se considera **cerrable** sólo cuando todas las recomendaciones P1 tienen owner y fecha.

package/skills/agent-workflow/specialties/analyze-investigate/SKILL.md DELETED Viewed

@@ -1,148 +0,0 @@
----
-name: analyze-investigate
-description: Recolección de evidencia divergente sin juicio. Lee código, corre queries read-only contra <mcp-cert>/<mcp-prod> (MCPs), tracea logs, cava git history. Produce EVIDENCE.md + queries/. Invocado en execution de sesiones analyze (cualquier modalidad). Pre-requisito de analyze-synthesize en analyze sessions.
-version: 1.2.0
----
-> **Profile parametrization**: lee `mcp_databases[]` de `profile.json` (resuelto vía cascade 5 capas). Ver [`references/profile-parametrization.md`](../../references/profile-parametrization.md) para el contrato completo y comportamiento por defecto cuando el profile está vacío.
-# analyze-investigate — qtc v1.1+
-Specialty skill **analyze**: investigación divergente. Primer paso de `execution` para sesiones analyze (cualquier modalidad). **Read-only**.
-## Rama base — verificar antes de leer/queries
-Antes de lecturas extensivas o queries (`Grep`, `Read`, MCP `<mcp-cert>`/`<mcp-prod>`), confirmar que cada fuente está en su `main_branch` (default `certificacion`). El análisis sobre otra rama puede divergir de producción y producir conclusiones erradas.
-- El lifecycle ya valida esto al entrar a execution (skill `session`, bloque "Verificación interactiva de ramas"). Si no se ejecutó, correr `agent-workflow sources` antes de la primera evidencia.
-- Si una fuente está en otra rama, **avisar** explícitamente en `EVIDENCE.md` que el análisis se hizo sobre `<current_branch>` y aclarar el riesgo de divergencia.
-- Para decidir editar código durante la investigación, ver Caso C en `../session/references/branch-verification.md` (no aplica a este skill — es read-only).
-## Cuándo se invoca
-- Composición desde `agent-workflow:session` en `execution` cuando es sesión `analyze` y todavía no existe `EVIDENCE.md` (legacy: `EVIDENCIA.md`).
-- NL: "investigá", "buscar evidencia", "qué dice el código sobre X", "corré la query".
-- Devuelta por `specialty-choose --phase execution` cuando OBJECTIVE menciona análisis/investigación/propuesta/post-mortem.
-## Acción
-Producir `.workflow/sessions/<folder>/EVIDENCE.md` + opcionalmente `queries/*.sql`.
-### Estructura de EVIDENCE.md
-```markdown
-# Evidence — sessionNNN-analyze-<slug>
-## Original question
-[Copiar `## Question` del OBJECTIVE.md.]
-## Sources consulted
-- Código: <repo+path/file.java líneas X-Y>
-- Logs: <archivo o sistema>
-- BD (<mcp-cert> / <mcp-prod>): <queries en queries/>
-- Git history: <commits relevantes con SHA y fecha>
-- Refs externas: <links si aplica>
-## Raw finding 1: <título>
-- **Qué se observó**: ...
-- **Dónde**: <link/path>
-- **Cuándo**: <fecha si aplica>
-## Raw finding 2: ...
-## Notes / tentative hypotheses
-- [hipótesis sin compromiso, para revisar en analyze-synthesize]
-```
-### Lectura estructurada del OBJECTIVE
-Para extraer la pregunta original sin leer todo el archivo:
-```
-agent-workflow objetivo-data --code <CODE>
-```
-Devuelve `{titulo, tipo, modalidad, brief, criterios_aceptacion, fuentes_mencionadas, origen}`. El `brief` aplica como "Original question" para sesiones analyze. El comando lee tanto `OBJECTIVE.md` (canónico EN) como `OBJETIVO.md` (legacy ES) vía bilingual readers de R1.
-### Reglas para queries (modalidad=datos o tecnica con datos)
-- **Read-only siempre**: SELECT, no DML. Los MCP servers `<mcp-cert>` y `<mcp-prod>` lo enforcan a nivel server.
-- **Guardar en `.workflow/sessions/<folder>/queries/NNN-<slug>.sql`** con header:
-  ```sql
-  -- Query: <propósito>
-  -- Server: <mcp-cert> | <mcp-prod>
-  -- Fecha: 2026-04-26
-  -- Sesión: sessionNNN-analyze-<slug>
-  -- Costo estimado: <filas|N/A>; índices usados: <lista|none>
-  ```
-- **Numerar secuencialmente** por orden de ejecución.
-- **Resultado resumido en EVIDENCE.md**, no el dump completo (puede ser MB).
-### Cost guard — antes de ejecutar (v1.1+)
-Las queries contra `<mcp-cert>` / `<mcp-prod>` tienen costo real (latencia, I/O, hold de conexión). Aplicar el cost guard antes de cualquier query no-trivial.
-**Resumen de categorías**:
-- **Barata**: COUNT(*) ≤ 1.000 filas o PK lookup → ejecutar directo.
-- **Moderada**: 1.000-10.000 filas o seq scan sobre tabla pequeña → avisar al usuario tamaño + duración estimada antes.
-- **Costosa**: > 10.000 filas o seq scan sobre >100k → **confirmación explícita** del usuario antes.
-- **Bloqueada**: UPDATE/INSERT/DELETE → refusarse.
-Procedimiento completo (4 pasos: estimar tamaño con COUNT(*) + EXPLAIN; clasificar; aviso al usuario con formatos exactos; registrar costo real en header) + excepciones permitidas + anti-patrones en **`references/cost-guard.md`**.
-### Reglas para lectura de código
-- Usar `Grep` y `Read` extensivamente. NUNCA `Edit/Write` durante investigate (read-only).
-- Citar paths con líneas: `mscore-solicitud-spring/src/main/java/.../Foo.java:142`.
-- Si el código está disperso, usar `Glob` + `Grep` para zoom.
-### Reglas para logs y git history
-- Logs: si hay acceso (SSH o herramienta del proyecto), describir la query/comando. Capturar timestamps relevantes.
-- Git: `git log --oneline --since="<fecha>" -- <path>` para acotar. Capturar SHA + fecha + autor + mensaje. Si modalidad=incidente, capturar commit "culpable" destacado.
-- **Solo git read-only**: `log`, `show`, `diff`, `blame`, `branch --show-current`. NUNCA ejecutar `git commit`/`push`/`merge`/`rebase`/`tag`/`reset --hard`/`checkout` durante investigate. Ver `agent-workflow:commits-policy`.
-## Loop de investigación
-```
-[hipótesis] → [buscar evidencia] → [actualizar EVIDENCE.md] → [nueva hipótesis o convergencia]
-                                           ↓
-                                  [→ analyze-synthesize cuando hay suficiente]
-```
-Iterar hasta material suficiente para sintetizar.
-## Reglas
-- **NO juzgar durante investigate**: capturar lo que es, no lo que "debería ser". El juicio viene en `analyze-synthesize`.
-- **Sin escribir código**: read-only. NUNCA Edit/Write durante investigate.
-- **Honest about gaps**: si una fuente no está disponible, declararlo en EVIDENCE.
-- **Sospechar de la pregunta original**: si surge evidencia que sugiere que la pregunta del OBJECTIVE está mal formulada, marcarlo en "Notes / tentative hypotheses".
-## Composición con otras skills
-| Skill | Cuándo |
-|---|---|
-| `analyze-synthesize` | siguiente paso una vez EVIDENCE tiene material suficiente |
-| `analyze-conclude` | después de synthesize, produce CONCLUSIONS.md modulado por modalidad (technical/incident/data) |
-## Sandbox read-only
-`../session/references/sandbox-readonly-rules.md` (canon). En plan mode describe en el plan file:
-- **Paths destino**: `.workflow/sessions/<folder>/EVIDENCE.md` + `queries/*.sql`.
-- **Fuentes a consultar**: archivos de código (paths), tablas BD (schema + nombre), logs/dashboards (con ventanas), git history.
-- **Queries propuestas**: lista con SELECT + tabla + ventana + costo estimado. Marcar costosas para que decida el usuario.
-- **Estructura de EVIDENCE.md**: hallazgos crudos sin sintetizar.
-NO ejecuta: queries MCP (aunque sean read-only — respetar plan mode), `Read` está permitido pero limitado a navegación, `Write` sobre EVIDENCE.md o queries/.
-## Recursos
-- **`references/cost-guard.md`** — protocolo completo de cost guard (4 pasos + excepciones + anti-patrones).
-- MCP servers `<mcp-cert>` y `<mcp-prod>` — read-only por server config.
-- shared-contract §14 — fase execution del lifecycle universal.

package/skills/agent-workflow/specialties/analyze-investigate/references/cost-guard.md DELETED Viewed

@@ -1,85 +0,0 @@
-# Cost guard — protocolo para queries MCP
-Antes de ejecutar `mcp__plugin_developer-workflow_qtc-{cert,prod}__execute_sql` con cualquier query no-trivial, aplicar este guard. Las queries contra `<mcp-cert>` / `<mcp-prod>` tienen costo real (latencia, I/O, hold de conexión).
-## Paso 1 — estimar tamaño antes de ejecutar la query principal
-Para queries que NO son `SELECT 1`, `LIMIT 1`, ni `WHERE pk = literal`:
-```sql
--- Estimación 1: cuántas filas esperar
-SELECT COUNT(*) FROM <tabla principal> WHERE <filtros>;
--- Estimación 2: peek a estructura (1 fila)
-SELECT * FROM <tabla principal> WHERE <filtros> LIMIT 1;
-```
-Si soporta `EXPLAIN`:
-```sql
-EXPLAIN (FORMAT TEXT) <query principal>;
-```
-Leer el plan: índices usados, tipo de scan (seq scan vs index scan), filas estimadas (`rows=`).
-## Paso 2 — clasificar costo
-| Categoría | Criterios | Acción |
-|---|---|---|
-| **Barata** | COUNT(*) ≤ 1.000 filas; PK lookup; EXPLAIN dice index scan | Ejecutar directamente. Documentar tamaño real en query header. |
-| **Moderada** | COUNT(*) entre 1.000 y 10.000; seq scan sobre tabla pequeña (<100k); JOIN con todos índices | Avisar al usuario el tamaño + duración estimada. Ejecutar si no objeta. |
-| **Costosa** | COUNT(*) > 10.000; JOIN sin índice; seq scan sobre >100k; ventana > 90 días sobre tabla activa | **Confirmación EXPLÍCITA** antes de ejecutar. Sugerir LIMIT, filtros, sample. |
-| **Bloqueada** | UPDATE/INSERT/DELETE detectado; lock fuerte (FOR UPDATE) | Refusarse. MCP enforcan; el AI tampoco intenta. |
-## Paso 3 — formato de aviso al usuario
-### Moderada (antes de ejecutar)
-```
-La query estimada toca ~5.200 filas (EXPLAIN: index scan sobre idx_solicitud_fecha,
-ventana 30 días). Tiempo esperado <2s. Ejecuto?
-```
-### Costosa
-**Dispara `AskUserQuestion`** con spec de C2 (`agent-workflow:prompts-catalog#C2`). Header `cost`, 2 opciones canónicas (Proceder / Cancelar) + preview ASCII obligatorio con el SQL y el plan EXPLAIN resumido. NO narrar la pregunta en texto plano (anti-patrón histórico: bloque "(a)/(b)/(c)/(d) — Decidí" como input libre).
-Plantilla del preview:
-```
-⚠ Query potencialmente costosa
-  COUNT(*) estimado: ~85.000 filas
-  EXPLAIN: seq scan sobre solicitud (sin índice para WHERE estado='X')
-  Sin LIMIT — Servidor: <mcp-prod>
-SQL:
-  SELECT * FROM solicitud WHERE estado = 'X' ORDER BY fecha DESC;
-```
-Si el usuario activa el Other auto-inyectado puede pedir variantes (LIMIT, sample por mod(id,N), filtros adicionales) en texto libre — el AI reformula la query y vuelve a aplicar el guard sobre la versión revisada antes de ejecutar.
-NO ejecutar la versión costosa sin confirmación explícita, aunque el usuario haya autorizado queries genéricas en la sesión.
-## Paso 4 — registrar el costo real
-Tras ejecutar, agregar al header del archivo SQL:
-```sql
--- Costo real: <filas devueltas> filas en <duración>; servidor=<cert|prod>
-```
-Esto cierra el loop: la próxima sesión que toque la misma tabla tiene referencia.
-## Excepciones permitidas (sin guard explícito)
-- `SELECT 1` y healthchecks.
-- `SELECT * FROM <tabla> WHERE <pk> = <valor>` (PK lookup determinístico).
-- Queries contra `information_schema` / `pg_catalog` (metadata, casi gratis).
-- Re-ejecución de una query que ya tenía guard documentado en una sesión previa.
-## Anti-patrones
-- **`SELECT * FROM tabla` sin WHERE**: nunca, salvo confirmación con `(a)` arriba.
-- **JOIN cartesiano accidental**: revisar siempre que cada JOIN tenga ON con clave indexada.
-- **Loop de queries pequeñas**: si vas a correr 50 queries similares, 1 query con `IN (...)` o `JOIN` es preferible. Documentar la decisión.
-- **Saltarse el guard porque "es solo cert"**: cert también tiene costo y se comparte con otros equipos.

package/skills/agent-workflow/specialties/analyze-synthesize/SKILL.md DELETED Viewed

@@ -1,127 +0,0 @@
----
-name: analyze-synthesize
-description: Estructura información en un plan accionable. Skill CLAVE invocada por agent-workflow:session durante la fase planning para descomponer el OBJECTIVE en TASKS.md (cuando auto-plan dice `lite` o `full`). También se invoca durante execution para sintetizar FINDINGS.md a partir de evidencia recolectada por analyze-investigate. Output siempre estructurado con criterios + dependencias + ordenamiento.
-version: 1.1.0
----
-# analyze-synthesize — qtc v1.1+
-Specialty skill **analyze**: estructura información de manera accionable. Doble rol:
-1. **En `planning`** (uso primario): descompone OBJECTIVE en TASKS.md cuando `agent-workflow auto-plan-decide` retorna `lite` o `full`. La invoca `agent-workflow:session` directamente.
-2. **En `execution`** (analyze-only): sintetiza FINDINGS.md a partir de EVIDENCE.md después de `analyze-investigate`.
-Es la **skill más importante** del flow=analyze porque participa en planning de TODOS los flows (no solo analyze).
-## Cuándo se invoca
-- **Composición desde `agent-workflow:session` en planning** cuando `auto-plan-decide` retorna `lite` o `full`.
-- **Composición en sesión analyze en execution** después de `analyze-investigate` cuando hay evidencia que organizar.
-- NL del usuario: "estructurá el plan", "organizá los hallazgos", "armá las tareas".
-- Devuelta por `specialty-choose --phase planning`.
-## Acción: estructurar plan (uso primario, planning)
-Output: `.workflow/sessions/<folder>/TASKS.md` con descomposición ordenada.
-### Estructura canónica de TASKS.md
-```markdown
-# Tasks — sessionNNN-<flow>-<slug>
-## Plan summary
-[1-2 oraciones: qué se va a hacer, en qué orden, criterio de hecho.]
-## Tasks
-- [ ] **T1**: <título imperativo> — <criterio: cómo sé que está hecha>
-  - Depende de: ninguna
-  - Estima: <S|M|L>
-- [ ] **T2**: <título> — <criterio>
-  - Depende de: T1
-  - Estima: <S|M|L>
-- [ ] **T3**: ... — <criterio>
-  - Depende de: T1
-  - Estima: <S|M|L>
-## Risks / external dependencies
-- <riesgo 1: qué podría romper la ejecución, mitigación>
-```
-### Reglas de estructuración
-- **3-7 tareas para `full`**, 1-3 para `lite`. Si exceden 7, agrupar.
-- **Cada tarea con criterio de hecho explícito** (no solo título).
-- **Dependencias declaradas** — el AI puede paralelizar tareas independientes.
-- **Estima S|M|L** orientativa: S = <30min, M = 30min-2h, L = 2-8h. Si una L se acerca a 8h, considerá descomponer.
-- **No prescribir solución técnica acá** — la decisión de "cómo" se toma durante execution con la specialty correspondiente (implement, design-deliver, etc.).
-## Acción: sintetizar hallazgos (analyze execution)
-Output: `.workflow/sessions/<folder>/FINDINGS.md` (legacy: `HALLAZGOS.md`).
-```markdown
-# Findings — sessionNNN-analyze-<slug>
-## Patterns identified
-- **Patrón A**: <qué+por qué+evidencia (link a EVIDENCE.md sección)>
-## False positives discarded
-- **<hipótesis descartada>**: por qué no aplica, evidencia.
-## Model decision
-[Cuál modelo / hipótesis explica mejor los datos. 1-2 párrafos.]
-## What is NOT known (gaps)
-- <pregunta abierta que requeriría más investigación>
-```
-### Reglas de síntesis
-- **Toda afirmación con evidencia**: link al `EVIDENCE.md#section` o al artefacto (query, screenshot, log).
-- **Honest gaps**: lo que no se pudo probar o quedó incierto, declararlo. No inventar.
-- **Convergencia**: el output debe ser una historia coherente, no un dump.
-- **Próximo paso**: FINDINGS termina apuntando a `analyze-conclude` (produce CONCLUSIONS.md modulado por `## Modality`).
-## Reglas
-- **Sin imaginación creativa**: este skill es estructurador, no inventor. Trabaja con lo que el OBJECTIVE o EVIDENCE ya dice.
-- **Single source of truth**: el TASKS.md es la fuente de qué se va a hacer; el FINDINGS.md es la fuente de qué se sabe. Otros artefactos (DECISIONS, CONCLUSIONS) referencian, no duplican.
-- **Idempotente**: re-invocar sobre TASKS.md existente refina, no recrea.
-- **No commits autónomos**: ver `agent-workflow:commits-policy`. Synthesize escribe TASKS/FINDINGS pero nunca commitea.
-## Composición con otras skills
-| Skill | Cuándo |
-|---|---|
-| `analyze-investigate` | en analyze sessions, EVIDENCE antes de sintetizar |
-| `analyze-conclude` | siguiente paso en analyze sessions; produce CONCLUSIONS.md modulado por `## Modality` (technical/incident/data) |
-| `agent-workflow:session` | invoca este skill en planning de cualquier flow |
-## Sandbox read-only
-Reglas universales en el canon (`sandbox-readonly-rules.md`). En plan mode esta skill describe en el plan file el output según el rol:
-- **Rol planning** (invocado por `agent-workflow:session` durante phase planning):
-  - **Path destino**: `.workflow/sessions/<folder>/TASKS.md`.
-  - **Items propuestos** (≥3 si auto-plan = `full`, 1-3 si `lite`): cada uno con título, criterio de aceptación, dependencias (orden), estimación de esfuerzo.
-  - Sugerencias de skills a invocar para cada item (sin invocarlas).
-- **Rol execution** (sesiones analyze, sintetizar evidencia):
-  - **Path destino**: `.workflow/sessions/<folder>/FINDINGS.md`.
-  - **Estructura**: hallazgo principal, sub-hallazgos numerados, conexiones entre ellos, gaps (qué falta investigar).
-  - Origen de cada hallazgo: link al item de EVIDENCE.md (sin re-pegar el contenido).
-NO ejecuta: `Write` sobre TASKS.md ni FINDINGS.md.
-## Recursos
-- shared-contract §14 — fase planning del lifecycle universal.
-- shared-contract §15 — naming convention specialty skills.
-- shared-contract §19 — auto-plan trigger heurística (cuándo invocar este skill).

package/skills/agent-workflow/specialties/design-brief/SKILL.md DELETED Viewed

@@ -1,90 +0,0 @@
----
-name: design-brief
-description: Capta el brief inicial de una sesión de diseño y declara el `## Type` (project|system). Invocado desde la fase planning del lifecycle universal de agent-workflow cuando el OBJECTIVE menciona UI/UX/diseño/pantalla/mockup/wireframe. Produce OBJECTIVE.md con secciones Type, Brief, Context y Acceptance criteria. No produce código ni mocks aún — sólo capturar QUÉ y POR QUÉ.
-version: 1.1.0
----
-# design-brief — agent-workflow v1.0+
-Specialty skill **design**: capta el brief y el tipo de sesión durante la fase `planning` del lifecycle universal.
-## Cuándo se invoca
-- Composición desde `agent-workflow:session` en `planning` cuando el OBJECTIVE menciona UI/UX/diseño/pantalla/mockup/wireframe/layout/forma.
-- Devuelta por `agent-workflow specialty-choose --phase planning` si el OBJECTIVE incluye keywords de design.
-- NL del usuario: "abrí una sesión de diseño", "vamos a diseñar X", "necesito un mock de Y".
-## Pre-requisitos
-1. Bloque AW-PROJECT presente. Si no → proponer `/agent-workflow:project-init`.
-2. Sesión nueva (o existente sin OBJECTIVE completo).
-## Acción
-### 1. Pedir al usuario
-| Campo | Tipo | Ejemplos |
-|---|---|---|
-| **Type** | `project` \| `system` (legacy ES: `proyecto`/`sistema`) | `project` = pantalla/mantenimiento concreto. `system` = tokens/componentes compartidos. |
-| **Nombre** | slug-kebab ≤4 palabras | `mock-lista-negra`, `tokens-spacing`, `wizard-nuevo-cliente` |
-| **Brief corto** | 1-3 oraciones | quién (rol/usuario), qué problema, constraints clave |
-| **Acceptance criteria** | lista | cómo sabemos que la sesión cumple su objetivo |
-Si el OBJECTIVE no declara `## Type`, **dispara `AskUserQuestion`** con spec de S1 (`agent-workflow:prompts-catalog#S1`). Header `design-type`, 2 opciones (Project / System). Si el usuario activa el Other auto, pedir clarificación libre y NO inferir el type desde el texto — la sesión queda sin type hasta que el usuario lo declare.
-NO narrar la pregunta en texto plano (ej. "¿Esto es proyecto o sistema?" en chat es un anti-patrón).
-### 2. Crear sesión
-```
-agent-workflow session-create \
-    --name <slug> \
-    --objetivo "<brief>" \
-    --type <project|system>
-```
-Crea `.workflow/sessions/sessionNNN-design-<slug>/OBJECTIVE.md` con `## Type` + `## Brief` pre-cargados. Las flags legacy `--tipo proyecto|sistema` siguen aceptadas y se normalizan a EN.
-### 3. Iterar el brief si hace falta
-Si el brief es vago o ambiguo:
-- 1-2 preguntas de clarificación (no más).
-- Editar OBJECTIVE.md (legacy: OBJETIVO.md) con la versión refinada.
-- Confirmar con el usuario antes de avanzar.
-### 4. Hand-off a planning del lifecycle universal
-Reportar al `agent-workflow:session` que el brief está cerrado y el plan structurado puede empezar (si auto-plan dice `full` o `lite`). Para `type=system`, plan suele ser `lite` (tareas predecibles); para `type=project`, suele ser `full` (criterios + variantes).
-## Reglas
-- **Spec-only**: NO escribir código. NO escribir mocks aún (eso es design-develop).
-- **Type es obligatorio**: sin `Type` no se crea la sesión. Convención shared-contract §11.
-- **Brief corto**: si el usuario quiere extender, hacerlo en `## Context` o en `DISCOVERY.md` (más adelante).
-- **No asumir framework de UI**: el brief habla del problema, no de Angular/React/Bootstrap. Eso lo decide el flow=dev al implementar.
-## Composición con otras skills
-| Skill | Cuándo |
-|---|---|
-| `design-discover` | siguiente paso, en fase `execution` (investigación de usuarios/flows/sistema existente) |
-| `design-develop` | divergencia/convergencia de soluciones, en `execution` |
-| `design-deliver` | spec final, al cerrar `execution` antes de `validation` |
-| `frontend-design` | reglas agnósticas de UI (form/list/modal/navigation/feedback) — referenciar pero no invocar acá |
-## Sandbox read-only
-Reglas universales en el canon (`sandbox-readonly-rules.md`). En plan mode esta skill describe en el plan file:
-- Campos a pedir al usuario para capturar el brief: nombre/slug, Type (`project`|`system`; legacy ES aceptado), Brief, Context, Acceptance criteria, Inspiración.
-- Que el OBJECTIVE.md se crearía a partir del template `objetivo-design.md` (interno del CLI) con esos campos.
-- Que `agent-workflow session-create` se invocaría — pero NO se ejecuta hasta salir de plan mode.
-NO ejecuta: `agent-workflow session-create`, `Write` sobre OBJECTIVE.md.
-## Recursos
-- shared-contract §11 — convención `## Type` (project|system; legacy ES `proyecto`/`sistema`).
-- shared-contract §14 — fase planning del lifecycle universal.
-- `agent-workflow:prompts-catalog#S1` — spec literal del prompt design-type (header, opciones, manejo del Other).
-- skill `frontend-design` — principios de UI agnósticos del framework.

package/skills/agent-workflow/specialties/design-deliver/SKILL.md DELETED Viewed

@@ -1,121 +0,0 @@
----
-name: design-deliver
-description: Spec final estable para handoff al flow=dev. Componentes, estados, validaciones, tokens aplicados, decisiones UX racionalizadas. Sin código. Produce DELIVERY.md como entregable canónico (referenciado por handoff `--from design:NNN`). Invocado al final de execution cuando design-develop convergió en una variante elegida.
-version: 2.2.0
----
-# design-deliver — qtc v2.1+
-Specialty skill **design**: producción del spec final. Cierre creativo de `execution` antes de pasar a `validation`.
-## Cuándo se invoca
-- Composición desde `agent-workflow:session` al final de `execution` cuando design-develop convergió.
-- NL del usuario: "spec final", "armá el entregable", "vamos a deliverable", "cerrá el diseño".
-## Acción
-Producir `.workflow/sessions/<folder>/DELIVERY.md` (legacy: `ENTREGA.md`) con el spec completo + canónico para handoff al flow=dev.
-### Estructura canónica de DELIVERY.md
-```markdown
-# Delivery — sessionNNN-design-<slug>
-## Summary
-[2-3 oraciones del qué y para quién. Esto es el TL;DR del handoff.]
-## Components
-### <Component 1>
-- Type: form | list | modal | navigation | feedback | custom
-- States: idle | loading | error | success | disabled | …
-- Validations (if form): [lista]
-- Tokens applied: spacing.md, color.danger, font.body
-- UX rules: [shortcuts, accesibilidad, responsive]
-- Mock: docs/referencias/<nombre>.png o link Figma
-### <Component 2>
-- ...
-## Flows / interactions
-1. [paso 1]
-2. [paso 2]
-3. ...
-## UX decisions
-- [decisión clave + por qué + qué se descartó]
-## Tokens / design-system applied
-- (sólo si type=project): listar tokens consumidos del DS.
-- (si type=system): listar tokens NUEVOS o MODIFICADOS, con migration impact.
-## Validation criteria
-- [cómo dev sabrá que la implementación cumple el spec]
-## Out of scope
-- [qué NO se implementa en este spec, para evitar scope creep en la sesión dev]
-```
-## Reglas
-- **Sin código**: DELIVERY.md es markdown puro + referencias a mocks/Figma. El código lo escribe el flow=dev.
-- **Componentes referenciados a frontend-design**: si un componente es una variante estándar, citar `frontend-design references/<patron>.md`. Si es nuevo/custom, especificarlo entero.
-- **Estados explícitos**: cada componente declara TODOS sus estados (no asumir que el dev los infiere).
-- **Validaciones con regex/longitud/required cuando aplica**: el dev no inventa.
-- **Out of scope explícito**: cierra puertas; evita feature creep.
-- **Si type=system**: DELIVERY.md describe los CAMBIOS al design system (delta + migration), no una pantalla. La distinción `## Type: project|system` queda como metadato interno del documento; **no** afecta la carpeta de graduación (todo va a `docs/especificaciones/` — path canónico ES preservado por compat con sesiones legacy).
-- **No commits autónomos**: design-deliver **nunca** commitea DELIVERY.md ni `docs/referencias/` por iniciativa. Ver `agent-workflow:commits-policy` (Regla 3): cuando el usuario solicita un commit — closure auto, ad-hoc en cualquier fase, o sin sesión activa — el AI invoca el flujo M1 propose-then-execute con `AskUserQuestion`.
-## Loop hasta convergencia final
-Después del primer draft de DELIVERY.md:
-1. Mostrar al usuario.
-2. Recibir feedback.
-3. Iterar sobre el archivo (Edit, no recreación).
-4. Repetir hasta el usuario confirme: "OK, podemos handoff".
-## Hand-off al flow=dev (post-cierre de la sesión design)
-Cuando la sesión cierre, DELIVERY.md se gradúa a `docs/especificaciones/NNN-<slug>/DELIVERY.md` (kind=`especificacion`, modelo nuevo DEC-003). Sin distinción project/system en la carpeta destino — la distinción queda como `## Type` interno del documento. La carpeta destino conserva el nombre español `docs/especificaciones/` por compatibilidad con paths existentes en sesiones legacy.
-Destino según workspace_mode (DEC-002):
-- **hub mode** → `<hub>/docs/especificaciones/NNN-<slug>/DELIVERY.md`.
-- **project mode** → `<cwd>/docs/especificaciones/NNN-<slug>/DELIVERY.md`.
-```
-/agent-workflow:session --from design:<code> "<objetivo de implementación>"
-```
-El OBJECTIVE de la sesión dev quedará con `## Origin` linkeado al `DELIVERY.md` y tag `origen:design-NNN` en HISTORY.md (shared-contract §10).
-## Composición con otras skills
-| Skill | Cuándo |
-|---|---|
-| `design-develop` | si el feedback del usuario invalida la convergencia, retroceder |
-| `frontend-design` | para validar que cada componente referenciado existe en patterns |
-## Sandbox read-only
-Reglas universales en el canon (`sandbox-readonly-rules.md`). En plan mode esta skill describe en el plan file:
-- **Path destino** del DELIVERY.md: `.workflow/sessions/<folder>/DELIVERY.md`.
-- **Esqueleto propuesto**: secciones (Summary, Components, States, Tokens applied, Variants, Validation criteria, Hand-off a dev), longitud aproximada por sección.
-- **Referencias del usuario**: lista de archivos en `<workspace-root>/docs/referencias/` (mockups, especificaciones de tokens, exportes que el usuario provea), con formato y propósito. Carpeta transversal — DEC-004 v2. **El AI no escribe ahí salvo solicitud explícita**.
-- **Type declarado** en OBJECTIVE: `project` o `system` (legacy ES `proyecto`/`sistema` se normaliza). Metadato interno del documento. En cualquier caso gradúa a `docs/especificaciones/` (kind=`especificacion`). Si falta, plan dice "preguntar al usuario".
-NO ejecuta: `Write` sobre DELIVERY.md ni `docs/referencias/`; `agent-workflow graduate --kind especificacion`.
-## Recursos
-- skill `frontend-design` — patterns canónicos para referenciar.
-- shared-contract §10 — handoff `--from design:<code>`.
-- shared-contract §11 — convención `## Type` (afecta destino de graduación).
-- shared-contract §14 — fase execution del lifecycle universal.