@tacuchi/agent-workflow-cli 15.2.0 → 16.0.0

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

@@ -19,36 +19,36 @@ description: >-
 
 ## Purpose
 
-Autorar cambios de base de datos como **scripts SQL versionados**, nunca ejecutándolos. Cubre dos modos:
+Author database changes as **versioned SQL scripts**, never executing them. Two modes:
 
-- **Read-only** (consulta): leer schema/datos via MCP para entender el dominio (research, planning).
-- **Write-to-script** (cambio): toda mutación de BD se escribe a `SCRIPTS.sql` de la sesión; la **aplica el usuario**, no la IA.
+- **Read-only** (query): read schema/data via MCP to understand the domain (research, planning).
+- **Write-to-script** (change): every DB mutation is written to the session's `SCRIPTS.sql`; the **user applies it**, never the AI.
 
 ## Composed by
 
-- **research** — leer schema via MCP read-only para entender el dominio.
-- **`plan-exec-loop`** — cada cambio SQL se appendea a `SCRIPTS.sql` durante la ejecución.
-- **`quick-loop`** — igual, para el atajo liviano.
-- **`export-scripts`** — consolida los `SCRIPTS.sql` de N sesiones en el bundle `docs/scripts/NNN-export-scripts-YYYY-MM-DD/` y deriva el rollback.
+- **research** — read schema via read-only MCP to understand the domain.
+- **`plan-exec-loop`** — every SQL change is appended to `SCRIPTS.sql` during execution.
+- **`quick-loop`** — same, for the lightweight shortcut.
+- **`export-scripts`** — consolidates N sessions' `SCRIPTS.sql` into the `docs/scripts/NNN-export-scripts-YYYY-MM-DD/` bundle and derives the rollback.
 
 ## Knowledge
 
-### Regla cero — nunca ejecutar SQL (invariante 4)
+### Rule zero — never execute SQL (invariant 4)
 
-La IA **nunca ejecuta DML/DDL** contra ninguna BD, por ningún canal (MCP, `psql`, `Bash`, driver de app). Las migraciones quedan en `SCRIPTS.sql` y las **aplica el usuario**. Si aparece la tentación de "verificar aplicando", rehusar y pedir al usuario que ejecute.
+The AI **never executes DML/DDL** against any DB, through any channel (MCP, `psql`, `Bash`, an app driver). Migrations stay in `SCRIPTS.sql` and the **user applies them**. If the temptation "verify by applying" appears, refuse and ask the user to run it.
 
-- **Lecturas read-only via MCP**: `SELECT`, inspección de schema, conteos — OK. Sin `INSERT/UPDATE/DELETE/CREATE/ALTER/DROP/TRUNCATE`.
-- Los MCP de BD (cert/prod) son **READONLY** por contrato.
-- Excepción única, que NO relaja la regla: si el usuario pide explícitamente "ejecutalo vos contra cert", aún así confirmar por bloque y no asumir autorización ampliada.
+- **Read-only reads via MCP**: `SELECT`, schema inspection, counts — OK. No `INSERT/UPDATE/DELETE/CREATE/ALTER/DROP/TRUNCATE`.
+- The DB MCPs (cert/prod) are **READONLY** by contract.
+- Single exception, which does NOT relax the rule: if the user explicitly asks "run it yourself against cert", still confirm per block and never assume broadened authorization.
 
-### Staging — archivo único `SCRIPTS.sql` por sesión
+### Staging — a single `SCRIPTS.sql` per session
 
 ```
 .workflow/sessions/<folder>/
-└── SCRIPTS.sql      (consolidado de TODAS las sentencias de la sesión)
+└── SCRIPTS.sql      (consolidated: ALL of the session's statements)
 ```
 
-Cada sentencia se **appendea** con un par de markers en comentarios:
+Every statement is **appended** with a pair of comment markers:
 
 ```sql
 -- @category: 01-ddl-tablas
@@ -58,60 +58,64 @@ CREATE TABLE IF NOT EXISTS esq_credito.tb_usuarios (
 );
 ```
 
-- `@category` clasifica (4 valores canónicos, abajo).
-- `@stmt` da el slug determinístico `NN-verbo-objetivo`; `export-scripts` deriva el filename al separar.
-- Orden dentro del archivo = orden cronológico de append. El orden de ejecución final por categoría (01→02→03→04) lo resuelve `export-scripts`, no este paso.
-- `BEGIN;` global al inicio del archivo, `COMMIT;` al final. Cada sentencia individual **no** trae su propio BEGIN/COMMIT.
-- **Sin** `.rollback.sql` per archivo durante exec — el rollback se genera al exportar.
+- `@category` classifies (4 canonical values, below).
+- `@stmt` gives the deterministic slug `NN-verb-target`; `export-scripts` derives the filename when splitting.
+- Order inside the file = chronological append order. The final per-category execution order (01→02→03→04) is resolved by `export-scripts`, not here.
+- A global `BEGIN;` at the top of the file, `COMMIT;` at the end. Individual statements carry **no** BEGIN/COMMIT of their own.
+- **No** per-file `.rollback.sql` during exec — the rollback is generated on export.
 
-### Las 4 categorías (`@category`)
+### The 4 categories (`@category`)
 
-| Marker | Patrones de detección |
+| Marker | Detection patterns |
 |---|---|
 | `01-ddl-tablas` | `CREATE/DROP/ALTER TABLE`, `CREATE INDEX`, `CREATE SEQUENCE` |
 | `02-ddl-funciones` | `CREATE [OR REPLACE] FUNCTION/PROCEDURE`, `DROP FUNCTION/PROCEDURE` |
-| `03-migracion` | `UPDATE`, `INSERT ... SELECT`, `DELETE` sobre datos existentes, transformaciones de columnas |
-| `04-inserts` | `INSERT INTO ... VALUES`, seeds de catálogos, datos de configuración inicial |
+| `03-migracion` | `UPDATE`, `INSERT ... SELECT`, `DELETE` over existing data, column transformations |
+| `04-inserts` | `INSERT INTO ... VALUES`, catalog seeds, initial configuration data |
 
-**Orden de ejecución obligatorio**: 01 → 02 → 03 → 04. El `SCRIPTS.sql` puede mezclar categorías cronológicamente; `export-scripts` ordena el bundle final.
+**Mandatory execution order**: 01 → 02 → 03 → 04. `SCRIPTS.sql` may mix categories chronologically; `export-scripts` orders the final bundle.
 
-### Estilo SQL
+### SQL style
+
+- **Canonical 4-line header**, between two equal-sign lines (delivered scripts are user-facing → field values in the user's language):
 
-- **Header canónico de 4 líneas**, entre dos líneas de iguales:
   ```sql
   -- ============================================================================
   -- Script:  NNN-tipo-objetivo.sql
   -- Sesion:  sNNN
-  -- Objeto:  <qué hace, 1-2 líneas>
-  -- Alcance: <filtros y boundaries del cambio, 1 línea>
+  -- Objeto:  <what it does, 1-2 lines>
+  -- Alcance: <filters and boundaries of the change, 1 line>
   -- ============================================================================
   ```
-  Solo 4 campos. Autor/Fecha/notas largas NO van en el header (si hacen falta, bloque libre debajo). Si el motor no es Postgres, indicarlo en `Objeto:`.
-- **Idempotencia**: `CREATE TABLE IF NOT EXISTS`, `DROP ... IF EXISTS`, `CREATE OR REPLACE`, `ON CONFLICT`.
-- **Schema explícito** siempre (`esq_credito.tb_x`, nunca `public.`).
-- **CTEs sobre DO/LOOP**: una transformación = `WITH ... AS` encadenadas + un `INSERT/UPDATE/DELETE` final. Evitar `DO $$ ... LOOP ... END $$` cuando el resultado se logra declarativamente (más fácil de auditar y revertir). Excepción: descubrimiento dinámico de objetos (FKs/columnas/constraints) — documentar el motivo en `Objeto:`.
-- **Queries parametrizadas** siempre (nunca concatenar strings) — en cualquier SQL que termine en código de app.
-- Nunca crear `fn_*`/`sp_*` para reusar lógica exclusiva de un script; usar CTE o inline.
-- **Separadores entre secciones** (solo si hay 2+ secciones):
+
+  Only 4 fields. Author/Date/long notes do NOT go in the header (a free block below, if needed). If the engine is not Postgres, state it in `Objeto:`.
+- **Idempotency**: `CREATE TABLE IF NOT EXISTS`, `DROP ... IF EXISTS`, `CREATE OR REPLACE`, `ON CONFLICT`.
+- **Explicit schema** always (`esq_credito.tb_x`, never `public.`).
+- **CTEs over DO/LOOP**: one transformation = chained `WITH ... AS` + one final `INSERT/UPDATE/DELETE`. Avoid `DO $$ ... LOOP ... END $$` when the result is achievable declaratively (easier to audit and revert). Exception: dynamic object discovery (FKs/columns/constraints) — document the reason in `Objeto:`.
+- **Parametrized queries** always (never string concatenation) — in any SQL that ends up in app code.
+- Never create `fn_*`/`sp_*` to reuse logic exclusive to one script; use a CTE or inline.
+- **Section separators** (only with 2+ sections):
+
   ```sql
   -- ----------------------------------------------------------------------------
-  -- N. Descripción corta de qué hace este bloque.
+  -- N. Short description of what this block does.
   -- ----------------------------------------------------------------------------
   ```
-  Cajas dobles (`====`) solo para el header.
 
-### Proceso de mantenimiento del `SCRIPTS.sql`
+  Double boxes (`====`) only for the header.
+
+### `SCRIPTS.sql` maintenance process
 
-1. **Detectar la categoría** del cambio (tabla de markers).
-2. **Verificar idempotencia** del statement.
-3. **Append** con par de markers (`@category` + `@stmt`).
-4. **Style check** — header canónico, CTEs sobre DO/LOOP, schema explícito.
-5. **No** renumerar ni mover (solo hay un `SCRIPTS.sql`).
-6. **No** generar `.rollback.sql` durante exec.
+1. **Detect the category** of the change (markers table).
+2. **Verify idempotency** of the statement.
+3. **Append** with the marker pair (`@category` + `@stmt`).
+4. **Style check** — canonical header, CTEs over DO/LOOP, explicit schema.
+5. **Never** renumber or move (there is a single `SCRIPTS.sql`).
+6. **Never** generate `.rollback.sql` during exec.
 
-### Rollback (lo genera `export-scripts`, no este paso)
+### Rollback (generated by `export-scripts`, not here)
 
-`export-scripts` lee los forwards ya consolidados y genera **un único** `00-ROLLBACK.sql` al root del bundle, en orden inverso. Conocer las estrategias para escribir forwards reversibles:
+`export-scripts` reads the consolidated forwards and generates **a single** `00-ROLLBACK.sql` at the bundle root, in reverse order. Know the strategies to write reversible forwards:
 
 | Forward | Rollback |
 |---|---|
@@ -119,19 +123,19 @@ CREATE TABLE IF NOT EXISTS esq_credito.tb_usuarios (
 | `ALTER TABLE tb_x ADD COLUMN col` | `ALTER TABLE tb_x DROP COLUMN IF EXISTS col;` |
 | `CREATE INDEX idx_...` | `DROP INDEX IF EXISTS idx_...;` |
 | `CREATE SEQUENCE seq_...` | `DROP SEQUENCE IF EXISTS seq_...;` |
-| `CREATE OR REPLACE FUNCTION fn_x(...)` | `DROP FUNCTION IF EXISTS fn_x(<firma>);` |
-| `UPDATE/DELETE` con backup en `esq_audit.tb_bkp_*` | `UPDATE … FROM esq_audit.tb_bkp_…` |
-| `INSERT INTO tb_x VALUES (...)` | `DELETE FROM tb_x WHERE <clave natural / rango>;` (nunca DELETE sin WHERE) |
+| `CREATE OR REPLACE FUNCTION fn_x(...)` | `DROP FUNCTION IF EXISTS fn_x(<signature>);` |
+| `UPDATE/DELETE` with a backup in `esq_audit.tb_bkp_*` | `UPDATE … FROM esq_audit.tb_bkp_…` |
+| `INSERT INTO tb_x VALUES (...)` | `DELETE FROM tb_x WHERE <natural key / range>;` (never DELETE without WHERE) |
 
-**Irreversibles → bloque "Fase 5" manual** (fuera de la transacción, una línea por caso): `TRUNCATE`, `DROP COLUMN`/`DROP TABLE` sin backup, `ALTER COLUMN TYPE` con pérdida, `DROP ... CASCADE`, `DELETE/UPDATE` sin respaldo en `esq_audit`. Para que un cambio destructivo sea reversible, escribir el backup en el mismo forward (`esq_audit.tb_bkp_<tabla>_sNNN`).
+**Irreversible → manual "Fase 5" block** (outside the transaction, one line per case): `TRUNCATE`, `DROP COLUMN`/`DROP TABLE` without backup, lossy `ALTER COLUMN TYPE`, `DROP ... CASCADE`, `DELETE/UPDATE` without a backup in `esq_audit`. To make a destructive change reversible, write the backup in the same forward (`esq_audit.tb_bkp_<table>_sNNN`).
 
 ## Output
 
-- Durante loops: sentencias appendeadas a `.workflow/sessions/<folder>/SCRIPTS.sql` (artefacto de sesión, no `docs/`).
-- Vía `export-scripts`: bundle `docs/scripts/NNN-export-scripts-YYYY-MM-DD/` — `00-ROLLBACK.sql` + `01-<CATEGORIA>.sql` … (numeración continua, sin gaps por categoría vacía) + `README.md`. Orden canónico de categorías: `DDL-TABLES → DDL-FUNCTIONS → DML → INSERTS`.
+- During loops: statements appended to `.workflow/sessions/<folder>/SCRIPTS.sql` (session artifact, never `docs/`).
+- Via `export-scripts`: the `docs/scripts/NNN-export-scripts-YYYY-MM-DD/` bundle — `00-ROLLBACK.sql` + `01-<CATEGORY>.sql` … (continuous numbering, no gaps for empty categories) + `README.md`. Canonical category order: `DDL-TABLES → DDL-FUNCTIONS → DML → INSERTS`.
 
-Nunca escribe a `docs/` desde un loop (invariante 1: solo `export-*` exporta). Nunca ejecuta nada contra una BD (invariante 4).
+It never writes `docs/` from a loop (invariant 1: only `export-*` exports). It never executes anything against a DB (invariant 4).
 
 ## Source
 
-Reglas autocontenidas (sin dependencia de skills externas). Racional e historia: diseño (`docs/referencias/workflow-roles/sql.md`).
+Self-contained rules (no dependency on external skills). Rationale and history: design (`docs/referencias/workflow-roles/sql.md`).

package/skills/w/roles/ui-spec/SKILL.md

@@ -10,7 +10,7 @@ description: >-
   in PLAN (`plan-new-loop`/`plan-refine-loop`) it authors per-screen **design
   SPECs** (`NNN-SPEC-<SLUG>.md`) as session artifacts. Use when a loop is refining
   a spec or building/refining a plan that involves screens, forms, dashboards,
-  modals or any UI surface. Recycled from the `ui-spec-generator` service.
+  modals or any UI surface.
 ---
 
 # ui-spec — UI spec authoring
@@ -21,81 +21,81 @@ description: >-
 
 ## Purpose
 
-Dado un requerimiento de UI, autorar una **descripción estructurada en Markdown** de las pantallas y sus componentes — descriptiva (qué hay y para qué) y estructurada (regiones → componentes, con vocabulario consistente), agnóstica de framework. **Reemplaza** al servicio single-shot `ui-spec-generator`: ahora la IA la autora **nativamente**, guiada por esta skill. No hay endpoint que llamar; el saber del servicio vive aquí. **Salida en un solo formato: Markdown** (sin representación JSON paralela).
+Given a UI requirement, author a **structured Markdown description** of the screens and their components — descriptive (what exists and what for) and structured (regions → components, consistent vocabulary), framework-agnostic. The AI authors it **natively**, guided by this skill; there is no endpoint to call. **Single output format: Markdown** (no parallel JSON representation).
 
 ## Composed by
 
-Dos niveles, misma capacidad:
+Two levels, same capability:
 
-- **`spec-refine-loop`** (ver `../../loops/spec-refine-loop/SKILL.md`) — al resolver el gap **UI sin especificar** (cuando el requerimiento involucra UI): autora la sección `## UI spec` **del spec** (el *qué* de la UI, pantallas a grano grueso).
-- **`plan-new-loop` · `plan-refine-loop`** (ver `../../loops/plan-new-loop/SKILL.md` § *Delta 4*) — al resolver el gap **UI sin design SPEC** (cuando el **plan incluye UI**): autora **design SPECs** por pantalla (`NNN-SPEC-<SLUG>.md`) como **artefactos de la sesión de PLAN** (ver `../../artifacts/artifacts-design/SPEC.md`); derivan de `## UI spec` si existe.
+- **`spec-refine-loop`** (see `../../loops/spec-refine-loop/SKILL.md`) — resolving the **UI unspecified** gap (when the requirement involves UI): authors the spec's `## UI spec` section (the UI's *what*, coarse-grain screens).
+- **`plan-new-loop` · `plan-refine-loop`** (see `../../loops/plan-new-loop/SKILL.md` § *Delta 4*) — resolving the **UI without design SPEC** gap (when the **plan includes UI**): authors per-screen **design SPECs** (`NNN-SPEC-<SLUG>.md`) as **PLAN session artifacts** (see `../../artifacts/artifacts-design/SPEC.md`); they derive from `## UI spec` when it exists.
 
-En ambos, el loop aporta lo que el servicio viejo no tenía:
+In both, the composing loop contributes:
 
-- **Pregunta al humano** (design-system, tema, ambigüedades de pantalla) vía *structured-choice* (regla canónica: `../../loops/CHASSIS.md` § *Structured-choice*; binding por arnés: `../../harness/SKILL.md`).
-- **Itera** gap-driven hasta converger.
-- Ofrece **variantes** y **cura** el resultado.
+- **Asking the human** (design system, theme, screen ambiguities) via *structured-choice* (canonical rule: `../../loops/CHASSIS.md` § *Structured-choice*; per-harness binding: `../../harness/SKILL.md`).
+- **Gap-driven iteration** until convergence.
+- Offering **variants** and **curating** the result.
 
-Cualquier loop podría componerla; los casos primarios son SPEC y PLAN. En SPEC, la descripción aterriza como sección del documento spec (`docs/specs/NNN-spec-<slug>.md`) — el spec sigue siendo un documento (invariante 3). En PLAN aterriza como **design SPECs** (artefactos de sesión) — que **no** son el requirement-spec: son el detalle de diseño por pantalla, de proceso.
+Any loop could compose it; the primary cases are SPEC and PLAN. In SPEC the description lands as a section of the spec document (`docs/specs/NNN-spec-<slug>.md`) — the spec remains a document (invariant 3). In PLAN it lands as **design SPECs** (session artifacts) — which are **not** the requirement-spec: they are the per-screen design detail, process-facing.
 
 ## Knowledge
 
-### Estructura conceptual (universal, recursiva)
+### Conceptual structure (universal, recursive)
 
-Una **pantalla** tiene: `nombre`, `tipo` (propósito semántico: auth, dashboard, form, list, detail, error, …), `plataforma` (web por default, mobile, …), `descripción` opcional, y **o bien regiones** (pantalla compleja) **o bien componentes** directos (pantalla simple) — **no ambos**.
+A **screen** has: `name`, `type` (semantic purpose: auth, dashboard, form, list, detail, error, …), `platform` (web by default, mobile, …), optional `description`, and **either regions** (complex screen) **or** direct **components** (simple screen) — **never both**.
 
-- Una **región** agrupa componentes y tiene un `type`.
-- Un **componente** tiene un `kind`, y opcionalmente `role`, `label` y `children` (anidables, recursivos).
+- A **region** groups components and has a `type`.
+- A **component** has a `kind`, and optionally `role`, `label` and `children` (nestable, recursive).
 
-Es un modelo conceptual para guiar la autoría; **no se serializa a JSON** — la única salida es el render Markdown (ver Output).
+It is a conceptual model to guide authoring; **it is never serialized to JSON** — the only output is the Markdown render (see Output).
 
-- `type` (región) ∈ `header · main · footer · sidebar · filters · summary`
-- `kind` (componente) por categoría:
-  - **Contenedores**: `card · panel · modal`
-  - **Datos**: `table · list · grid`
-  - **Visualización**: `chart · metric · badge · image`
-  - **Entrada**: `textInput · select · checkbox · datePicker · toggle`
-  - **Acciones**: `button · link · actionGroup`
-  - **Navegación**: `navBar · tabs · breadcrumb`
+- `type` (region) ∈ `header · main · footer · sidebar · filters · summary`
+- `kind` (component) by category:
+  - **Containers**: `card · panel · modal`
+  - **Data**: `table · list · grid`
+  - **Visualization**: `chart · metric · badge · image`
+  - **Input**: `textInput · select · checkbox · datePicker · toggle`
+  - **Actions**: `button · link · actionGroup`
+  - **Navigation**: `navBar · tabs · breadcrumb`
   - **Feedback**: `alert · progress`
 
 ### Rules
 
-1. **Conciso** — solo lo esencial. Nada de relleno ni componentes especulativos.
-2. Pantalla simple (login, recuperar contraseña, error) → `components` directo, **sin** `regions`.
-3. Pantalla compleja (dashboard, mantenimiento CRUD) → `regions` para organizar.
-4. `role` es **opcional** — solo si aporta claridad (`role:"logo"`, `role:"primary"`).
-5. Límites: **≤100 componentes**, **≤5 niveles** de anidación.
-6. Una sola pantalla por bloque `#`; si el requerimiento son varias pantallas, se listan una tras otra (cada una con su `#`).
+1. **Concise** — only the essential. No filler, no speculative components.
+2. Simple screen (login, password recovery, error) → direct `components`, **no** `regions`.
+3. Complex screen (dashboard, CRUD maintenance) → `regions` to organize.
+4. `role` is **optional** — only when it adds clarity (`role:"logo"`, `role:"primary"`).
+5. Limits: **≤100 components**, **≤5 nesting levels**.
+6. One screen per `#` block; a multi-screen requirement lists them one after another (each with its own `#`).
 
-### Design options (las pregunta el loop al humano)
+### Design options (the loop asks the human)
 
-Estas opciones **guían contenido/labels**; la estructura de la pantalla es **agnóstica** de design-system y NO las lleva como parte del modelo. Se **anotan en el spec** (encabezado de la sección):
+These options **guide content/labels**; the screen structure is design-system **agnostic** and does NOT carry them in the model. They are **annotated in the spec** (section header):
 
 - **Design system**: `material3 · bootstrap5 · tailwind3 · antDesign · chakraUI · custom`.
-- **Tema**: `light · dark · auto`.
-- **Idioma**: `es · en · …` (afecta los `label`).
-- **Densidad** (opcional): `compact · comfortable · spacious`.
-- **maxWidth** (opcional): pixeles, 320–3840 (anotación de layout).
+- **Theme**: `light · dark · auto`.
+- **Language**: `es · en · …` (affects the `label`s — user-facing content follows the user's language).
+- **Density** (optional): `compact · comfortable · spacious`.
+- **maxWidth** (optional): pixels, 320–3840 (layout annotation).
 
 ### Variants
 
-Cuando el requerimiento admite más de un layout razonable (ej. tabla vs. grid de cards; tabs vs. acordeón), ofrecer **2-3 variantes** como pantallas Markdown alternativas y pedir al humano que elija. Una sola variante se cura y queda; las descartadas no se persisten.
+When the requirement admits more than one reasonable layout (e.g. table vs. card grid; tabs vs. accordion), offer **2-3 variants** as alternative Markdown screens and ask the human to pick. The chosen variant is curated and stays; discarded ones are not persisted.
 
 ### Disambiguation
 
-Antes de autorar, resolver ambigüedades con *structured-choice* (lo dispara el loop; ver `../../harness/SKILL.md`):
+Before authoring, resolve ambiguities via *structured-choice* (the loop triggers it):
 
-- Pantalla simple o compleja (¿necesita `regions`?).
-- Qué acciones primarias/secundarias existen.
-- Qué datos muestra (tabla, métricas, ambos).
-- Si hay estados (loading, empty, error) que el spec deba enumerar.
+- Simple or complex screen (does it need `regions`?).
+- Which primary/secondary actions exist.
+- What data it shows (table, metrics, both).
+- Whether there are states (loading, empty, error) the spec must enumerate.
 
-Si el humano no responde, asumir el caso más simple coherente con la descripción y anotar el supuesto.
+If the human does not answer, assume the simplest case coherent with the description and note the assumption.
 
-### Examples (few-shot)
+### Examples (few-shot; labels in the user's language)
 
-**Simple (sin regiones)** — "Recuperar Contraseña" (auth, web):
+**Simple (no regions)** — `Recuperar Contraseña` (auth, web):
 
 ```markdown
 # Recuperar Contraseña
@@ -108,7 +108,7 @@ Si el humano no responde, asumir el caso más simple coherente con la descripci
 - **Volver al login** (link)
 ```
 
-**Complejo (con regiones)** — "Dashboard" (web):
+**Complex (with regions)** — "Dashboard" (web):
 
 ```markdown
 # Dashboard
@@ -122,40 +122,26 @@ Si el humano no responde, asumir el caso más simple coherente con la descripci
 - **Registros** (table)
 ```
 
-## Output — dos aterrizajes, un solo formato (Markdown)
+## Output — two landing zones, one format (Markdown)
 
-**Salida en un solo formato: Markdown.** La escribe el loop (no esta skill por sí sola). El **render es el mismo** en ambos niveles; cambia dónde aterriza, según el loop que compone:
+**Single output format: Markdown.** The loop writes it (never this skill on its own). The **render is identical** at both levels; what changes is where it lands, per the composing loop:
 
-| Loop que compone | Aterriza en | Grano |
+| Composing loop | Lands in | Grain |
 |---|---|---|
-| `spec-refine-loop` | sección `## UI spec` **del spec** (`docs/specs/NNN-spec-<slug>.md`) — documento, in place | todas las pantallas del requerimiento, grano grueso |
-| `plan-new-loop` · `plan-refine-loop` | **design SPECs** `NNN-SPEC-<SLUG>.md` — artefactos en la **sesión de PLAN** (uno **por pantalla**, con encabezado de traza; ver `../../artifacts/artifacts-design/SPEC.md`) | una pantalla por archivo, detalle ejecutable |
+| `spec-refine-loop` | the spec's `## UI spec` section (`docs/specs/NNN-spec-<slug>.md`) — document, in place | all the requirement's screens, coarse grain |
+| `plan-new-loop` · `plan-refine-loop` | **design SPECs** `NNN-SPEC-<SLUG>.md` — artifacts in the **PLAN session** (one **per screen**, with a trace header; see `../../artifacts/artifacts-design/SPEC.md`) | one screen per file, executable detail |
 
-Encabezar la sección (o el encabezado de traza del SPEC) con las opciones de diseño elegidas (design system, tema, idioma) en una línea. Luego el render Markdown, con estas reglas exactas (recicladas del `MarkdownFormatter`):
+Head the section (or the SPEC's trace header) with the chosen design options (design system, theme, language) in one line. Then the Markdown render, with these exact rules:
 
-- `# {nombre}`
-- `**Tipo**: {tipo} | **Plataforma**: {plataforma}`
-- `descripción` como párrafo aparte (solo si existe).
-- Con regiones: un `## {Type capitalizado}` por región (capitalizar la primera letra del `type`).
-- Sin regiones: un único `## Componentes`.
-- Cada componente: `- **{label || role || kind}**`, seguido de ` ({kind})` **solo si** había `label` o `role`.
-- `children` indentados **2 espacios por nivel**.
-- Si hay varias pantallas, se listan una tras otra (cada una con su `#`).
-
-Ejemplo de render para el dashboard de arriba:
-
-```markdown
-# Dashboard
-**Tipo**: dashboard | **Plataforma**: web
-
-## Summary
-- **Total** (metric)
-- **Pendientes** (metric)
-
-## Main
-- **Registros** (table)
-```
+- `# {name}`
+- `**Tipo**: {type} | **Plataforma**: {platform}`
+- `description` as a separate paragraph (only if present).
+- With regions: one `## {Capitalized type}` per region (capitalize the `type`'s first letter).
+- Without regions: a single `## Componentes`.
+- Each component: `- **{label || role || kind}**`, followed by ` ({kind})` **only if** there was a `label` or `role`.
+- `children` indented **2 spaces per level**.
+- Multiple screens are listed one after another (each with its own `#`).
 
 ## Source
 
-Reciclada de `ui-spec-generator` (Spring Boot/Kotlin). Se **conservan**: el prompt de sistema (vocabulario, kinds, reglas), la estructura conceptual pantalla/región/componente, los pocos-shot (ahora en Markdown), el enum de design systems, los constraints (theme/density/maxWidth) y las reglas exactas del `MarkdownFormatter` (su render era exactamente este). Se **descarta**: la **serialización JSON `Screen`** (segunda representación, ahora innecesaria), el transporte HTTP, OpenRouter/Gemini y el modo single-shot — los reemplaza la iteración del `spec-refine-loop`. El endpoint del servicio deja de usarse. También absorbe los principios UX de la vieja skill `standards/frontend-design/` cuando el spec describe mantenimientos CRUD (formularios, listados, modales, navegación, feedback).
+Rationale and history: design (`docs/referencias/workflow-roles/ui-spec.md`).