@tacuchi/agent-workflow-cli 12.10.0 → 13.0.0

package/dist/domain/skills.d.ts

@@ -4,8 +4,15 @@
  * A loop composes a CAPABILITY by its role (e.g. "ui-design"), not a concrete
  * skill. The role → skill binding is resolved from `skills.toml`
  * (cascade: built-in default → global → workspace). See skills-resolver-service.
+ *
+ * Only WORKFLOW-SPECIFIC capabilities are roles here. Generic, stack-agnostic
+ * conventions (coding standards, testing strategy, technical writing) are NOT
+ * roles: they live as standalone skills the host auto-discovers by `description`
+ * and applies whenever relevant. The workflow stays indifferent — it never reads
+ * or binds a specific convention skill; the host surfaces any useful one that is
+ * installed (e.g. from the `dev-conventions` marketplace plugin, or anywhere).
  */
-export declare const SKILL_ROLES: readonly ["ui-design", "sql", "git", "coding-standards", "writing", "research", "testing", "tools", "diagrams", "overview"];
+export declare const SKILL_ROLES: readonly ["ui-design", "sql", "git", "research", "tools", "diagrams", "overview"];
 export type SkillRole = (typeof SKILL_ROLES)[number];
 /** Built-in default skill name for each capability role. */
 export declare const BUILTIN_DEFAULT_SKILLS: Record<SkillRole, string>;

package/dist/domain/skills.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"skills.d.ts","sourceRoot":"","sources":["../../src/domain/skills.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AACH,eAAO,MAAM,WAAW,6HAWd,CAAC;AAEX,MAAM,MAAM,SAAS,GAAG,CAAC,OAAO,WAAW,CAAC,CAAC,MAAM,CAAC,CAAC;AAErD,4DAA4D;AAC5D,eAAO,MAAM,sBAAsB,EAAE,MAAM,CAAC,SAAS,EAAE,MAAM,CAW5D,CAAC;AAEF,MAAM,MAAM,kBAAkB,GAAG,SAAS,GAAG,QAAQ,GAAG,WAAW,CAAC;AAEpE,MAAM,WAAW,aAAa;IAC5B,IAAI,EAAE,SAAS,CAAC;IAChB,uEAAuE;IACvE,KAAK,EAAE,MAAM,GAAG,IAAI,CAAC;IACrB,MAAM,EAAE,kBAAkB,CAAC;IAC3B,OAAO,EAAE,OAAO,CAAC;CAClB;AAED,MAAM,MAAM,cAAc,GAAG,MAAM,CAAC,SAAS,EAAE,aAAa,CAAC,CAAC;AAI9D,wBAAgB,WAAW,CAAC,KAAK,EAAE,MAAM,GAAG,KAAK,IAAI,SAAS,CAE7D"}
+{"version":3,"file":"skills.d.ts","sourceRoot":"","sources":["../../src/domain/skills.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AACH,eAAO,MAAM,WAAW,mFAQd,CAAC;AAEX,MAAM,MAAM,SAAS,GAAG,CAAC,OAAO,WAAW,CAAC,CAAC,MAAM,CAAC,CAAC;AAErD,4DAA4D;AAC5D,eAAO,MAAM,sBAAsB,EAAE,MAAM,CAAC,SAAS,EAAE,MAAM,CAQ5D,CAAC;AAEF,MAAM,MAAM,kBAAkB,GAAG,SAAS,GAAG,QAAQ,GAAG,WAAW,CAAC;AAEpE,MAAM,WAAW,aAAa;IAC5B,IAAI,EAAE,SAAS,CAAC;IAChB,uEAAuE;IACvE,KAAK,EAAE,MAAM,GAAG,IAAI,CAAC;IACrB,MAAM,EAAE,kBAAkB,CAAC;IAC3B,OAAO,EAAE,OAAO,CAAC;CAClB;AAED,MAAM,MAAM,cAAc,GAAG,MAAM,CAAC,SAAS,EAAE,aAAa,CAAC,CAAC;AAI9D,wBAAgB,WAAW,CAAC,KAAK,EAAE,MAAM,GAAG,KAAK,IAAI,SAAS,CAE7D"}

package/dist/domain/skills.js

@@ -4,15 +4,19 @@
  * A loop composes a CAPABILITY by its role (e.g. "ui-design"), not a concrete
  * skill. The role → skill binding is resolved from `skills.toml`
  * (cascade: built-in default → global → workspace). See skills-resolver-service.
+ *
+ * Only WORKFLOW-SPECIFIC capabilities are roles here. Generic, stack-agnostic
+ * conventions (coding standards, testing strategy, technical writing) are NOT
+ * roles: they live as standalone skills the host auto-discovers by `description`
+ * and applies whenever relevant. The workflow stays indifferent — it never reads
+ * or binds a specific convention skill; the host surfaces any useful one that is
+ * installed (e.g. from the `dev-conventions` marketplace plugin, or anywhere).
  */
 export const SKILL_ROLES = [
     "ui-design",
     "sql",
     "git",
-    "coding-standards",
-    "writing",
     "research",
-    "testing",
     "tools",
     "diagrams",
     "overview",
@@ -22,10 +26,7 @@ export const BUILTIN_DEFAULT_SKILLS = {
     "ui-design": "ui-spec",
     sql: "sql",
     git: "git",
-    "coding-standards": "coding-standards",
-    writing: "writing",
     research: "research",
-    testing: "testing",
     tools: "tools",
     diagrams: "diagrams",
     overview: "workflow",

package/dist/domain/skills.js.map

@@ -1 +1 @@
-{"version":3,"file":"skills.js","sourceRoot":"","sources":["../../src/domain/skills.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,WAAW,GAAG;IACzB,WAAW;IACX,KAAK;IACL,KAAK;IACL,kBAAkB;IAClB,SAAS;IACT,UAAU;IACV,SAAS;IACT,OAAO;IACP,UAAU;IACV,UAAU;CACF,CAAC;AAIX,4DAA4D;AAC5D,MAAM,CAAC,MAAM,sBAAsB,GAA8B;IAC/D,WAAW,EAAE,SAAS;IACtB,GAAG,EAAE,KAAK;IACV,GAAG,EAAE,KAAK;IACV,kBAAkB,EAAE,kBAAkB;IACtC,OAAO,EAAE,SAAS;IAClB,QAAQ,EAAE,UAAU;IACpB,OAAO,EAAE,SAAS;IAClB,KAAK,EAAE,OAAO;IACd,QAAQ,EAAE,UAAU;IACpB,QAAQ,EAAE,UAAU;CACrB,CAAC;AAcF,MAAM,QAAQ,GAAwB,IAAI,GAAG,CAAC,WAAW,CAAC,CAAC;AAE3D,MAAM,UAAU,WAAW,CAAC,KAAa;IACvC,OAAO,QAAQ,CAAC,GAAG,CAAC,KAAK,CAAC,CAAC;AAC7B,CAAC"}
+{"version":3,"file":"skills.js","sourceRoot":"","sources":["../../src/domain/skills.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AACH,MAAM,CAAC,MAAM,WAAW,GAAG;IACzB,WAAW;IACX,KAAK;IACL,KAAK;IACL,UAAU;IACV,OAAO;IACP,UAAU;IACV,UAAU;CACF,CAAC;AAIX,4DAA4D;AAC5D,MAAM,CAAC,MAAM,sBAAsB,GAA8B;IAC/D,WAAW,EAAE,SAAS;IACtB,GAAG,EAAE,KAAK;IACV,GAAG,EAAE,KAAK;IACV,QAAQ,EAAE,UAAU;IACpB,KAAK,EAAE,OAAO;IACd,QAAQ,EAAE,UAAU;IACpB,QAAQ,EAAE,UAAU;CACrB,CAAC;AAcF,MAAM,QAAQ,GAAwB,IAAI,GAAG,CAAC,WAAW,CAAC,CAAC;AAE3D,MAAM,UAAU,WAAW,CAAC,KAAa;IACvC,OAAO,QAAQ,CAAC,GAAG,CAAC,KAAK,CAAC,CAAC;AAC7B,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tacuchi/agent-workflow-cli",
-  "version": "12.10.0",
+  "version": "13.0.0",
   "description": "Agnostic runtime CLI for AI development workflows — a stages + loops + artifacts harness. Bundles the universal `w` skill set under `skills/w/` (slash commands `/w:*`: spec-new/spec-refine, plan-new/plan-exec, quick, workspace-init, export-*); `self install --target <host>` copies SKILL + commands + hooks into the host. Pluggable capability skills via `.workflow/skills.toml`. Multi-empresa parametrization via `profile.json` cascade. Namespace auto-detected from any `.<ns>/sessions/` dir in CWD; default `workflow`.",
   "type": "module",
   "bin": {

package/skills/w/SKILL.md

@@ -133,9 +133,8 @@ Un loop **no** compone una skill concreta; compone una **capacidad por su rol**
 ui-design        = "ui-spec"          # built-in default
 sql              = "sql"
 git              = "git"
-coding-standards = "coding-standards"
-writing          = "writing"
-testing          = "off"              # capacidad desactivada
+research         = "research"
+# diagrams       = "off"              # ← capacidad desactivada
 # ui-design      = "acme/figma-spec"  # ← skill de tercero (vía skills.sh)
 ```
 
@@ -148,14 +147,13 @@ Catálogo de roles y su default:
 | `ui-design` | `ui-spec` | must | `spec-refine-loop` (UI) |
 | `sql` | `sql` | must | research · `plan-exec-loop` · `quick-loop` · `export-scripts` |
 | `git` | `git` | must | `plan-exec-loop` · `quick-loop` |
-| `coding-standards` | `coding-standards` | must | `plan-exec-loop` · `quick-loop` |
-| `writing` | `writing` | must | todos los loops · `export-manuals`/`export-reports` |
 | `research` | `research` | should | todos los loops (capacidad inline) |
-| `testing` | `testing` | should | `plan-exec-loop` · `quick-loop` |
 | `tools` | `tools` | should | `plan-exec-loop` |
 | `diagrams` | `diagrams` | should | `export-diagrams` |
 | `overview` | `workflow` | should | cualquiera (orientación) |
 
+> **Convenciones ambientes (no roles).** Los estándares de código, testing y redacción **no son roles** del workflow ni se bindean: son **skills standalone que el host auto-descubre por su `description`** y aplica cuando son relevantes. El workflow es **indiferente** (no las lee ni las busca). Una familia útil vive en el plugin `dev-conventions` del marketplace, pero el workflow **no depende** de él.
+
 El **chasis del loop** NO se bindea: **es** el loop, no es enchufable.
 
 ### Harness (agnóstico al arnés)

package/skills/w/exports/README.md

@@ -25,11 +25,11 @@
 | Export | Composes | Reads (artifacts / sessions + corpus) | Writes (its ONLY category) |
 |---|---|---|---|
 | [`export-scripts`](export-scripts/SKILL.md) | `sql` | type-B `SCRIPTS.sql` (DDL/DML migrations) across N sessions + standalone `docs/scripts/*.sql` | `docs/scripts/NNN-export-scripts-<date>/` (numbered forwards + `00-ROLLBACK.sql`) |
-| [`export-manuals`](export-manuals/SKILL.md) | `writing` | sessions + `DECISION` + plan-doc (`Solution`, `Final behavior`, `Validations`) + touched code | `docs/manuals/` |
+| [`export-manuals`](export-manuals/SKILL.md) | — (prosa: convenciones ambientes) | sessions + `DECISION` + plan-doc (`Solution`, `Final behavior`, `Validations`) + touched code | `docs/manuals/` |
 | [`export-diagrams`](export-diagrams/SKILL.md) | `diagrams` | source code of the sources + plan-doc (`AS-IS` / `TO-BE`, `Impacted`) | `docs/diagrams/` (C4 / mermaid) |
-| [`export-reports`](export-reports/SKILL.md) | `writing` | corpus of sessions (spec, `CONCLUSIONS`, `DECISION`) + plan-doc state + `docs/` | `docs/reports/` (executive / functional report) |
+| [`export-reports`](export-reports/SKILL.md) | — (prosa: convenciones ambientes) | corpus of sessions (spec, `CONCLUSIONS`, `DECISION`) + plan-doc state + `docs/` | `docs/reports/` (executive / functional report) |
 
-> **Composition over ownership:** an export does **not** own its authoring logic — it **composes a capability role** from [`../roles/`](../roles/) (resolved through `.workflow/skills.toml`): `export-scripts` composes `sql`; `export-manuals` and `export-reports` compose `writing`; `export-diagrams` composes `diagrams`. Swapping the implementation is a one-line config change; it never touches the export.
+> **Composition over ownership:** an export that owns a derived artifact does **not** own its authoring logic — it **composes a capability role** from [`../roles/`](../roles/) (resolved through `.workflow/skills.toml`): `export-scripts` composes `sql`; `export-diagrams` composes `diagrams`. Swapping the implementation is a one-line config change; it never touches the export. `export-manuals` and `export-reports` produce **prose**, which follows **ambient writing conventions** (the host auto-applies an installed writing skill if present) — they do **not** compose or bind a `writing` role.
 
 ## Common properties
 
@@ -83,6 +83,6 @@ Exports read the corpus through the CLI — **never hard-coded paths**:
 | Export | File | Category | Composes |
 |---|---|---|---|
 | `export-scripts` | [`export-scripts/SKILL.md`](export-scripts/SKILL.md) | `docs/scripts` | `sql` |
-| `export-manuals` | [`export-manuals/SKILL.md`](export-manuals/SKILL.md) | `docs/manuals` | `writing` |
+| `export-manuals` | [`export-manuals/SKILL.md`](export-manuals/SKILL.md) | `docs/manuals` | — (prosa: convenciones ambientes) |
 | `export-diagrams` | [`export-diagrams/SKILL.md`](export-diagrams/SKILL.md) | `docs/diagrams` | `diagrams` |
-| `export-reports` | [`export-reports/SKILL.md`](export-reports/SKILL.md) | `docs/reports` | `writing` |
+| `export-reports` | [`export-reports/SKILL.md`](export-reports/SKILL.md) | `docs/reports` | — (prosa: convenciones ambientes) |

package/skills/w/exports/export-manuals/SKILL.md

@@ -1,21 +1,21 @@
 ---
 name: export-manuals
-description: "Sintetiza manuales técnicos del workspace en `docs/manuals/` consolidando N sesiones (`exec`/`quick`) + `docs/`. Lee de cada sesión el `DECISION` y el plan-doc (`Solution`, `Final behavior`, `Validations`) + el código tocado en las fuentes (cómo opera/funciona lo construido). Dos modos: `complement` (default, sobrescribe `INDEX.md` apuntando a los manuales detectados) y `regenerate` (produce dossier `NNN-export-manuals-YYYY-MM-DD/` con 1 manual por tema). Audiencia: operadores / soporte / onboarding. Read-only/reporte: no commitea ni muta sesiones. Compone la capacidad `writing`. Úsalo para 'manual operativo', 'cómo funciona lo entregado', 'paquete de onboarding técnico', 'índice de manuales'. Invocado por el usuario vía `/w:export-manuals`."
+description: "Sintetiza manuales técnicos del workspace en `docs/manuals/` consolidando N sesiones (`exec`/`quick`) + `docs/`. Lee de cada sesión el `DECISION` y el plan-doc (`Solution`, `Final behavior`, `Validations`) + el código tocado en las fuentes (cómo opera/funciona lo construido). Dos modos: `complement` (default, sobrescribe `INDEX.md` apuntando a los manuales detectados) y `regenerate` (produce dossier `NNN-export-manuals-YYYY-MM-DD/` con 1 manual por tema). Audiencia: operadores / soporte / onboarding. Read-only/reporte: no commitea ni muta sesiones. La prosa sigue las convenciones de redacción ambientes (el host auto-aplica una skill de writing instalada si está presente). Úsalo para 'manual operativo', 'cómo funciona lo entregado', 'paquete de onboarding técnico', 'índice de manuales'. Invocado por el usuario vía `/w:export-manuals`."
 ---
 
 # export-manuals — Manuales técnicos desde sesiones + `docs/`
 
 Genera o refresca manuales de **operación / cómo-funciona / onboarding** en `docs/manuals/`, consolidando lo entregado en N sesiones + el corpus `docs/`. **Read-only / reporte** — no commitea, no muta sesiones ni el código.
 
-> Familia `export-*` (la única vía artefacto→`docs/`). Recicla el espíritu del viejo `export-tech-manuals` (modos complementar/regenerar, `INDEX.md`, dossier por tema), modernizado: `docs/manuals` en inglés, sin modos project/hub, y la prosa la aporta la capacidad `writing` (no una skill propia). Diseño: `docs/referencias/workflow-exports/export-manuals.md`.
+> Familia `export-*` (la única vía artefacto→`docs/`). Recicla el espíritu del viejo `export-tech-manuals` (modos complementar/regenerar, `INDEX.md`, dossier por tema), modernizado: `docs/manuals` en inglés, sin modos project/hub, y la prosa sigue las convenciones de redacción **ambientes** (el host auto-aplica una skill de writing instalada si está presente), no un rol propio. Diseño: `docs/referencias/workflow-exports/export-manuals.md`.
 
 ## Category
 
 `docs/manuals` — **única** carpeta `docs/` que este export escribe.
 
-## Composes
+## Writing (convención ambiente, no rol)
 
-Capacidad **`writing`** (built-in default `writing`), resuelta vía `.workflow/skills.toml`. Aporta la redacción accionable (frases cortas, listas sobre prosa, sin relleno) y el léxico técnico para la audiencia operador/soporte. Este export **no** posee esa lógica: la compone. Rebindeable u `off` por config.
+La redacción del manual sigue las convenciones de redacción **ambientes**: el host auto-aplica una skill de writing instalada (si está presente) por su `description` — frases cortas, listas sobre prosa, sin relleno, léxico técnico para la audiencia operador/soporte. Este export **no** compone un rol `writing` ni lo bindea; es **indiferente** a qué skill de redacción exista. Una familia útil vive en el plugin `dev-conventions` del marketplace, pero el export **no depende** de él.
 
 ## When to use
 
@@ -30,7 +30,7 @@ Capacidad **`writing`** (built-in default `writing`), resuelta vía `.workflow/s
 2. Inspecciona el código tocado en las fuentes (cómo opera/funciona lo construido) — solo lectura.
 3. Detecta temas (declarados en el OBJECTIVE/`SESSION`, o inferidos por keywords operativos).
 4. Resuelve el modo (`complement` o `regenerate`).
-5. Sintetiza el contenido aplicando la capacidad `writing`.
+5. Sintetiza el contenido aplicando las convenciones de redacción ambientes (host).
 6. Escribe: `complement` → sobrescribe `docs/manuals/INDEX.md`; `regenerate` → dossier `docs/manuals/NNN-export-manuals-YYYY-MM-DD/` con 1 manual por tema.
 
 ## What it does NOT do
@@ -99,11 +99,11 @@ Listar `docs/manuals/*.md` (excluyendo `INDEX.md` y subdirectorios `NNN-export-m
 
 Por cada sesión del corpus filtrado (`aw session-artifacts --code <NNN>`): leer `DECISION` + plan-doc (`Solution`/`Final behavior`/`Validations`) + el código tocado. Tema **primario**: sección de temas en el OBJECTIVE/`SESSION`. **Secundario**: inferencia por keywords operativos ("configurar", "instalar", "paso a paso", "cómo …"). Filtrar por `--topics` si está presente. Listar (slug, confidence, sesiones de origen).
 
-### Paso 4 — Sintetizar (compone `writing`)
+### Paso 4 — Sintetizar (prosa: convenciones ambientes)
 
 **Modo `complement`** — un `INDEX.md`: cabecera + count de manuales + tabla (Tema · Slug · Manual presente/`[pendiente]` · Sesiones de origen) + "Próximos pasos" si hay temas pendientes.
 
-**Modo `regenerate`** — 1 `.md` por tema en el dossier, cada uno con: Propósito · Pre-requisitos · Pasos numerados (cómo operar) · Comportamiento final (del plan-doc) · Validación post-uso · Decisiones relevantes (`DECISION`) · Troubleshooting · Referencias. Cada manual debe permitir al operador completar la tarea **sin** invocar al equipo de desarrollo. Más un `README.md` del dossier con el índice. La redacción aplica la capacidad `writing`.
+**Modo `regenerate`** — 1 `.md` por tema en el dossier, cada uno con: Propósito · Pre-requisitos · Pasos numerados (cómo operar) · Comportamiento final (del plan-doc) · Validación post-uso · Decisiones relevantes (`DECISION`) · Troubleshooting · Referencias. Cada manual debe permitir al operador completar la tarea **sin** invocar al equipo de desarrollo. Más un `README.md` del dossier con el índice. La redacción sigue las convenciones de redacción ambientes (host).
 
 ### Paso 5 — Escribir o reportar
 
@@ -122,6 +122,6 @@ Si `--dry-run`: imprimir el reporte; no escribir. Si no: `complement` → `Write
 ## Resources
 
 - Design: `docs/referencias/workflow-exports/export-manuals.md` · familia: [`../README.md`](../README.md).
-- Capacidad compuesta: `writing` (built-in default; ver `docs/referencias/workflow-skills/`).
+- Redacción: convención **ambiente** (no rol) — el host auto-aplica una skill de writing instalada si está presente.
 - Artefactos fuente: `DECISION` + plan-doc (ver `docs/referencias/workflow-artifacts/artifacts-exec/` y `docs/specs`/`docs/plans`).
 - Siblings: [`../export-scripts/SKILL.md`](../export-scripts/SKILL.md) · [`../export-diagrams/SKILL.md`](../export-diagrams/SKILL.md) · [`../export-reports/SKILL.md`](../export-reports/SKILL.md).

package/skills/w/exports/export-reports/SKILL.md

@@ -1,21 +1,21 @@
 ---
 name: export-reports
-description: "Consolida N sesiones del workspace en un informe ejecutivo/funcional bajo `docs/reports/NNN-<slug>-YYYY-MM-DD.md`. Lee el corpus: el spec (`docs/specs`), `CONCLUSIONS` (research), `DECISION`, el estado del plan-doc + el resto de `docs/` para contexto. Sintetiza: qué se hizo, decisiones clave, resultados/conclusiones, pendientes/roadmap — con dedup de recomendaciones cross-session. Audiencia ajustable vía `--audience` (gerencia ≈ corto; tecnica ≈ detallado). Funde el espíritu de los viejos export-report (ejecutivo) y export-conclusions (dedup de R-items) en una sola salida a `docs/reports`. Read-only/reporte: no commitea ni muta sesiones. Compone la capacidad `writing`. Úsalo para 'informe ejecutivo', 'qué se hizo este trimestre para gerencia', 'brief con recomendaciones consolidadas'. Invocado por el usuario vía `/w:export-reports`."
+description: "Consolida N sesiones del workspace en un informe ejecutivo/funcional bajo `docs/reports/NNN-<slug>-YYYY-MM-DD.md`. Lee el corpus: el spec (`docs/specs`), `CONCLUSIONS` (research), `DECISION`, el estado del plan-doc + el resto de `docs/` para contexto. Sintetiza: qué se hizo, decisiones clave, resultados/conclusiones, pendientes/roadmap — con dedup de recomendaciones cross-session. Audiencia ajustable vía `--audience` (gerencia ≈ corto; tecnica ≈ detallado). Funde el espíritu de los viejos export-report (ejecutivo) y export-conclusions (dedup de R-items) en una sola salida a `docs/reports`. Read-only/reporte: no commitea ni muta sesiones. La prosa sigue las convenciones de redacción ambientes (el host auto-aplica una skill de writing instalada si está presente). Úsalo para 'informe ejecutivo', 'qué se hizo este trimestre para gerencia', 'brief con recomendaciones consolidadas'. Invocado por el usuario vía `/w:export-reports`."
 ---
 
 # export-reports — Informe ejecutivo/funcional desde el corpus de sesiones + `docs/`
 
 Genera un único `.md` que consolida N sesiones del workspace en un informe **ejecutivo/funcional**: qué se hizo, decisiones clave, resultados/conclusiones y pendientes/roadmap. **Read-only / reporte** — no commitea, no muta sesiones ni el corpus.
 
-> Familia `export-*` (la única vía artefacto→`docs/`). **Funde** el espíritu de dos viejos exports en una sola salida a `docs/reports`: `export-report` (informe ejecutivo con tabla de componentes + diagrama de flujo) y `export-conclusions` (dedup de R-items cross-session). Modernizado: `docs/reports` en inglés, sin modos project/hub, y la prosa la aporta la capacidad `writing`. Diseño: `docs/referencias/workflow-exports/export-reports.md`.
+> Familia `export-*` (la única vía artefacto→`docs/`). **Funde** el espíritu de dos viejos exports en una sola salida a `docs/reports`: `export-report` (informe ejecutivo con tabla de componentes + diagrama de flujo) y `export-conclusions` (dedup de R-items cross-session). Modernizado: `docs/reports` en inglés, sin modos project/hub, y la prosa sigue las convenciones de redacción **ambientes** (el host auto-aplica una skill de writing instalada si está presente), no un rol propio. Diseño: `docs/referencias/workflow-exports/export-reports.md`.
 
 ## Category
 
 `docs/reports` — **única** carpeta `docs/` que este export escribe.
 
-## Composes
+## Writing (convención ambiente, no rol)
 
-Capacidad **`writing`** (built-in default `writing`), resuelta vía `.workflow/skills.toml`. Aporta la traducción técnico→ejecutiva, la cota de longitud por audiencia y el léxico (frases cortas, listas sobre prosa, sin relleno). Este export **no** posee esa lógica: la compone. Rebindeable u `off` por config.
+La redacción del informe sigue las convenciones de redacción **ambientes**: el host auto-aplica una skill de writing instalada (si está presente) por su `description` — traducción técnico→ejecutiva, cota de longitud por audiencia, frases cortas, listas sobre prosa, sin relleno. Este export **no** compone un rol `writing` ni lo bindea; es **indiferente** a qué skill de redacción exista. Una familia útil vive en el plugin `dev-conventions` del marketplace, pero el export **no depende** de él.
 
 ## When to use
 
@@ -91,9 +91,9 @@ Por sesión filtrada (`aw session-artifacts --code <NNN>`): el spec referido (qu
 
 Extraer los R-items de `CONCLUSIONS`/`DECISION` (pendientes, diferidos, "próximos pasos"). Agrupar por slug; merge de duplicados anotando `origins[]`; si dos R-items del mismo slug se contradicen, marcarlos como conflicto para resolución explícita. **No** deduplicar los C-items (son específicos de cada análisis: se preservan con trazabilidad).
 
-### Paso 4 — Sintetizar (compone `writing`)
+### Paso 4 — Sintetizar (prosa: convenciones ambientes)
 
-Render aplicando la capacidad `writing`: Resumen ejecutivo · Qué se hizo (agrupado por capacidad de negocio, **no** por sesión) · Componentes impactados (tabla) · Decisiones clave · Resultados/conclusiones · Pendientes/Roadmap (solo si hay R-items). Traducción técnico→ejecutiva y cota de longitud por `--audience`. Opcional: un `flowchart LR` simple de síntesis (con link `mermaid.ink`); el diagrama técnico detallado es de `export-diagrams`.
+Render aplicando las convenciones de redacción ambientes (host): Resumen ejecutivo · Qué se hizo (agrupado por capacidad de negocio, **no** por sesión) · Componentes impactados (tabla) · Decisiones clave · Resultados/conclusiones · Pendientes/Roadmap (solo si hay R-items). Traducción técnico→ejecutiva y cota de longitud por `--audience`. Opcional: un `flowchart LR` simple de síntesis (con link `mermaid.ink`); el diagrama técnico detallado es de `export-diagrams`.
 
 ### Paso 5 — Escribir o reportar
 
@@ -110,6 +110,6 @@ Idempotente funcional: cada invocación toma el siguiente `NNN`; no sobrescribe
 ## Resources
 
 - Design: `docs/referencias/workflow-exports/export-reports.md` · familia: [`../README.md`](../README.md).
-- Capacidad compuesta: `writing` (built-in default; ver `docs/referencias/workflow-skills/`).
+- Redacción: convención **ambiente** (no rol) — el host auto-aplica una skill de writing instalada si está presente.
 - Insumos: spec (`docs/specs`), `CONCLUSIONS`/`DECISION` (ver `docs/referencias/workflow-artifacts/`), plan-doc (`docs/plans`).
 - Siblings: [`../export-scripts/SKILL.md`](../export-scripts/SKILL.md) · [`../export-manuals/SKILL.md`](../export-manuals/SKILL.md) · [`../export-diagrams/SKILL.md`](../export-diagrams/SKILL.md).

package/skills/w/harness/SKILL.md

@@ -63,7 +63,7 @@ Mecanismo concreto por arnés (jun-2026; `~` parcial · `?` sin confirmar).
 
 "Aprovechar las skills que el arnés tenga instaladas" se resuelve por el **mismo binding** de `.workflow/skills.toml`: un rol puede apuntar a una skill **instalada en el host** (de tercero, vía skills.sh) en vez del built-in. Regla:
 
-- Si el host tiene una skill **mejor** para un rol (ej. un generador de diagramas superior para `diagrams`, un linter de estándares para `coding-standards`), se la **bindea** en `.workflow/skills.toml` y el loop la compone sin cambios.
+- Si el host tiene una skill **mejor** para un rol (ej. un generador de diagramas superior para `diagrams`, o un investigador especializado para `research`), se la **bindea** en `.workflow/skills.toml` y el loop la compone sin cambios.
 - El built-in default es el **piso**, no el techo: garantiza que el rol funcione en cualquier host; el binding lo **enriquece** donde el host puede más.
 
 ## Convención para el resto del corpus

package/skills/w/loops/README.md

@@ -92,7 +92,7 @@ spec-refine-loop  ── CHASIS (patrón de referencia: objetivo persistente + v
                                        hereda git/BD/no-export de plan-exec
 ```
 
-El chasis **no es una capacidad bindeable**: *es* `spec-refine-loop` y los demás loops lo heredan. Lo enchufable son las **capacidades** que un loop compone (ej. `ui-design`, `sql`, `git`, `testing`), resueltas por `.workflow/skills.toml`.
+El chasis **no es una capacidad bindeable**: *es* `spec-refine-loop` y los demás loops lo heredan. Lo enchufable son las **capacidades** que un loop compone (ej. `ui-design`, `sql`, `git`, `tools`), resueltas por `.workflow/skills.toml`.
 
 ## Composed capabilities (roles)
 
@@ -103,13 +103,12 @@ Los loops componen **capacidades por su rol**, no skills concretas; la skill que
 | `ui-design` | `ui-spec` | `spec-refine-loop` (cuando hay UI) |
 | `sql` | `sql` | research · `plan-exec-loop` · `quick-loop` |
 | `git` | `git` | `plan-exec-loop` · `quick-loop` |
-| `coding-standards` | `coding-standards` | `plan-exec-loop` · `quick-loop` |
-| `writing` | `writing` | todos los loops |
 | `research` | `research` | todos los loops (research inline) |
-| `testing` | `testing` | `plan-exec-loop` · `quick-loop` |
 | `tools` | `tools` | `plan-exec-loop` |
 | `overview` | `workflow` | cualquiera (orientación) |
 
+> **Convenciones ambientes (no roles).** Los estándares de código, testing y redacción **no son roles** del workflow ni se bindean: son **skills standalone que el host auto-descubre por su `description`** y aplica cuando son relevantes. El workflow es **indiferente** (no las lee ni las busca). Una familia útil vive en el plugin `dev-conventions` del marketplace, pero el workflow **no depende** de él.
+
 `off` en config → capacidad desactivada: el loop sigue sin ella; si era necesaria, lo dice o pregunta al humano.
 
 ## Index

package/skills/w/loops/plan-exec-loop/SKILL.md

@@ -14,7 +14,7 @@ description: >-
   se ejecuta); validación por fase y final (lo dependiente de migración no
   aplicada se difiere como handoff a DBA); y SIN auto-export (escribe solo
   docs/plans + docs/tools; el resto queda como artefacto de session para
-  export-*). Compone git, coding-standards, testing, tools y sql. Lo arranca
+  export-*). Compone git, tools y sql. Lo arranca
   /w:plan-exec y es reanudable. Invocar para implementar un plan ya generado.
 ---
 
@@ -55,7 +55,9 @@ Del chasis [`spec-refine-loop`](../spec-refine-loop/SKILL.md), sin cambios:
 
 ## Composes
 
-`git` (rama segura + commits propuestos) · `coding-standards` (cambio mínimo, estilo de la fuente) · `testing` (validación) · `tools` (herramientas reusables → `docs/tools`) · `sql` (regla BD) · `writing`. Todas resueltas por `.workflow/skills.toml`; `off` → el loop sigue sin la capacidad y, si era necesaria, lo dice o pregunta.
+`git` (rama segura + commits propuestos) · `tools` (herramientas reusables → `docs/tools`) · `sql` (regla BD). Todas resueltas por `.workflow/skills.toml`; `off` → el loop sigue sin la capacidad y, si era necesaria, lo dice o pregunta.
+
+> **Convenciones ambientes (no roles).** Los estándares de código, testing y redacción **no son roles** del workflow ni se bindean: son **skills standalone que el host auto-descubre por su `description`** y aplica cuando son relevantes. El workflow es **indiferente** (no las lee ni las busca). Una familia útil vive en el plugin `dev-conventions` del marketplace, pero el workflow **no depende** de él.
 
 ## Internal sessions (managed)
 

package/skills/w/loops/quick-loop/SKILL.md

@@ -48,7 +48,9 @@ QUICK
 
 ## Composes
 
-`git` · `coding-standards` · `testing` (verification-first) · `sql` (regla BD) · `writing` · `research` (inline). Resueltas por `.workflow/skills.toml`.
+`git` · `sql` (regla BD) · `research` (inline). Resueltas por `.workflow/skills.toml`.
+
+> **Convenciones ambientes (no roles).** Los estándares de código, testing y redacción **no son roles** del workflow ni se bindean: son **skills standalone que el host auto-descubre por su `description`** y aplica cuando son relevantes. El workflow es **indiferente** (no las lee ni las busca). Una familia útil vive en el plugin `dev-conventions` del marketplace, pero el workflow **no depende** de él.
 
 ## Delta QUICK — minimal ceremony
 

package/skills/w/loops/spec-refine-loop/SKILL.md

@@ -114,7 +114,9 @@ El **CLI es dueño del número**: `aw session-create` antepone un `NNN` **global
 
 El gap **UI sin especificar** (cuando el requerimiento involucra UI; ver *Gap taxonomy*) se resuelve **componiendo** la capacidad **`ui-design`** (default built-in `ui-spec`; rebindeable vía `.workflow/skills.toml`): autora el UI spec nativamente (estructura, vocabulario, formato Markdown). Es un tercer modo de resolución de gap (junto a *research* y *humano*): el loop aporta la iteración/Q&A que el viejo servicio no tenía (design-system, tema, variantes, desambiguación) **vía la misma structured-choice**, y lo integra como sección `## UI spec` del spec.
 
-Otras capacidades transversales que el chasis usa siempre: `research` (research **inline**, ver abajo), `sql` (regla BD en research), `writing` (redacción del spec). Todas se resuelven por config; `off` → el loop sigue sin la capacidad y, si era necesaria, lo dice o pregunta.
+Otras capacidades transversales que el chasis usa siempre: `research` (research **inline**, ver abajo), `sql` (regla BD en research). Todas se resuelven por config; `off` → el loop sigue sin la capacidad y, si era necesaria, lo dice o pregunta. La **prosa del spec** sigue las convenciones de redacción **ambientes** (el host auto-aplica una skill de writing instalada si está presente), no un rol compuesto.
+
+> **Convenciones ambientes (no roles).** Los estándares de código, testing y redacción **no son roles** del workflow ni se bindean: son **skills standalone que el host auto-descubre por su `description`** y aplica cuando son relevantes. El workflow es **indiferente** (no las lee ni las busca). Una familia útil vive en el plugin `dev-conventions` del marketplace, pero el workflow **no depende** de él.
 
 ## Deliverable schema (el spec, editado in place)
 

package/skills/w/roles/README.md

@@ -8,17 +8,14 @@
 
 ## Capability catalog
 
-All 10 roles, their built-in defaults, their tier, and which loops/exports compose them:
+All 7 roles, their built-in defaults, their tier, and which loops/exports compose them:
 
 | Role | Default built-in | Tier | Composed by |
 |---|---|---|---|
 | `ui-design` | [`ui-spec`](ui-spec/SKILL.md) | must | `spec-refine-loop` (when requirement involves UI) |
 | `sql` | `sql` | must | inline research · `plan-exec-loop` · `quick-loop` · `export-scripts` |
 | `git` | `git` | must | `plan-exec-loop` · `quick-loop` |
-| `coding-standards` | `coding-standards` | must | `plan-exec-loop` · `quick-loop` |
-| `writing` | `writing` | must | all loops · `export-manuals` · `export-reports` |
 | `research` | [`research`](research/SKILL.md) | should | all loops (on-demand investigation) |
-| `testing` | [`testing`](testing/SKILL.md) | should | `plan-exec-loop` · `quick-loop` |
 | `tools` | [`tools`](tools/SKILL.md) | should | `plan-exec-loop` |
 | `diagrams` | [`diagrams`](diagrams/SKILL.md) | should | `export-diagrams` |
 | `overview` | `workflow` | should | any loop (orientation about the workflow itself) |
@@ -27,6 +24,8 @@ All 10 roles, their built-in defaults, their tier, and which loops/exports compo
 - `must` — core to almost every session; built-in always active unless explicitly `off`.
 - `should` — loaded on-demand; active by default but lower priority to override.
 
+> **Convenciones ambientes (no roles).** Los estándares de código, testing y redacción **no son roles** del workflow ni se bindean: son **skills standalone que el host auto-descubre por su `description`** y aplica cuando son relevantes. El workflow es **indiferente** (no las lee ni las busca). Una familia útil vive en el plugin `dev-conventions` del marketplace, pero el workflow **no depende** de él.
+
 ---
 
 ## Binding cascade
@@ -59,18 +58,15 @@ built-in default
 # ui-design        = "ui-spec"
 # sql              = "sql"
 # git              = "git"
-# coding-standards = "coding-standards"
-# writing          = "writing"
 # research         = "research"
-# testing          = "testing"
 # tools            = "tools"
 # diagrams         = "diagrams"
 # overview         = "workflow"
 
 # Override examples:
-testing          = "off"                # disable testing capability
 ui-design        = "acme/figma-spec"    # third-party skill installed via skills.sh
 diagrams         = "mermaid-only"       # custom built installed locally
+sql              = "off"                # disable the sql capability
 ```
 
 ### Override: point to a third-party skill
@@ -86,10 +82,10 @@ ui-design = "acme/figma-spec"
 
 ```toml
 [skills]
-testing = "off"
+sql = "off"
 ```
 
-The loop that composes `testing` will skip it. If the task required testing and the role is `off`, the loop should inform the human and ask how to proceed.
+The loop that composes `sql` will skip it. If the task required the capability and the role is `off`, the loop should inform the human and ask how to proceed.
 
 ### Override: use a different built-in
 
@@ -113,18 +109,15 @@ Lists the resolved binding for every role in the current workspace, showing whic
 Example output:
 
 ```
-Role              Resolved skill      Source
------------------ ------------------- -----------
-ui-design         ui-spec             built-in
-sql               sql                 built-in
-git               git                 built-in
-coding-standards  coding-standards    built-in
-writing           writing             built-in
-research          research            built-in
-testing           off                 workspace   (.workflow/skills.toml)
-tools             tools               built-in
-diagrams          mermaid-only        global      (~/.workflow/skills.toml)
-overview          workflow            built-in
+Role              Resolved skill          Source
+----------------- ----------------------- -----------
+ui-design         ui-spec                 built-in
+sql               sql                     built-in
+git               git                     built-in
+research          research                built-in
+tools             tools                   built-in
+diagrams          mermaid-only            global      (~/.workflow/skills.toml)
+overview          workflow                built-in
 ```
 
 ---
@@ -142,7 +135,7 @@ Each `SKILL.md` follows this schema:
 
 | Section | Content |
 |---|---|
-| Frontmatter `name:` | kebab-case; MUST equal the binding name (`research`, `testing`, etc.) |
+| Frontmatter `name:` | kebab-case; MUST equal the binding name (`research`, `tools`, etc.) |
 | Frontmatter `description:` | rich description: what + when; drives automatic selection |
 | `## Role` | which capability role this implements (its skills.toml slot) |
 | `## Purpose` | what it does |

package/skills/w/roles/tools/SKILL.md

@@ -21,7 +21,7 @@ Dar al `plan-exec-loop` la capacidad de crear herramientas y utilidades auxiliar
 
 | Tipo | Rol | ¿Quién lo maneja? |
 |---|---|---|
-| Código de producto (services, controllers, components) | cambio en el repo fuente | `plan-exec-loop` + `coding-standards` |
+| Código de producto (services, controllers, components) | cambio en el repo fuente | `plan-exec-loop` (estilo: convenciones ambientes del host) |
 | Tool / utilidad auxiliar creada por el plan | herramienta de soporte | esta skill (`tools`) |
 | Script SQL de migración | dato persistente | `sql` + `export-scripts` |
 
@@ -120,7 +120,7 @@ Si la tool genera o manipula SQL:
 
 ### Code quality baseline
 
-Al autorar el código de la tool, aplicar lo que la capacidad `coding-standards` del workspace establezca. Si `coding-standards` está `off` o no está configurada, usar los estándares del lenguaje detectado:
+Al autorar el código de la tool, seguir las convenciones de código **ambientes** del host (auto-descubiertas por su `description`; no es un rol del workflow ni se bindea). Si no hay una skill de estándares aplicable, usar los estándares del lenguaje detectado:
 - **Shell**: shellcheck-compatible, variables entre comillas, `set -euo pipefail`.
 - **Node/TS**: tipado explícito, sin `any` salvo justificación, error handling explícito.
 - **Python**: type hints, docstring en funciones públicas, manejo de excepciones específico.

package/skills/w/roles/coding-standards/SKILL.md

@@ -1,82 +0,0 @@
----
-name: coding-standards
-description: >-
-  Coding standards capability — built-in default for the `coding-standards` role.
-  Stack-agnostic principles (SOLID, fail-fast, descriptive names, small methods,
-  reuse over duplication) plus per-stack conventions (Java/Spring, Angular/TypeScript,
-  Node), security (no secrets in code or logs, parametrized SQL, DB read-only via MCP),
-  HTTP error handling (never silence errors), logging levels, and FE-BE integration
-  rules (unified sparse DTO, PATCH for edit, no hidden fallbacks). Use when a loop
-  implements, reviews or refactors code.
----
-
-# coding-standards — Coding standards capability
-
-## Role
-
-`coding-standards` — built-in default. Rebindable in `.workflow/skills.toml` (third-party skill or `off`).
-
-## Purpose
-
-Aportar los estándares de código que la IA aplica al **implementar, revisar o refactorizar**. Read-only por diseño: carga reglas, no edita ni ejecuta nada por sí misma — el loop consumidor materializa el código.
-
-## Composed by
-
-- **`plan-exec-loop`** — al implementar/refactorizar las tasks del plan.
-- **`quick-loop`** — al implementar el atajo liviano.
-
-## Knowledge
-
-### Principios generales
-
-- **SOLID** — Single Responsibility, Open/Closed, Liskov, Interface Segregation, Dependency Inversion.
-- **Fail fast** — validar y retornar al inicio del método (early returns, evitar nesting).
-- **Nombres descriptivos** — el código habla por sí mismo; comentarios solo para el "por qué".
-- **Métodos pequeños** — una sola responsabilidad por función.
-- **Composición sobre herencia**.
-- **Reutilización antes que duplicación (DRY)** — antes de crear componente/función/clase, revisar si ya existe en `shared/` (frontend) o `common/`/`util/` (backend). Si un patrón aparece 2-3 veces, proponer extracción.
-
-### Estándares por stack
-
-- **Java / Spring Boot**: Constructor Injection (sin Field Injection), `@Transactional(readOnly=true)` para lecturas, Java records para DTOs Request/Response, Jakarta Validation para inputs.
-- **Angular / TypeScript**: constructor injection, `async` pipe en templates, evitar `any`, FormBuilder reactivo sobre `ngModel` directo, arquitectura `@data`/`@presentation`, normalización de tipos.
-- **Node / otros**: mismos principios generales; aplicar las convenciones idiomáticas del proyecto detectado.
-
-### Integración FE-BE (cuando el cambio cruza frontend y backend)
-
-- **R1 — Sparse DTO unificado**: mismo DTO `<Feature>SaveRequest` para create + edit, todos los campos nullable. `null` = "no tocar".
-- **R2 — PATCH para edit**: `@PatchMapping` en BE, `http.patch()` en FE. POST solo para create. PUT solo si replace total justificado.
-- **R3 — FE envía solo cambios**: payload diff entre `formValue` y entidad original.
-- **R4 — Sin fallbacks que oculten errores**: prohibido `catchError(() => of([]))` en FE; prohibido try/catch con fallback al método legacy en BE durante migraciones. Usar feature flags explícitas para rollout gradual.
-- **R5 — Validación BE con Bean Validation + groups**: `@NotNull(groups = OnCreate.class)` para distinguir reglas POST vs PATCH cuando comparten DTO.
-- **R6 — DB stub-first**: funciones/SP nuevas arrancan devolviendo mock (`RETURN '[]'::jsonb`); implementación real en una fase posterior.
-
-### Seguridad
-
-- **Nunca** exponer secrets, API keys ni credenciales en código.
-- **Nunca** logear datos sensibles (contraseñas, tokens, datos personales).
-- **Siempre** parametrizar queries SQL (nunca concatenar strings).
-- **BD vía MCP es READONLY**. Modificaciones a BD solo como scripts SQL versionados (ver rol `sql`); las aplica el **usuario**, nunca la IA — ni por MCP, ni `Bash`, ni `psql`, ni driver. (Invariante 4.)
-
-### Manejo de errores HTTP
-
-- **Nunca** silenciar errores HTTP con `catchError(() => of([]))` ni equivalentes. Los errores del backend se propagan al usuario (toast/mensaje) para detectar regresiones en guardado/sincronización/creación. Para reintentos usar operadores explícitos (`retry`, `retryWhen`), no silenciar.
-
-### Logging
-
-- `ERROR` — fallos que requieren atención inmediata.
-- `WARN` — situaciones inesperadas pero manejadas.
-- `INFO` — eventos de negocio relevantes (inicio/fin de procesos).
-- `DEBUG` — detalle técnico para diagnóstico.
-
-### Convenciones de BD (nomenclatura)
-
-Esquemas `esq_`, tablas `tb_`, sequences `seq_`, funciones `fn_`/procedimientos `sp_`, patrón maestra-detalle, auditoría en `esq_audit`. Para autoría de scripts SQL (estilo, header, categorías, rollback) usar el rol **`sql`**.
-
-## Output
-
-Ninguno propio. La skill aporta reglas; el código lo escribe el loop. Cuando el cambio toca BD, delega la autoría de scripts al rol `sql`. Nunca exporta a `docs/` (invariante 1).
-
-## Source
-
-Reciclada de `standards/coding-standards/` (SKILL.md + references Java/Spring, Angular/TypeScript, fe-be-integration, database-conventions, frontend-structure, project-structure). Los principios UX de mantenimientos CRUD (formularios, listados, modales) viven en el rol `ui-spec`/`ui-design`; la autoría de scripts SQL en el rol `sql`. Se descarta la dependencia de `profile.json` y de comandos CLI de la doctrina vieja.

package/skills/w/roles/testing/SKILL.md

@@ -1,180 +0,0 @@
----
-name: testing
-description: >
-  Estrategia y ejecución de pruebas: selecciona niveles (unit / integration / e2e),
-  resuelve comandos por stack detectado, guía la convención de nombres y estructura de tests.
-  Pregunta al humano antes de ejecutar; nunca lanza el test runner sin confirmación explícita.
-  Compuesta por plan-exec-loop y quick-loop durante la fase de validación de cambios.
----
-
-# testing — Test strategy and execution capability
-
-## Role
-
-`testing` — implementación built-in por defecto. Rebindeable a otra skill (de tercero o `off`) en `.workflow/skills.toml`.
-
-## Purpose
-
-Dar a los loops la capacidad de razonar sobre tests: qué nivel aplicar, con qué comando, con qué convención. **No ejecuta tests de forma autónoma** — primero pregunta al humano si quiere que el loop los corra, o si los correrá manualmente, o si no hacen falta en esta sesión.
-
-## Composed by
-
-| Loop | Cuándo la compone |
-|---|---|
-| `plan-exec-loop` | durante validation de cada task ejecutada |
-| `quick-loop` | cuando el cambio quick requiere verificación |
-
-## Knowledge
-
-### Execution rule
-
-Por defecto, **no ejecutar pruebas automáticamente**. Antes de correr cualquier test runner, preguntar al humano vía *structured-choice* (capacidad del arnés — ver `../../harness/SKILL.md`). En **Claude Code** es `AskUserQuestion` (máx 4 preguntas/llamada → **≤3 preguntas de contenido + 1 control `flow`**); en un arnés sin elección estructurada, degrada a **markdown numerado**.
-
-```
-structured-choice:
-  "¿Correr los tests?"
-  [a] Sí, el loop los ejecuta
-  [b] Los corro yo manualmente
-  [c] No hace falta en esta sesión
-```
-
-Solo saltear la pregunta si el workspace declara `Validation mode: auto` en `.workflow/config.toml`.
-
-### Test levels
-
-Tres niveles universales (adaptados al stack detectado):
-
-| Nivel | Alcance | Cuándo usarlo |
-|---|---|---|
-| **a) Unit** | Lógica aislada (servicios, utils, mappers) | Fix puntual, lógica sin dependencias externas |
-| **b) Integration** | Unit + capa de API/controladores | Endpoint nuevo o modificado |
-| **c) Full** | Integration + contexto completo + e2e | Feature completa, flujo crítico, integración entre capas |
-
-### Stack resolution
-
-El stack se detecta por archivos de manifest presentes en el workspace. Precedencia: si el bloque `WORKSPACE → Stack` declara override de build/wrapper, usarlo.
-
-#### Spring Boot (Maven)
-
-| Nivel | Framework | Comando |
-|---|---|---|
-| a) Unit | JUnit 5 + Mockito | `./mvnw test -Dtest=ClaseTest` |
-| b) Integration | + MockMvc | `./mvnw test` |
-| c) Full | + @SpringBootTest | `./mvnw verify` |
-
-> Windows: `mvnw.cmd` en lugar de `./mvnw`.
-
-#### Spring Boot (Gradle)
-
-| Nivel | Comando |
-|---|---|
-| a) Unit | `./gradlew test --tests ClaseTest` |
-| b) Integration | `./gradlew test` |
-| c) Full | `./gradlew integrationTest` (o `check`) |
-
-#### Angular
-
-| Nivel | Framework | Comando |
-|---|---|---|
-| a) Unit | Jasmine + Karma (o Jest) | `ng test --watch=false` |
-| b) Integration | + TestBed + ComponentFixture | `ng test --watch=false` |
-| c) Full | + Cypress/Playwright si configurado | `npm run e2e` |
-
-#### Node / TypeScript genérico
-
-| Nivel | Comando |
-|---|---|
-| a) Unit | `npm test` (script `test` en `package.json`) |
-| b) Integration | `npm test` con suites de integración |
-| c) Full | `npm run test:e2e` o según config |
-
-#### Resolución automática
-
-1. `mvnw` / `mvnw.cmd` → Maven wrapper.
-2. `gradlew` → Gradle wrapper.
-3. `angular.json` → `ng test`.
-4. `package.json` con script `test` → `npm test`.
-5. Si hay override en `WORKSPACE → Stack` → usarlo.
-
-### Naming conventions
-
-**Java:** clase `[Objetivo]Test.java`, método `[metodo]_[escenario]_[resultado]`. Estructura Arrange-Act-Assert.
-
-```java
-@Test
-void enviar_conEmailValido_retornaExito() {
-    // Arrange
-    var request = new NotificacionRequest("user@example.com", "Asunto", "template", Map.of());
-    when(emailProvider.send(any())).thenReturn(true);
-    // Act
-    var resultado = service.enviar(request);
-    // Assert
-    assertThat(resultado).isTrue();
-}
-```
-
-**Angular / TypeScript:** archivo `[nombre].spec.ts`, bloques `describe` / `it`. Usar `TestBed` para componentes.
-
-```typescript
-describe('AuthService', () => {
-  it('should return token on login', () => {
-    // ...
-  });
-});
-```
-
-### Level selection prompt (to show the human)
-
-Adaptar al stack resuelto. Ejemplo para Spring Boot:
-
-```
-¿Qué nivel de pruebas aplicamos?
-  a) Unitarios       — JUnit 5 + Mockito (rápido, aislado)
-  b) Integración     — + MockMvc controllers
-  c) Completo        — + @SpringBootTest (contexto Spring completo)
-```
-
-El humano puede cambiar de nivel en cualquier momento o decidir no ejecutar desde el loop.
-
-### Execution and logging
-
-1. Confirmar que el humano quiere ejecución desde el loop (ver "Execution rule").
-2. Ejecutar el comando resuelto según stack y nivel.
-3. Registrar resultado en `TEST_LOG.md` **solo si** el humano pidió registro formal o la ejecución fue desde el loop.
-4. Si el humano ya validó manualmente, no repetir; anotar una línea breve si aporta trazabilidad.
-5. Si hay fallos y el humano quiere continuar: corregir y re-ejecutar.
-
-### TestBuilder pattern (Java)
-
-Para construir fixtures reutilizables sin acoplar los tests al constructor de producción:
-
-```java
-public class NotificacionTestBuilder {
-    private String destinatario = "test@example.com";
-    private String estado = "PENDIENTE";
-
-    public static NotificacionTestBuilder builder() { return new NotificacionTestBuilder(); }
-
-    public NotificacionTestBuilder destinatario(String val) { this.destinatario = val; return this; }
-    public NotificacionTestBuilder estado(String val) { this.estado = val; return this; }
-
-    public Notificacion build() {
-        var e = new Notificacion();
-        e.setDestinatario(destinatario);
-        e.setEstado(estado);
-        return e;
-    }
-}
-```
-
-## Output
-
-No produce artefactos de forma autónoma. Cuando el humano confirma ejecución:
-- Corre el comando resuelto y reporta el resultado inline.
-- Escribe `TEST_LOG.md` en la sesión activa solo si fue pedido explícitamente.
-
-No gradua a `docs/` (invariant #1).
-
-## Source
-
-Reciclado de `agent-workflow/standards/testing-strategy/` del bundle viejo (v0.1.0). Se conserva: los tres niveles (a/b/c), la regla de confirmación antes de ejecutar, la resolución de stack por manifest, los naming conventions, la tabla de comandos por framework. Se descarta: la referencia al bloque `AW-PROJECT → Stack` (reemplazado por `WORKSPACE → Stack`), el `TEST_LOG.md` obligatorio, el sandbox-readonly-rules legacy, referencias a `plan mode` del sistema anterior.

package/skills/w/roles/writing/SKILL.md

@@ -1,90 +0,0 @@
----
-name: writing
-description: >-
-  Clear technical writing capability — built-in default for the `writing` role. Rules
-  for any prose the AI produces in agent-workflow context: spec/plan/session artifacts,
-  commit messages, PR descriptions, export deliverables (manuals/reports). Short
-  sentences, lists over prose, one idea per line, "what + why" on one line, no jargon,
-  no filler. Use across all loops and in export-manuals / export-reports.
----
-
-# writing — Clear technical writing
-
-## Role
-
-`writing` — built-in default. Rebindable in `.workflow/skills.toml` (third-party skill or `off`). The most broadly composed role.
-
-## Purpose
-
-Reglas de estilo y formato para **toda la prosa** que la IA produce en contexto agent-workflow. Read-only por diseño: carga reglas; el `.md` lo materializa el consumidor (loop o export).
-
-## Composed by
-
-- **Todos los loops** — al escribir specs, planes, artefactos de sesión, mensajes de commit, descripciones de PR.
-- **`export-manuals`** — al redactar manuales técnicos (`docs/manuals`).
-- **`export-reports`** — al redactar informes ejecutivos (`docs/reports`).
-
-(También aplica a respuestas en chat sobre temas agent-workflow.)
-
-## Knowledge
-
-### Las 6 reglas
-
-1. **Frases cortas**: máximo ~15 palabras. Si pasa de 20, partir en dos.
-2. **Listas sobre prosa**: 3+ ideas paralelas van en bullets. Prosa solo para narrar.
-3. **Una idea por línea**: si el bullet usa "y" o ";" para meter una segunda idea, separar.
-4. **"Qué + por qué" en una línea**: formato `<qué>: <por qué corto>`. Sin párrafo aparte para el "por qué".
-5. **Sin jerga ni abreviaturas raras**: palabras comunes. Términos técnicos (MCP, C4) OK; abreviaturas inventadas (ej. "TLDR del CTX") no.
-6. **Sin relleno**: borrar "es importante notar que…", "cabe destacar…", "como se mencionó…", "en conclusión…". La idea va directo.
-
-### Palabras a evitar / preferir
-
-| Evitar | Preferir |
-|---|---|
-| "es importante notar que" / "cabe destacar" | (borrar, empezar con la idea) |
-| "en otras palabras" / "asimismo" | (borrar) / "también" |
-| "se procede a" / "llevar a cabo" | verbo directo / "hacer" |
-| "implementar la funcionalidad de X" | "implementar X" |
-| "realizar la validación de" | "validar" |
-| "a los efectos de" / "en el marco de" | "para" / "en" |
-| "no obstante" / "previamente mencionado" | "pero" / "antes" |
-| "TLDR", "FYI", "WIP" | escribir la palabra completa |
-
-### Ejemplo antes / después
-
-Antes:
-> Es importante notar que cada llamada implica un round-trip al servidor MCP además del consumo de tokens correspondiente al JSON de respuesta.
-
-Después (-50%):
-> Cada llamada MCP cuesta un round-trip y los tokens del JSON.
-
-Decisión densa, antes:
-> Se decidió, luego de analizar las alternativas, implementar la validación de roles solo en el frontend, dado que el backend no requiere la lógica y evita duplicar la regla.
-
-Después:
-> **Decisión**: validar permisos solo en el frontend.
-> **Por qué**: el backend no necesita la lógica; evita duplicar la regla.
-
-### Cuándo SÍ se permite prosa larga
-
-- Resúmenes ejecutivos donde la decisión necesita 4-6 oraciones para sostenerse.
-- Cadena causal de un incidente (causa raíz puede requerir un párrafo).
-- Tradeoffs de UX que necesitan explicación.
-
-Aún ahí: oraciones simples encadenadas, no oraciones largas.
-
-### Aplicación a los documentos del modelo nuevo
-
-- **spec** (`docs/specs`): brief y criterios de aceptación claros; la sección `## UI spec` la formatea el rol `ui-design`.
-- **plan** (`docs/plans`): resumen + fases + tasks con dependencias; tasks sin código inline (el código va en evidencia y se referencia).
-- **decisiones**: `**Decisión**:` + `**Por qué**:`, 3-6 líneas; si es obvia, no se registra.
-- **commit messages / PR**: mismas reglas (frases cortas, sin jerga, sin relleno). Formato canónico del mensaje en el rol `git`.
-- **export manuals/reports**: audiencia operadores/gerencia; bullets sobre prosa, sin relleno corporativo.
-
-## Output
-
-Ninguno propio. La skill aporta reglas; el `.md` lo escribe el consumidor (loop o export). Cuando escribe a `docs/`, lo hace solo el export que la compone (invariante 1) y solo en su carpeta (invariante 2).
-
-## Source
-
-Reciclada de `standards/redaccion-simple/` (las 6 reglas, tabla evitar/preferir, ejemplos, cuándo permitir prosa larga). Se descarta el catálogo de estructuras por artefacto del modelo viejo (OBJETIVO/DECISIONES/etc.); los documentos del modelo nuevo son spec/plan + artefactos de sesión, y su estructura la definen los loops y exports.