@trycore/spec-build-harness 0.8.4 → 0.8.5

package/.claude-plugin/plugin.json

@@ -2,7 +2,7 @@
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "trycore-spec-build-harness",
   "displayName": "Trycore — Spec & Build Harness",
-  "version": "0.8.4",
+  "version": "0.8.5",
   "description": "Arnés de construcción de dos loops (slice por épica + release gate) para Claude Code, con gates de calidad, estado compartido y OpenSpec. Compañero de @trycore/spec-product-flow. Agnóstico al proyecto.",
   "author": {
     "name": "Trycore",

package/GOVERNANCE.md

@@ -10,8 +10,8 @@ evoluciona con el modelo y el proyecto. No es "instalar y olvidar".
 | Estado | `build-state.json` (+schema, README) | `.claude/state/` |
 | Agentes | 14 agentes de build | `.claude/agents/build/` |
 | Hooks | settings.json + 13 scripts | `.claude/settings.json`, `.claude/hooks/build/` |
-| Skill | `building-a-slice` (+11 refs · `workflows/`) · `releasing-a-version` (`workflows/`) · `building-a-micro-change` (carril ligero de mantenimiento) · `managing-parallel-front` (front paralelo inter-épica) | `.claude/skills/` |
-| Comandos | `/opsx:*` · `/build:onboard` · `/build:reflect` · `/build:slice` · `/build:release` · `/build:work` · `/build:resume` · `/build:front` | `.claude/commands/` |
+| Skill | `building-a-slice` (+11 refs · `workflows/`) · `releasing-a-version` (`workflows/`) · `building-a-micro-change` (carril ligero de mantenimiento) · `managing-parallel-front` (front paralelo inter-épica) · `prototyping-screens` (prototipo HTML de referencia) | `.claude/skills/` |
+| Comandos | `/opsx:*` · `/build:onboard` · `/build:reflect` · `/build:prototype` · `/build:slice` · `/build:release` · `/build:work` · `/build:resume` · `/build:front` | `.claude/commands/` |
 | Config | allowlist de stack | `.claude/config/stack-allowlist.json` |
 
 ## Fases de activación (`harness_phase`)
@@ -46,6 +46,21 @@ Editar `stack-allowlist.json` SOLO si la sección de requisitos técnicos del PR
 ## Bitácora de cambios de metodología
 Cambios a la política de construcción (unidad de trabajo, gates, DoR/DoD). Aprueba el DRI; van por PR.
 
+- **2026-08-05 · v0.8.5** — **El arnés puede generar el prototipo (fuente de diseño)** (origen:
+  investigación de comunidad sobre fidelidad visual + dolor recurrente de pantallas que difieren del
+  prototipo; spec `docs/superpowers/specs/2026-08-05-prototype-generator-design.md`). **Aprobación del
+  DRI (Agent Manager) requerida en el PR.** Cambia una regla de política: "el arnés NO genera el
+  prototipo" → "**puede generarlo** vía `/build:prototype` (skill `prototyping-screens`); la
+  confirmación (`design_source.confirmed`) y la aprobación de cada pantalla (`borrador`→`aprobada`
+  en `manifest.json`) siguen siendo **exclusivamente humanas**". No cambia unidad de trabajo, gates,
+  DoR ni DoD: el gate `design_source` conserva su semántica (espejo de `scaffold`) y `fidelity`
+  sigue igual. Toca §9.2 (4º carve-out de escritura: subárbol `docs/05-prototipo/`, análogo a
+  `docs/adr/`) y §10 regla 9 (nota de producción de la fuente). Modo feature con **precondición
+  dura** (app corriendo + MCP de inspección de UI; sin degradación estática), coherente con la
+  postura estricta de `fidelity`. Artefactos nuevos: **1 comando** (`/build:prototype`, total 9
+  `/build:*`) y **1 skill** (`prototyping-screens`, total 16); sin hooks ni agentes nuevos; schema
+  sin cambio estructural (solo texto de `description`). Release **0.8.5** (version-sync ×3).
+
 - **2026-06-24 · v0.7.0** — **Workflows dinámicos en el flujo build-a-slice** (origen:
   evaluación adversarial del arnés con workflows dinámicos; 18 mejoras aprobadas contra una rúbrica de
   hardness). **Aprobado por el DRI (Agent Manager); fusionado en PR #7.** No cambia la unidad de trabajo, los gates,

package/INSTALL.md

@@ -87,8 +87,8 @@ Qué hace `init`:
 1. **Verifica requisitos duros** (a menos que uses `--skip-doctor`).
 2. **Siembra los assets** en rutas nativas de Claude Code:
    - `.claude/agents/build/` — 14 agentes.
-   - `.claude/commands/opsx/` (10 comandos `/opsx:*`) y `.claude/commands/build/` (8 comandos: `/build:onboard`, `/build:reflect`, `/build:architect`, `/build:slice`, `/build:release`, `/build:work`, `/build:resume`, `/build:front`).
-   - `.claude/skills/` — 15 skills (`building-a-slice`, `building-a-micro-change`, `releasing-a-version`, `managing-parallel-front`, `setup-architecture`, `openspec-*`).
+   - `.claude/commands/opsx/` (10 comandos `/opsx:*`) y `.claude/commands/build/` (9 comandos: `/build:onboard`, `/build:reflect`, `/build:architect`, `/build:prototype`, `/build:slice`, `/build:release`, `/build:work`, `/build:resume`, `/build:front`).
+   - `.claude/skills/` — 16 skills (`building-a-slice`, `building-a-micro-change`, `releasing-a-version`, `managing-parallel-front`, `setup-architecture`, `prototyping-screens`, `openspec-*`).
    - `.claude/hooks/build/` — 13 hooks (bash + python).
 3. **Siembra el estado**: `state/build-state.schema.json` y `state/README.md` se versionan;
    `state/build-state.json` se siembra **vacío y nunca se sobrescribe** (va al `.gitignore`).

package/METODOLOGIA.md

@@ -493,13 +493,16 @@ La construcción **consume** los artefactos de discovery y los trata como entrad
 
 El arnés **no escribe** en los artefactos de discovery (`docs/01-prd/` … `docs/04-historias/`); cuando
 una HU no cumple DoR, devuelve el trabajo a discovery (`/trycore:*`). Los contactos de escritura del
-arnés en `docs/` son **tres** y están acotados: la **back-reference** del change en la épica y las HU
+arnés en `docs/` son **cuatro** y están acotados: la **back-reference** del change en la épica y las HU
 al archivar (§6.4), el subárbol **`docs/adr/`** —propiedad de construcción— que produce la capa de
-arquitectura (§9.3), y la **épica caparazón** en `docs/03-backlog/epicas.md` — únicamente esa épica,
+arquitectura (§9.3), la **épica caparazón** en `docs/03-backlog/epicas.md` — únicamente esa épica,
 únicamente con **aprobación humana explícita** del borrador propuesto en `/build:onboard` Fase 2c
 (frontmatter `origin: harness-draft`); si el humano rechaza, la épica se crea en discovery como
-siempre. `docs/adr/` **no** es un artefacto de discovery: es la salida de construcción que traza
-*hacia* discovery (HU/PRD) sin modificarla.
+siempre —, y el subárbol **`docs/05-prototipo/`** —propiedad de construcción— donde
+`/build:prototype` (skill `prototyping-screens`) produce el prototipo HTML de referencia (la fuente
+de diseño): las pantallas nacen `borrador` y solo pasan a `aprobada` con aprobación humana, análogo
+a `docs/adr/`. Ni `docs/adr/` ni `docs/05-prototipo/` son artefactos de discovery: son salida de
+construcción que traza *hacia* discovery (HU/PRD) sin modificarla.
 
 ### 9.3 Capa de arquitectura (ADD) — entre discovery y construcción
 
@@ -556,7 +559,9 @@ salida es file-based y la propuesta se materializa en git, mañana irá por API
    no MVP** (recortar/diferir es bloqueante explícito, nunca decisión del modelo; verificación
    ejecutada, no por inspección).
 9. **Fidelidad estricta**: para slices con UI, `fidelity` solo cierra con **verificación visual real**
-   (MCP chrome-devtools); INCONCLUSO no pasa.
+   (MCP chrome-devtools); INCONCLUSO no pasa. La fuente de diseño puede **producirse** con
+   `/build:prototype` (en modo feature exige extracción viva de la app corriendo);
+   `design_source.confirmed` sigue siendo confirmación humana, nunca del arnés.
 10. El core es **agnóstico**: lo específico del dominio se inyecta vía `/build:onboard` y
     `stack-allowlist.json`; el ejemplo de referencia vive en `docs/examples/reference/`.
 11. Si una skill, agente o reference contradice este documento, **gana la metodología**.

package/README.md

@@ -142,8 +142,8 @@ trycore-spec-build-harness/
 ├── agents/build/              ← 14 agentes revisores (segunda opinión, contexto limpio)
 ├── commands/
 │   ├── opsx/                  ← 10 comandos /opsx:* (ciclo OpenSpec)
-│   └── build/                 ← 8 comandos /build:* (onboard, reflect, architect, slice, release, work, resume, front)
-├── skills/                    ← 15 skills (building-a-slice, building-a-micro-change, releasing-a-version, managing-parallel-front, setup-architecture, 10 openspec-*) + 3 plantillas *.workflow.js (opt-in, read-only)
+│   └── build/                 ← 9 comandos /build:* (onboard, reflect, architect, prototype, slice, release, work, resume, front)
+├── skills/                    ← 16 skills (building-a-slice, building-a-micro-change, releasing-a-version, managing-parallel-front, setup-architecture, prototyping-screens, 10 openspec-*) + 3 plantillas *.workflow.js (opt-in, read-only)
 ├── hooks/build/               ← 13 hooks (gate-check, reflect-nudge, release-gate-nudge, scaffold-guard, gitflow-guard, stack-guard, statusline-bridge, context-monitor, reconcile-build-state, …)
 ├── state/                     ← máquina de estado: build-state.json + schema + README
 ├── config/                    ← build-config.template.json (umbrales de contexto) + stack-allowlist.template.json (artefacto del consumidor)
@@ -183,7 +183,8 @@ El core no menciona ningún dominio de cliente. Toda parametrización entra por
 - ✅ **v0.7.0** — **orquestación con workflows dinámicos + hardening** (de una evaluación adversarial del propio arnés): **3 plantillas `*.workflow.js`** opt-in y read-only (`explore-fanout`, `wiring-verify`, `release-gate`) que entran **solo donde aportan valor** y nunca en el camino caliente del inner loop; **3 comandos nuevos** `/build:slice` (entrada del inner loop), `/build:release` (outer loop) y `/build:work` (router *classify-and-act*); hook **`release-gate-nudge.sh`** (Stop, determinista: solo sugiere el Release Gate). Rename de los gates de los 5 reviewers pesados → `releases[].gates.{security,smell,ux,coherence,stack_arch}` (`stack`→`stack_arch`; separación `coherence` (release) / `coherence_link` (inner)). Hardening: degradación segura en 8 agentes, escritura atómica del estado, cierre del bypass de specs no-semver, `wiring` exige evidencia ejecutada y `check-agnostic` barre `*.js`. Total: **12 agentes**, **10 hooks**, **5 comandos `/build:*`**.
 - ✅ **v0.8.0** — **motor de contexto + estado anclado a disco + front paralelo inter-épica**: hooks **`statusline-bridge.sh`** (canal CLI) + **`context-monitor.sh`** (umbrales `context.warning_pct`/`context.critical_pct` configurables, 35%/25% por defecto) con **auto-handoff** a `session_continuity` en critical/`PreCompact` y comando **`/build:resume`** para rehidratar desde disco; config **`context.auto_checkpoint`** (opt-in). Reconciliador **`reconcile-build-state.py`** (`SessionStart`): deriva de git + evidencia de tests, degrada `wiring_checklist` sin evidencia, anota *branch drift*, ratchet de gates, fail-open. **Front paralelo** (`parallel_front` en el estado): comando **`/build:front`** + skill **`managing-parallel-front`** + `scripts/lib/front-plan.py` (disjunción por `files_scope`, foundational-first). Schema nuevo: `slice.layer`, `slice.files_scope`, `slice.branch_drift`, `slice.session_continuity`. **Caveat:** `statusLine` es solo canal CLI; en plugin-only el motor de contexto degrada fail-open. Total: **12 agentes**, **13 hooks**, **7 comandos `/build:*`**, **14 skills**.
 - ✅ **v0.8.1** — **hotfix del motor de contexto**: `context-monitor.sh` re-inyectaba `additionalContext` en cada evento `Stop`, lo que re-lanzaba el turno en bucle hasta el tope `CLAUDE_CODE_STOP_HOOK_BLOCK_CAP` (9→override). Ahora en `Stop` re-lanza como mucho una vez por sesión (solo la transición a crítico que graba el handoff) y `warning` nunca inyecta en `Stop`. Cubierto por `test-context-monitor.sh`.
-- ✅ **v0.8.4 (actual)** — **épica caparazón obligatoria en greenfield**: nuevo campo `project_kind` con detección automática conservadora en `trycore-build init` (brownfield seguro = manifiesto + código + **historial git con commits de código**; ambigüedad → una sola pregunta en `/build:onboard`; **en brownfield el mecanismo es N/A total, sin preguntar**) y gate de proyecto **`foundation`**: contrato del caparazón (navegación/menús · layout/panel central · homepage · login/authN · redirecciones/guards) como checklist podable con **evidencia de ejecución por ítem** (patrón `wiring_checklist`, contrato en `skills/building-a-slice/references/foundation-contract.md`). `/build:onboard` **Fase 2c** poda el contrato y redacta el **borrador híbrido** de la épica (solo se escribe en `epicas.md` con aprobación humana explícita — carve-out §9.2). **DoR 7-bis proactivo**: en greenfield ninguna épica `business` abre slice hasta que la caparazón esté **archivada con checklist evidenciada** (`foundation.completed_at`); las fundacionales y el carril micro-change nunca se bloquean. Línea `Caparazón` en `status`/`doctor`. Retrocompatible: campos opcionales del schema.
+- ✅ **v0.8.5 (actual)** — **generador de prototipos HTML de referencia**: comando **`/build:prototype`** + skill **`prototyping-screens`** que producen la fuente de diseño (`DESIGN_SOURCE`) en `docs/05-prototipo/` (`DESIGN.md` + `tokens.css` + `manifest.json` pantalla↔épica/HU + un HTML autocontenido por pantalla). Dos modos: **greenfield** (inventario desde PRD/mapa/historias → dirección estética con 2-3 variantes a elección humana → generación por lotes) y **feature** (pantallas de una épica nueva con **extracción viva obligatoria** del UI implementado: CSS computado + screenshots en 3 viewports vía MCP; sin degradación estática). Auto-verificación visual (render real, máx. 3 iteraciones, sin pixel-diff) y **aprobación humana** de cada pantalla (`borrador`→`aprobada`); `ux-fidelity-reviewer` resuelve pantallas vía `manifest.json` (solo `aprobada`). La regla "el arnés no genera el prototipo" evoluciona a "puede generarlo; `design_source.confirmed` sigue siendo humano". 4º carve-out de escritura en `docs/` (§9.2). Total: **14 agentes**, **13 hooks**, **9 comandos `/build:*`**, **16 skills**.
+- ✅ **v0.8.4** — **épica caparazón obligatoria en greenfield**: nuevo campo `project_kind` con detección automática conservadora en `trycore-build init` (brownfield seguro = manifiesto + código + **historial git con commits de código**; ambigüedad → una sola pregunta en `/build:onboard`; **en brownfield el mecanismo es N/A total, sin preguntar**) y gate de proyecto **`foundation`**: contrato del caparazón (navegación/menús · layout/panel central · homepage · login/authN · redirecciones/guards) como checklist podable con **evidencia de ejecución por ítem** (patrón `wiring_checklist`, contrato en `skills/building-a-slice/references/foundation-contract.md`). `/build:onboard` **Fase 2c** poda el contrato y redacta el **borrador híbrido** de la épica (solo se escribe en `epicas.md` con aprobación humana explícita — carve-out §9.2). **DoR 7-bis proactivo**: en greenfield ninguna épica `business` abre slice hasta que la caparazón esté **archivada con checklist evidenciada** (`foundation.completed_at`); las fundacionales y el carril micro-change nunca se bloquean. Línea `Caparazón` en `status`/`doctor`. Retrocompatible: campos opcionales del schema.
 - ✅ **v0.8.3** — **gates de validación paralelizados (sharding lossless)**: el carril `coherence` del Release Gate se shardea **por HU** (≥ 3 HUs, `args.hus[]`) — de un solo agente opus O(HUs) a un shard por HU en paralelo con consolidación **fail-closed** y cobertura completa; nueva plantilla **`dor-fanout.workflow.js`** para los chequeos per-HU del DoR (frontmatter/G-W-T/INVEST en paralelo; el nivel épica sigue en `dor-dod-gatekeeper`, único emisor del veredicto). `security`/`smell`/`ux`/`stack_arch` quedan monolíticos a propósito (riesgo cross-cutting); `integration` sigue secuencial (regla dura §5).
 - ✅ **v0.8.2** — **capa de arquitectura (ADD)** entre discovery y construcción: comando **`/build:architect`** + skill **`setup-architecture`** que aplica el método **Attribute-Driven Design** (Len Bass) leyendo `docs/` (solo lectura) y produciendo `docs/adr/` (drivers/ASRs → tácticas → estilos → vistas → ATAM-lite → stack), con **mínimo HITL** (autónomo, una revisión final; propone, no publica). Dos agentes nuevos (`asr-extractor`, `architecture-evaluator`), plantillas ADD embebidas en la skill (`skills/setup-architecture/assets/`) y **`asset-types.json`** (forward-compat runtime v0.9: `arch.drivers`/`arch.adr`/`arch.backlog`). Cierre del lazo: los ADRs se vuelven criterios — el **DoR** exige cobertura para el cimiento fundacional (opt-in, retrocompatible) y el gate **`stack_arch`** audita conformidad contra `docs/adr/`. Total: **14 agentes**, **13 hooks**, **8 comandos `/build:*`**, **15 skills**.
 

package/VERSION

@@ -1 +1 @@
-0.8.4
+0.8.5

package/agents/build/dor-dod-gatekeeper.md

@@ -55,7 +55,10 @@ cumplen; lista cada una con ✓/✗:
    instruye descomponerla en `sub_slices[]` construidos de a uno (`journey_smoke` verde entre cada uno).
 9. **Fuente de diseño (solo slices con UI)**: si la épica toca UI, `design_source.confirmed===true`
    (fuente visual de verdad declarada para el proyecto) y la épica apunta a la(s) pantalla(s)
-   equivalente(s) del `DESIGN_SOURCE`. Si no toca UI, este criterio es N/A.
+   equivalente(s) del `DESIGN_SOURCE`. Si la fuente es un prototipo generado (convención
+   `docs/05-prototipo/`), la(s) pantalla(s) equivalente(s) deben existir en su `manifest.json` con
+   `estado: "aprobada"` — un `borrador` **no** satisface este criterio (genera/aprueba primero con
+   `/build:prototype`). Si no toca UI, este criterio es N/A.
 10. **Cobertura arquitectónica (ADR)** — *opt-in, retrocompatible*: si el proyecto adoptó la capa de
     arquitectura (existe `docs/adr/_backlog-arquitectonico.md`, generado por `/build:architect`), los
     drivers **arquitecturalmente significativos** que la épica ejerce deben tener un ADR con estado

package/agents/build/ux-fidelity-reviewer.md

@@ -20,7 +20,10 @@ igual que `ux-krug-reviewer`.
 ## Entradas (pídelas si faltan)
 - La(s) pantalla(s) del slice (rutas de la app, p.ej. `<URL-local-del-dev-server>/<ruta>`).
 - La fuente de diseño (`DESIGN_SOURCE`): archivo/URL del prototipo o export, y cómo localizar la
-  pantalla equivalente.
+  pantalla equivalente. Si apunta a un directorio de prototipo generado (convención
+  `docs/05-prototipo/`), resuelve la pantalla equivalente vía su `manifest.json` (mapa
+  pantalla↔épica/HU↔archivo) y considera **solo** las entradas `estado: "aprobada"` como fuente
+  de verdad — un `borrador` no acredita fidelidad.
 - Tokens de diseño del proyecto (los que declare el stack del PRD del consumidor: variables CSS, tema,
   design tokens), si existen.
 

package/commands/build/onboard.md

@@ -66,7 +66,10 @@ Voy a leer tu PRD/openspec para proponer valores y confirmar contigo:
    - **Decisiones de alto impacto** (`HIGH_STAKES_DECISIONS`): decisiones que exigen explicabilidad/justificación en la UI.
    - **Fuente de diseño** (`DESIGN_SOURCE`): ¿el producto tiene UI? Si sí, ruta/URL de la fuente
      visual de verdad (prototipo, export de diseño o mockups) y cómo localizar cada pantalla; si no,
-     "N/A". (La escritura del estado `design_source` en `build-state.json` se hace en la Fase 3c.)
+     "N/A". Si hay UI pero **no existe** fuente aún, indica que `/build:prototype` puede generarla
+     tras el onboarding (prototipo HTML de referencia en `docs/05-prototipo/`; la confirmación
+     sigue siendo humana). (La escritura del estado `design_source` en `build-state.json` se hace
+     en la Fase 3c.)
 3. Si un punto no aplica al proyecto, registra explícitamente "no aplica" (no lo dejes como `{{...}}`).
 
 ---
@@ -167,7 +170,8 @@ Si el usuario lo desea y existe `package.json` en el proyecto:
 Espejo de la confirmación de scaffold, para `design_source` en `build-state.json`:
 - Si el producto **tiene UI**: setea `design_source.applies=true`, `source` (el puntero confirmado) y
   `confirmed=true` **solo si** el usuario confirma que la fuente de diseño existe (con `confirmed_by`,
-  `confirmed_at`). El arnés **no genera** el prototipo.
+  `confirmed_at`). El prototipo puede generarse con `/build:prototype` (skill `prototyping-screens`);
+  `confirmed` sigue siendo exclusivamente humano.
 - Si **no hay UI**: setea `design_source.applies=false` (el mecanismo de fidelidad queda N/A).
 
 Escribe **solo** los campos del schema (`applies`, `source`, `confirmed`, `confirmed_by`, `confirmed_at`,

package/commands/build/prototype.md

@@ -0,0 +1,22 @@
+---
+name: "BUILD: Prototype"
+description: Genera o amplía el prototipo HTML de referencia (la fuente de diseño / DESIGN_SOURCE) en docs/05-prototipo/. Dos modos — greenfield (prototipo inicial desde los docs de discovery + dirección estética elegida por el humano) y feature (pantallas de una épica nueva extraídas en vivo del UI ya implementado). Delega en la skill prototyping-screens. La confirmación de design_source sigue siendo humana.
+category: Workflow
+tags: [build-harness, outer-loop, prototipo, design-source, trycore]
+---
+
+# /build:prototype — Prototipo HTML de referencia
+
+Delega en la skill **prototyping-screens**. Uso:
+
+- `/build:prototype` — modo **greenfield** (o detección automática): prototipo inicial completo.
+  Inventario de pantallas desde PRD/mapa/historias → confirmación humana → dirección estética
+  (manual de marca o 2-3 variantes a elección humana) → generación por lotes con auto-verificación.
+- `/build:prototype <épica>` — modo **feature**: pantallas nuevas de esa épica, coherentes con el
+  UX/UI ya implementado. **Precondición dura**: app corriendo + MCP de inspección de UI (p.ej.
+  chrome-devtools); sin ellos hace STOP (la extracción viva de CSS computado no se degrada).
+
+Es **outer-loop**: córrelo antes de abrir slices (como `/build:architect`). Produce
+`docs/05-prototipo/` (DESIGN.md, tokens.css, manifest.json, pantallas/) y, en greenfield con
+aprobación humana, registra `design_source` en `build-state.json`. **La skill genera; el humano
+aprueba**: `design_source.confirmed` y el `estado: "aprobada"` del manifest nunca se auto-marcan.

package/docs/commands.md

@@ -3,7 +3,7 @@
 Esta referencia cubre los **dos planos de operación** del arnés de construcción:
 
 1. El **CLI `trycore-build`** (binario Node, paquete `@trycore/spec-build-harness` v0.7.0) — instala, actualiza, diagnostica y desinstala el arnés en el proyecto consumidor. Captura el **stack mecánico**.
-2. Los **slash commands de Claude Code** (`/opsx:*` + los 8 `/build:*`: `onboard`, `reflect`, `architect`, `slice`, `release`, `work`, `resume`, `front`) — operan el pipeline de dos loops, resuelven la parametrización **semántica** del dominio y capturan el conocimiento aprendido por slice.
+2. Los **slash commands de Claude Code** (`/opsx:*` + los 9 `/build:*`: `onboard`, `reflect`, `architect`, `prototype`, `slice`, `release`, `work`, `resume`, `front`) — operan el pipeline de dos loops, resuelven la parametrización **semántica** del dominio y capturan el conocimiento aprendido por slice.
 
 > **División de responsabilidades del onboarding (dos capas).** Un binario Node **no puede** escribir la auto-memory de Claude. Por eso `trycore-build init` siembra archivos y captura el stack mecánico (lenguaje/deps, package manager, runtime, ruta del PRD), y el slash command `/build:onboard` —ejecutado por Claude— lee el PRD, pregunta por PII / capa de servicios externos-IA / capa determinista / secretos / decisiones de alto impacto, resuelve los `{{placeholders}}` del bloque marcado de `CLAUDE.md` y escribe la auto-memory.
 
@@ -52,7 +52,7 @@ Solo `init` y `update` aceptan flags. `status`, `uninstall` y `doctor` toman ún
 
 ## 2. Slash commands de Claude Code
 
-El canal CLI namespacea por subcarpeta: `.claude/commands/opsx/` → `/opsx:*` y `.claude/commands/build/` → los 8 `/build:*` (`onboard`, `reflect`, `architect`, `slice`, `release`, `work`, `resume`, `front`).
+El canal CLI namespacea por subcarpeta: `.claude/commands/opsx/` → `/opsx:*` y `.claude/commands/build/` → los 9 `/build:*` (`onboard`, `reflect`, `architect`, `prototype`, `slice`, `release`, `work`, `resume`, `front`).
 
 ### `/opsx:*` — pipeline OpenSpec
 
@@ -117,6 +117,12 @@ El canal CLI namespacea por subcarpeta: `.claude/commands/opsx/` → `/opsx:*` y
 |---|---|
 | `/build:front` | Abre y coordina un **front paralelo** de épicas NO fundacionales y disjuntas en archivos, cada una en su propio worktree/rama/PR. Delega en la skill `managing-parallel-front`: verifica precondiciones (scaffold confirmado, sin épica foundational abierta), selecciona el conjunto disjunto (`scripts/lib/front-plan.py`) y mergea en orden con re-smoke. Úsalo solo con ≥2 épicas no fundacionales disjuntas listas; para una sola épica, usa `/build:slice`. |
 
+### `/build:prototype` — prototipo HTML de referencia (fuente de diseño)
+
+| Slash command | Propósito |
+|---|---|
+| `/build:prototype` | Genera o amplía el **prototipo HTML de referencia** (el `DESIGN_SOURCE`) en `docs/05-prototipo/` (`DESIGN.md` + `tokens.css` + `manifest.json` + un HTML autocontenido por pantalla). Adaptador delgado: **delega** en la skill `prototyping-screens`. Dos modos — **greenfield** (`/build:prototype`): inventario de pantallas desde PRD/mapa/historias → confirmación humana → dirección estética (manual de marca o 2-3 variantes a elección humana) → generación por lotes con auto-verificación visual; **feature** (`/build:prototype <épica>`): pantallas nuevas coherentes con el UX/UI **ya implementado**, con **precondición dura** (app corriendo + MCP de inspección de UI: extrae CSS computado real, screenshots en 3 viewports y estructura; sin degradación estática). Es **outer-loop** (antes de abrir slices). **La skill genera; el humano aprueba**: las pantallas nacen `borrador`, solo las `aprobada` son fuente de verdad (las lee `ux-fidelity-reviewer` vía `manifest.json`) y `design_source.confirmed` sigue siendo humano. |
+
 ---
 
 ## 3. Caveat de canales (CLI vs. plugin)
@@ -126,7 +132,7 @@ El arnés se distribuye por **dos canales** que coexisten, pero **namespacean di
 | Aspecto | Canal **CLI** (canónico) | Canal **Plugin** nativo |
 |---|---|---|
 | Instalación | `npm i -g @trycore/spec-build-harness` → `trycore-build init` | `/plugin marketplace add <repo-github>` → `/plugin install trycore-spec-build-harness@trycore-build` |
-| Namespace de comandos | Por subcarpeta: `/opsx:*` y los 8 `/build:*` (`onboard`, `reflect`, `architect`, `slice`, `release`, `work`, `resume`, `front`) | Por nombre del plugin: `/trycore-spec-build-harness:*` (por diseño de Claude Code) |
+| Namespace de comandos | Por subcarpeta: `/opsx:*` y los 9 `/build:*` (`onboard`, `reflect`, `architect`, `prototype`, `slice`, `release`, `work`, `resume`, `front`) | Por nombre del plugin: `/trycore-spec-build-harness:*` (por diseño de Claude Code) |
 | Referencia a agentes | Por su nombre (p. ej. `build-orchestrator`) | Bajo el nombre del plugin |
 | Cross-references internas | ✔ Escritas para este canal (skills invocan `/opsx:*`, agentes por nombre) | Pueden no resolver según están escritas |
 | Recomendación | **Usar este canal para operar un proyecto** | Conveniencia a nivel usuario |

package/docs/getting-started.md

@@ -48,7 +48,7 @@ npm i -g @fission-ai/openspec @trycore/spec-build-harness
 
 ## 2 · `trycore-build init` (terminal)
 
-Desde la raíz de tu proyecto. Es **idempotente** (re-correrlo es seguro) y siembra: **14 agentes**, **15 skills** (`building-a-slice`, `building-a-micro-change`, `releasing-a-version`, `managing-parallel-front`, `setup-architecture` + 10 `openspec-*`), **10 comandos `/opsx:*`** + **8 comandos `/build:*`** (`onboard`, `reflect`, `architect`, `slice`, `release`, `work`, `resume`, `front`), **13 hooks**, el estado vacío `.claude/state/build-state.json` (gitignored, nunca se sobreescribe) y el bloque `<!-- BEGIN trycore-build-harness -->` en tu `CLAUDE.md` con `{{placeholders}}` sin resolver.
+Desde la raíz de tu proyecto. Es **idempotente** (re-correrlo es seguro) y siembra: **14 agentes**, **16 skills** (`building-a-slice`, `building-a-micro-change`, `releasing-a-version`, `managing-parallel-front`, `setup-architecture`, `prototyping-screens` + 10 `openspec-*`), **10 comandos `/opsx:*`** + **9 comandos `/build:*`** (`onboard`, `reflect`, `architect`, `prototype`, `slice`, `release`, `work`, `resume`, `front`), **13 hooks**, el estado vacío `.claude/state/build-state.json` (gitignored, nunca se sobreescribe) y el bloque `<!-- BEGIN trycore-build-harness -->` en tu `CLAUDE.md` con `{{placeholders}}` sin resolver.
 
 ```bash
 trycore-build init

package/docs/hooks.md

@@ -93,7 +93,7 @@ Cierra el **ciclo autocorrectivo**. Al terminar el turno, si en `history[]` hay
 
 ### 9. `design-source-guard.sh` — `PreToolUse` · Write/Edit/MultiEdit · **bloqueante** (desde v0.5.0)
 
-Refuerza el **seguro de fuente de diseño** (espejo de `scaffold-guard`, para slices con UI). Bloquea con `exit 2` la escritura de **código de un slice con UI** —cuando `active_slice.phase` ∈ `red`/`green`/`refactor`/`smoke`/`api`/`data` **y** `active_slice.gates.fidelity === false` (marcado UI-pendiente por la DoR)— mientras el proyecto tenga UI (`design_source.applies === true`) y `design_source.confirmed` no sea `true`. **Permite** todo lo demás: slices sin UI (`gates.fidelity === null` o ausente), proyectos sin UI (`applies !== true`), fases de planificación (`dor`/`change`), o fuente ya confirmada. El arnés **exige** la fuente de diseño pero **no genera** el prototipo; la confirmación es **explícita** (vía `building-a-slice` Fase 0-bis / `dor-dod-gatekeeper`), nunca auto-detectada. Guarda `python3` fail-closed dirigido. En la práctica, como `design_source` es gate de proyecto, solo muerde la **primera** construcción de UI sin fuente declarada.
+Refuerza el **seguro de fuente de diseño** (espejo de `scaffold-guard`, para slices con UI). Bloquea con `exit 2` la escritura de **código de un slice con UI** —cuando `active_slice.phase` ∈ `red`/`green`/`refactor`/`smoke`/`api`/`data` **y** `active_slice.gates.fidelity === false` (marcado UI-pendiente por la DoR)— mientras el proyecto tenga UI (`design_source.applies === true`) y `design_source.confirmed` no sea `true`. **Permite** todo lo demás: slices sin UI (`gates.fidelity === null` o ausente), proyectos sin UI (`applies !== true`), fases de planificación (`dor`/`change`), o fuente ya confirmada. El arnés **exige** la fuente de diseño y puede **generarla** vía `/build:prototype` (skill `prototyping-screens`; el mensaje de bloqueo lo sugiere); la confirmación sigue siendo **explícita y humana** (vía `building-a-slice` Fase 0-bis / `dor-dod-gatekeeper`), nunca auto-detectada. Guarda `python3` fail-closed dirigido. En la práctica, como `design_source` es gate de proyecto, solo muerde la **primera** construcción de UI sin fuente declarada.
 
 ### 10. `release-gate-nudge.sh` — `Stop` · no bloqueante (desde v0.7.0)
 

package/hooks/build/design-source-guard.sh

@@ -46,7 +46,7 @@ PY
 if [ "$VERDICT" = "BLOCK" ]; then
   echo "⛔ design-source-guard: el slice con UI está en fase de código pero la fuente de diseño NO está confirmada." >&2
   echo "   Declara y confirma primero el DESIGN_SOURCE del proyecto (ver building-a-slice Fase 0-bis / DoR)." >&2
-  echo "   El arnés NO genera el prototipo: declara la fuente (prototipo/export) y confírmala." >&2
+  echo "   Genera el prototipo con /build:prototype o declara una fuente existente (prototipo/export), y confírmala." >&2
   exit 2
 fi
 exit 0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trycore/spec-build-harness",
-  "version": "0.8.4",
+  "version": "0.8.5",
   "description": "Arnés agéntico de construcción de Trycore para Claude Code: pipeline de dos loops (slice por épica + release gate) con gates de calidad, estado compartido y OpenSpec. Compañero de @trycore/spec-product-flow. Agnóstico al proyecto.",
   "type": "module",
   "bin": {

package/skills/building-a-slice/SKILL.md

@@ -105,8 +105,9 @@ Espejo de la Fase 0, para proyectos **con UI**. Antes de abrir el primer slice c
    - `confirmed === true` → continúa.
 2. `applies===true && confirmed===false` → **pregunta explícita** (AskUserQuestion): *"¿Existe una
    fuente de diseño declarada (prototipo/export) para la UI de este proyecto?"*
-   - **No** → **STOP**. Indica declararla (ruta/URL del prototipo o export). El arnés **NO la genera**.
-     No abras el slice con UI.
+   - **No** → **STOP**. Ofrece dos salidas: **generarla con `/build:prototype`** (skill
+     `prototyping-screens`; la confirmación sigue siendo humana) o declarar una fuente externa
+     (ruta/URL del prototipo o export). No abras el slice con UI sin fuente confirmada.
    - **Sí** → registra `design_source.source`, `confirmed=true`, `confirmed_by`, `confirmed_at`, `notes`.
 3. Lo respalda el hook determinista `design-source-guard.sh` (bloquea código de slice UI sin fuente
    confirmada) y lo valida el `dor-dod-gatekeeper` (criterio duro de DoR).

package/skills/building-a-slice/references/dor.md

@@ -33,7 +33,10 @@ la épica; lo de abajo aplica a la épica y a **cada HU** que cubre (`hus[]`). L
 - [ ] **Datos de prueba disponibles** o identificables (p.ej. los datos de ejemplo / fixtures sintéticos del dominio del consumidor).
 - [ ] **Fuente de diseño identificada (slices con UI)**: la fuente visual de verdad del slice
   (el `DESIGN_SOURCE` del dominio) está declarada y confirmada (`design_source.confirmed`), y este
-  slice apunta a la(s) pantalla(s) equivalente(s). No se construye UI fuera de la fuente declarada.
+  slice apunta a la(s) pantalla(s) equivalente(s). Si la fuente es un prototipo generado
+  (`docs/05-prototipo/`), esas pantallas existen en `manifest.json` con `estado: "aprobada"`
+  (un `borrador` no satisface el criterio; genera/aprueba primero con `/build:prototype`).
+  No se construye UI fuera de la fuente declarada.
 - [ ] **Clasificación `layer`**: `foundational` (auth/datos/design-system/arquitectura base) | `business`. Se escribe en `active_slice.layer`. Gatea el front paralelo (foundational nunca en paralelo).
 - [ ] **`files_scope`**: globs de los archivos que la épica tocará (p.ej. `src/reports/**`). Fuente de la disjunción inter-épica. Se escribe en `active_slice.files_scope`.
 

package/skills/prototyping-screens/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: prototyping-screens
+description: Use when generating or extending the HTML reference prototype (the DESIGN_SOURCE) — the visual source of truth screens are built against. Two modes — greenfield (full initial prototype from discovery docs + human-chosen aesthetic direction) and feature (new-epic screens extracted live from the already-implemented UI so they look native to the app). Self-verifies visually; human approval gates everything.
+---
+
+# Prototipar pantallas de referencia (outer-loop)
+
+Genera el **prototipo HTML de referencia** del consumidor: la fuente de verdad visual
+(`DESIGN_SOURCE`) contra la que después se construyen y verifican los slices con UI
+(gate `fidelity`, `ux-fidelity-reviewer`). Si algo aquí contradice `METODOLOGIA.md`,
+**gana la metodología**.
+
+**Invariantes:**
+- La skill **genera**; el humano **aprueba**. `design_source.confirmed` y el `estado: "aprobada"`
+  del manifest son **siempre** decisiones humanas — esta skill jamás los auto-marca.
+- Es **outer-loop**: se corre antes de abrir slices (como `/build:architect`), nunca dentro del
+  inner loop de una épica.
+- Escribe **solo** en `docs/05-prototipo/` (carve-out §9.2 de METODOLOGIA) y, con aprobación
+  humana, en `design_source` de `build-state.json` (protocolo de `state/README.md`).
+
+## Artefactos que produce (repo del consumidor)
+
+```
+docs/05-prototipo/
+├── DESIGN.md          ← tokens + reglas visuales en prosa (assets/DESIGN.md.template)
+├── tokens.css         ← los mismos tokens como CSS custom properties (fuente única)
+├── manifest.json      ← pantalla ↔ épica/HU ↔ archivo ↔ estado (assets/manifest.schema.json)
+└── pantallas/
+    └── <slug>.html    ← un HTML autocontenido por pantalla (assets/screen.template.html)
+```
+
+**Reglas duras del artefacto:**
+- HTML **autocontenido**: cero dependencias externas (sin CDNs, frameworks, fetch ni JS); única
+  importación permitida: `tokens.css`; renderiza en `file://` indefinidamente; datos ilustrativos
+  estáticos.
+- Cero valores visuales fuera de tokens (color/fuente/spacing/radio/sombra → `var(--token)`).
+- Estados relevantes (vacío, error, cargando…) que la HU exija → **variantes de pantalla**
+  (`<slug>--<estado>.html`, campo `variante_de` en el manifest), no interacciones.
+- Solo pantallas `estado: "aprobada"` son fuente de verdad (las lee `ux-fidelity-reviewer`); el
+  resto son `borrador`.
+
+## Detección de modo
+
+1. No existe `docs/05-prototipo/` ni hay `design_source.confirmed` → **greenfield**.
+2. Se pide pantallas para una épica y existe app implementada (o prototipo previo) → **feature**.
+3. Ambigüedad → pregunta al humano antes de tocar nada.
+
+## Modo greenfield — prototipo inicial completo
+
+1. **Inventario de pantallas**: lee PRD, user story map/flows e historias de discovery; deriva la
+   lista pantalla ↔ épica/HU (esqueleto del `manifest.json`) y **preséntala para confirmación
+   humana** antes de generar nada.
+2. **Dirección estética**: sigue `references/aesthetic-directions.md` (¿manual de marca? → destilar
+   tokens; si no → 2-3 direcciones visuales de una pantalla clave, elección humana en navegador).
+   Salida: `DESIGN.md` + `tokens.css`.
+3. **Generación por lotes**: pantallas en orden de flow, cada una desde su HU + tokens, sobre
+   `assets/screen.template.html`. Tras cada lote: auto-verificación (`references/self-check.md`)
+   y **pausa** para revisión humana en navegador. Registra cada pantalla en el manifest como
+   `borrador`.
+
+## Modo feature — pantallas de una épica nueva (el caso brownfield)
+
+1. **Precondición dura**: la app implementada **corriendo** + un MCP de inspección de UI habilitado
+   (p.ej. chrome-devtools para web). Si falta cualquiera → **STOP** con instrucciones (levantar la
+   app / habilitar el MCP). **Sin degradación a extracción estática**: el CSS computado real es el
+   factor decisivo de fidelidad (misma postura que el gate `fidelity`, donde INCONCLUSO bloquea).
+2. **Extracción viva**: sigue `references/extraction.md` (CSS computado + screenshots en 3 viewports
+   + árbol de componentes de 2-3 pantallas representativas; reconciliación de `tokens.css`: la app
+   real gana, las divergencias se reportan como drift).
+3. **Generación**: las pantallas nuevas de la épica usan los tokens reconciliados y los screenshots
+   de la app como referencia de composición. Criterio de éxito: la pantalla nueva parece
+   **"una pantalla más"** de la app existente.
+4. **Registro**: entradas nuevas en `manifest.json` como `borrador` (con `epica`/`historias`).
+
+## Auto-verificación (ambos modos)
+
+Sigue `references/self-check.md`: renderizado real de cada HTML (`file://`), screenshot en
+3 viewports + snapshot estructural, comparación (feature → contra lo extraído de la app;
+greenfield → contra tokens + consistencia del lote), corrección y re-render con **máximo
+3 iteraciones**; si no converge, reporte al humano con el delta. Sin pixel-diff.
+
+## Aprobación humana → estado
+
+1. Abre las pantallas en el navegador del usuario y pide aprobación explícita (por pantalla o por
+   lote). Aprobada → `manifest.json` pasa esa entrada a `"aprobada"`.
+2. **Greenfield** con ≥1 pantalla aprobada: ofrece registrar la fuente en `build-state.json` —
+   `design_source.source: "docs/05-prototipo/"`, `confirmed: true`, `confirmed_by`, `confirmed_at`,
+   `notes` — siguiendo el protocolo de escritura de `state/README.md`. Solo con el **sí** explícito
+   del humano.
+3. **Feature**: `design_source` ya está confirmado; solo se amplía el manifest.
+
+## Qué NO hace esta skill
+
+- **No** hace pixel-diff (comparación estructural/semántica, como el resto del arnés).
+- **No** genera código de producción: eso es el slice normal (`building-a-slice`) con su gate
+  `fidelity`; el prototipo es su entrada, no su salida.
+- **No** prototipa interacciones/animaciones (HTML estático; estados como variantes).
+- **No** integra plataformas de diseño externas (exports no navegables ya tienen su rama en
+  `ux-fidelity-reviewer`).
+- **No** escribe en `docs/01-…04-…` ni toca otros campos del estado.

package/skills/prototyping-screens/assets/DESIGN.md.template

@@ -0,0 +1,55 @@
+# DESIGN.md — reglas visuales del producto
+
+> Fuente de verdad **en prosa** de la identidad visual. Los mismos valores viven como CSS custom
+> properties en `tokens.css` (fuente única que importan todos los prototipos). Si este archivo y
+> `tokens.css` divergen, gana `tokens.css` y la divergencia se reporta como drift.
+
+## Identidad
+
+{{DIRECCION_ELEGIDA}} — dirección visual elegida y por qué (elección humana, ver Procedencia).
+
+## Paleta
+
+| Token | Valor | Uso |
+|---|---|---|
+| `--color-primary` | {{HEX}} | {{USO}} |
+| `--color-surface` | {{HEX}} | {{USO}} |
+| `--color-text` | {{HEX}} | {{USO}} |
+| … | … | … |
+
+## Tipografía
+
+- **Familias**: {{FAMILIA_TITULARES}} (titulares) · {{FAMILIA_CUERPO}} (cuerpo).
+- **Escala**: {{ESCALA}} (p.ej. 12/14/16/20/24/32).
+- **Pesos**: {{PESOS}} y dónde se usa cada uno.
+
+## Espaciado y radios
+
+- **Spacing scale**: {{SPACING_SCALE}} (todos los márgenes/paddings son múltiplos de la escala).
+- **Radios**: {{RADIOS}} por tipo de componente.
+
+## Sombras
+
+| Token | Valor | Uso |
+|---|---|---|
+| `--shadow-1` | {{VALOR}} | {{USO}} |
+
+## Componentes
+
+Reglas por componente (densidad, alineación, jerarquía) que los prototipos deben respetar:
+
+- {{COMPONENTE}}: {{REGLA}}
+
+## Don'ts (lista explícita)
+
+- No inventar colores, fuentes, spacing ni radios fuera de los tokens.
+- No introducir dependencias externas en los prototipos (CDNs, frameworks, fuentes remotas).
+- No "interpretar" el diseño al construir: copiar valores exactos.
+- {{DONT_ESPECIFICO_DEL_PRODUCTO}}
+
+## Procedencia
+
+- **Origen de los tokens**: {{ORIGEN}} (manual de marca / extracción viva de la app / dirección
+  elegida por el humano entre variantes).
+- **Fecha**: {{FECHA_ISO}}.
+- **Reconciliaciones**: {{NOTAS_DE_DRIFT}} (cuándo la app real corrigió lo declarado).

package/skills/prototyping-screens/assets/manifest.schema.json

@@ -0,0 +1,70 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "trycore-build/prototype-manifest",
+  "title": "Manifest del prototipo de referencia (docs/05-prototipo/manifest.json)",
+  "description": "Mapa determinista pantalla ↔ épica/HU ↔ archivo HTML ↔ estado. Solo las pantallas con estado 'aprobada' son fuente de verdad visual (las lee ux-fidelity-reviewer y resuelven el puntero por-slice de la DoR).",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["version", "pantallas"],
+  "properties": {
+    "version": {
+      "type": "integer",
+      "description": "Versión del formato del manifest (hoy: 1)."
+    },
+    "pantallas": {
+      "type": "array",
+      "items": { "$ref": "#/$defs/pantalla" }
+    }
+  },
+  "$defs": {
+    "pantalla": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["slug", "archivo", "estado"],
+      "properties": {
+        "slug": {
+          "type": "string",
+          "pattern": "^[a-z0-9]+(-[a-z0-9]+)*(--[a-z0-9]+(-[a-z0-9]+)*)?$",
+          "description": "Identificador kebab-case de la pantalla. Las variantes de estado usan sufijo doble guion (p.ej. <slug>--vacio)."
+        },
+        "archivo": {
+          "type": "string",
+          "description": "Ruta relativa al directorio del prototipo (p.ej. pantallas/<slug>.html)."
+        },
+        "epica": {
+          "type": "string",
+          "pattern": "^EP-[0-9]{3}$",
+          "description": "Épica a la que pertenece la pantalla (puntero por-slice de la DoR)."
+        },
+        "historias": {
+          "type": "array",
+          "items": { "type": "string", "pattern": "^HU-[0-9]{3}$" },
+          "description": "Historias de usuario que la pantalla cubre."
+        },
+        "estado": {
+          "type": "string",
+          "enum": ["borrador", "aprobada"],
+          "description": "borrador = generada, pendiente de aprobación humana; aprobada = fuente de verdad visual (la aprobación es SIEMPRE humana)."
+        },
+        "generada_en": {
+          "type": "string",
+          "format": "date-time",
+          "description": "Cuándo se generó/regeneró (ISO-8601 UTC)."
+        },
+        "viewports_verificados": {
+          "type": "array",
+          "items": { "type": "string", "enum": ["desktop", "tablet", "mobile"] },
+          "description": "Viewports en los que el self-check renderizó y verificó la pantalla."
+        },
+        "variante_de": {
+          "type": "string",
+          "description": "Slug de la pantalla base si esta entrada es una variante de estado (vacío, error, cargando…)."
+        },
+        "notas": {
+          "type": "string",
+          "description": "Nota libre (p.ej. desviaciones intencionales aceptadas por el humano)."
+        }
+      }
+    }
+  }
+}

package/skills/prototyping-screens/assets/screen.template.html

@@ -0,0 +1,34 @@
+<!doctype html>
+<!--
+  Prototipo de referencia — pantalla {{SLUG}}
+  Reglas duras del artefacto (NO negociables):
+  - AUTOCONTENIDO: cero dependencias externas (sin CDNs, sin frameworks, sin fetch, sin JS).
+    Única importación permitida: ../tokens.css. Debe renderizar en file:// indefinidamente.
+  - TOKENS: todo color, fuente, spacing, radio y sombra sale de las custom properties de
+    ../tokens.css. Cero valores mágicos fuera de tokens.
+  - DATOS ILUSTRATIVOS ESTÁTICOS: contenido de ejemplo neutro, embebido en el HTML.
+  - ESTADOS: los estados relevantes (vacío, error, cargando) que la HU exija son VARIANTES
+    de pantalla en archivos propios ({{SLUG}}--<estado>.html), no interacciones.
+  Trazabilidad: épica {{EPICA}} · historias {{HISTORIAS}} · registrada en ../manifest.json
+-->
+<html lang="es">
+<head>
+  <meta charset="utf-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1">
+  <title>{{TITULO_PANTALLA}} — prototipo</title>
+  <link rel="stylesheet" href="../tokens.css">
+  <style>
+    /* Estilos propios de esta pantalla: SOLO composición/layout.
+       Valores visuales (color, fuente, spacing, radio, sombra) → var(--token). */
+  </style>
+</head>
+<body>
+  <!-- región: navegación / cabecera -->
+
+  <!-- región: contenido principal (composición según la HU y el patrón de layout del sistema) -->
+
+  <!-- región: paneles secundarios / laterales (si el diseño los declara) -->
+
+  <!-- región: pie / acciones globales (si el diseño lo declara) -->
+</body>
+</html>

package/skills/prototyping-screens/references/aesthetic-directions.md

@@ -0,0 +1,42 @@
+# Dirección estética (modo greenfield)
+
+Protocolo para fijar la identidad visual **antes** de generar pantallas, cuando discovery solo
+entrega docs de texto. La decisión estética es **humana**; la skill produce opciones y destila.
+
+## 1. ¿Hay manual de marca?
+
+Pregunta primero si el consumidor tiene manual de marca / brand guidelines / design system previo.
+
+- **Sí** → destila los tokens directamente de ese insumo (paleta exacta, tipografías, reglas de
+  uso) a `DESIGN.md` + `tokens.css`, con **Procedencia: manual de marca**. **No** generes
+  variantes: la identidad ya está decidida. Salta al paso 4.
+- **No** → continúa con variantes (pasos 2-3).
+
+## 2. Elegir la pantalla clave
+
+Una sola pantalla para el ejercicio: la más **representativa del journey** (la que un usuario ve
+más tiempo o la que concentra más componentes distintos — típicamente la pantalla principal de
+trabajo tras entrar). Evita pantallas triviales: no discriminan entre direcciones.
+
+## 3. Generar 2-3 direcciones y someterlas a elección humana
+
+1. Genera la pantalla clave en **2-3 direcciones visuales genuinamente distintas** — que difieran
+   en paleta, tipografía y densidad/tono (p.ej. sobria-densa · aireada-amable · contrastada-enérgica),
+   no tres matices del mismo gris. Cada dirección respeta el mismo contenido y la misma HU.
+2. Móntalas **lado a lado en un único HTML comparador** autocontenido (una columna por dirección,
+   con nombre y rasgos clave de cada una) y ábrelo en el navegador del usuario.
+3. El humano elige. Se permite **mezclar** ("la paleta de A con la tipografía de B") si lo pide.
+4. El comparador es un artefacto de trabajo: puede guardarse en `docs/05-prototipo/` como
+   `_direcciones.html` para la trazabilidad de la decisión, pero **no** entra al manifest.
+
+## 4. Destilar `DESIGN.md` + `tokens.css`
+
+De la dirección elegida (o del manual de marca):
+- `tokens.css` — custom properties: paleta completa (con variantes de énfasis/estado), familias y
+  escala tipográfica, spacing scale, radios, sombras.
+- `DESIGN.md` (`assets/DESIGN.md.template`) — la prosa: identidad y por qué se eligió, tablas de
+  tokens con uso, reglas de componentes, **Don'ts** explícitos y **Procedencia** (dirección elegida
+  + fecha).
+
+A partir de aquí, **toda** pantalla del prototipo importa `tokens.css` y no introduce valores
+fuera de tokens; el self-check (`self-check.md`) lo verifica.

package/skills/prototyping-screens/references/extraction.md

@@ -0,0 +1,57 @@
+# Extracción viva del UX/UI implementado (modo feature)
+
+Protocolo para capturar el **contexto rico real** de la app implementada antes de generar
+pantallas nuevas. La lección de fondo: la fidelidad no sale de "mirar un screenshot", sale de
+**CSS computado real + capturas multi-viewport + estructura**. Todo esto exige la app corriendo
+y un MCP de inspección de UI habilitado (p.ej. chrome-devtools para web); sin ellos, la skill
+ya hizo STOP antes de llegar aquí.
+
+## 1. Elegir pantallas representativas (2-3)
+
+Criterio: cubrir los patrones que la pantalla nueva va a necesitar —
+- la pantalla de **navegación/layout principal** (caparazón: menús, cabecera, panel central);
+- una pantalla del **mismo tipo** que la que se va a generar (listado si va a haber listado,
+  formulario si va a haber formulario, detalle si detalle);
+- si existe, una pantalla ya validada como fiel (`gates.fidelity: true` en `history[]`).
+
+## 2. Capturar por cada pantalla
+
+1. **Screenshots en 3 viewports** — desktop, tablet y mobile (redimensionar la página antes de
+   cada captura). Guardan la referencia de composición y densidad.
+2. **CSS computado de elementos clave** — vía el MCP (evaluar `getComputedStyle` sobre):
+   - tipografía real: `font-family`, `font-size`, `font-weight`, `line-height` de titular
+     principal, titular secundario, cuerpo y etiquetas;
+   - color real: `color`, `background-color`, `border-color` de superficie, texto, acción
+     primaria, acción secundaria y estados de énfasis;
+   - espaciado real: `padding`/`margin`/`gap` de los contenedores estructurales y de los
+     componentes repetidos (tarjetas, filas, campos);
+   - `border-radius` y `box-shadow` de los componentes elevados.
+3. **Árbol estructural** — snapshot del árbol accesible/DOM de la pantalla: número y disposición
+   de paneles, orden de secciones, jerarquía. Es la referencia de **composición** (estructura >
+   píxeles).
+
+## 3. Destilar y reconciliar tokens
+
+1. Consolida lo capturado en un conjunto de tokens (paleta, tipografía, spacing scale, radios,
+   sombras). Los valores repetidos entre pantallas son los tokens; los valores únicos son ruido.
+2. **Si `docs/05-prototipo/tokens.css` ya existe → reconciliar**:
+   - **La app real gana** sobre lo declarado: si el token declarado dice un valor y el CSS
+     computado dice otro de forma consistente, actualiza el token al valor real.
+   - Cada divergencia se **reporta al humano como drift** (tabla token → declarado → real →
+     pantallas donde se observó). El drift es señal de que prototipo viejo y app se separaron:
+     el humano decide si además hay que corregir la app (fuera del alcance de esta skill).
+3. Si no existe `tokens.css`, créalo desde lo extraído y genera/actualiza `DESIGN.md`
+   (`assets/DESIGN.md.template`) con **Procedencia: extracción viva** y la fecha.
+
+## 4. Empaquetar el contexto para la generación
+
+Antes de generar, deja explícito el paquete de referencia que usará la pantalla nueva:
+- `tokens.css` reconciliado;
+- screenshots de referencia (composición/densidad) de las pantallas capturadas;
+- el árbol estructural del layout principal (dónde vive el contenido en el caparazón);
+- las reglas de componentes observadas (densidad de tablas, anatomía de formularios, etc.),
+  anotadas en `DESIGN.md` si no estaban.
+
+La generación no "interpreta" este paquete: **copia valores exactos**. Toda desviación deliberada
+se anota como desviación intencional en `notas` del manifest para que `ux-fidelity-reviewer` no
+la penalice después.

package/skills/prototyping-screens/references/self-check.md

@@ -0,0 +1,40 @@
+# Auto-verificación visual del prototipo (ambos modos)
+
+El prototipo no se da por bueno porque "se escribió bien": se **renderiza de verdad y se observa
+la salida real** antes de presentarlo al humano. Misma filosofía que el gate `fidelity`
+(verificación visual real, no best-effort), aplicada en dirección inversa: aquí lo verificado es
+el prototipo recién generado.
+
+## Protocolo por pantalla generada
+
+1. **Renderizar**: abrir el HTML vía `file://` con el MCP de inspección de UI (nueva página).
+   Si el archivo no renderiza limpio (recursos rotos, consola con errores), corregir antes de
+   comparar nada.
+2. **Capturar**: screenshot en **3 viewports** (desktop, tablet, mobile) + snapshot del árbol
+   accesible/DOM.
+3. **Comparar** según el modo:
+   - **Feature** — contra el paquete de extracción (`extraction.md`): ¿la tipografía computada
+     coincide token a token? ¿la paleta usada es la reconciliada, sin colores fuera? ¿la densidad
+     (spacing computado) y el patrón de layout replican los de las pantallas capturadas? ¿la
+     pantalla "parece una más" de la app?
+   - **Greenfield** — contra `DESIGN.md`/`tokens.css`: **cero valores visuales fuera de tokens**
+     (inspeccionar computed styles de los elementos clave); y **consistencia del lote**: mismas
+     resoluciones de componente (el mismo tipo de elemento se ve igual) entre las pantallas
+     generadas en esta tanda.
+4. **Corregir y re-renderizar** cada divergencia encontrada. **Máximo 3 iteraciones** por
+   pantalla; si a la tercera no converge, **parar y reportar al humano** el delta restante
+   (qué difiere, dónde, valor esperado vs observado) — nunca presentar como buena una pantalla
+   que no pasó su self-check.
+5. **Registrar**: anotar en `manifest.json` los `viewports_verificados` de la pantalla. El
+   `estado` sigue siendo `borrador`: el self-check **no aprueba** — aprobar es del humano.
+
+## Reglas
+
+- **Sin pixel-diff**: la comparación es estructural/semántica (composición, tokens computados,
+  densidad, jerarquía), igual que `ux-fidelity-reviewer`. El pixel-diff es frágil y no discrimina
+  desviaciones que importan de ruido de render.
+- **Estructura > píxeles**: una columna de más o un panel ausente pesa más que 2px de padding.
+- Las **variantes de estado** (`<slug>--<estado>.html`) pasan el mismo protocolo (suelen ser más
+  baratas: heredan la composición de la base).
+- El self-check corre **por lote** en greenfield (tras generar cada tanda) y **por pantalla** en
+  feature (pocas pantallas, más exigencia de encaje con la app).

package/state/README.md

@@ -56,8 +56,9 @@ slice (fases `red…data`) mientras `confirmed` no sea `true`. El arnés **no ge
 ### `design_source` (gate de proyecto, slices con UI)
 
 Espejo de `scaffold` para la UI: `applies` (¿el proyecto tiene UI?), `confirmed` (humano confirmó que
-existe una fuente de diseño declarada), `source` (puntero al prototipo/export). El arnés NO genera el
-prototipo. Lo respalda `design-source-guard.sh`.
+existe una fuente de diseño declarada), `source` (puntero al prototipo/export). El prototipo puede
+**generarse** con `/build:prototype` (skill `prototyping-screens`, salida en `docs/05-prototipo/`);
+`confirmed` sigue siendo exclusivamente humano. Lo respalda `design-source-guard.sh`.
 
 ### `foundation` (gate de proyecto, solo greenfield) + `project_kind`
 
@@ -124,3 +125,4 @@ El razonamiento vive en el modelo; el hook solo es un recordatorio determinista.
 | `foundation` (`required`, `checklist[]`, `epic`) | `/build:onboard` Fase 2c | una vez (greenfield) |
 | `foundation.checklist[].evidence` | `build-orchestrator` (durante la construcción de la caparazón) | al construir la caparazón |
 | `foundation.completed_at` | `dor-dod-gatekeeper` (al cerrar el DoD de la épica caparazón) | al archivar la caparazón |
+| `design_source` (`source`, `confirmed`, `confirmed_by/at`, `notes`) | `building-a-slice` Fase 0-bis · `/build:onboard` Fase 3c · `prototyping-screens` (greenfield, solo tras aprobación humana de ≥1 pantalla; `confirmed` humano siempre) | una vez (proyecto) |

package/state/build-state.schema.json

@@ -64,7 +64,7 @@
     "design_source": {
       "type": "object",
       "additionalProperties": false,
-      "description": "Gate de PROYECTO para slices con UI: existe una fuente de diseño declarada (prototipo/export). Espejo de scaffold: confirmed pasa a true SOLO por confirmación humana, nunca por auto-detección. El arnés NO genera el prototipo. applies=false apaga todo el mecanismo (proyecto sin UI).",
+      "description": "Gate de PROYECTO para slices con UI: existe una fuente de diseño declarada (prototipo/export). Espejo de scaffold: confirmed pasa a true SOLO por confirmación humana, nunca por auto-detección. El prototipo puede generarse con /build:prototype (skill prototyping-screens); confirmed sigue siendo exclusivamente humano. applies=false apaga todo el mecanismo (proyecto sin UI).",
       "required": ["applies", "confirmed"],
       "properties": {
         "applies": { "type": "boolean", "description": "¿el proyecto tiene UI / hay diseño que respetar? false → mecanismo N/A." },

package/templates/CLAUDE.md.template

@@ -51,7 +51,7 @@ Estos puntos de extensión los leen los agentes `security-reviewer`, `stack-guar
 - **Categorías de datos sensibles / PII reguladas**: {{SENSITIVE_DATA_CATEGORIES}}
 - **Secretos server-side**: {{SERVER_SIDE_SECRETS}}
 - **Decisiones de alto impacto que exigen explicabilidad UX**: {{HIGH_STAKES_DECISIONS}}
-- **Fuente de diseño / referencia visual**: {{DESIGN_SOURCE}}
+- **Fuente de diseño / referencia visual**: {{DESIGN_SOURCE}} (si no existe fuente aún, `/build:prototype` puede generarla en `docs/05-prototipo/`; la confirmación sigue siendo humana)
 
 (Si aparecen como `{{...}}`, ejecuta `/build:onboard` para parametrizarlos.)