@damiangilgonzalez/harness 1.3.7

package/skills/proposals/scripts/verify.sh

@@ -0,0 +1,201 @@
+#!/usr/bin/env bash
+#
+# verify.sh — structural lint for a proposal / SOW markdown draft.
+#
+# WHAT IT DOES (read-only; never edits a file)
+#   Greps a generated proposal/SOW markdown for its required-section contract and
+#   flags scope-creep and smuggled-legal language. It is a STRUCTURE check, not a
+#   quality judgement — the persuasion rigor lives in the capability eval.
+#     1. Required proposal sections present: executive summary, scope, pricing/
+#        investment, timeline, next step.
+#     2. If the doc looks like a SOW, its required clauses are present:
+#        exclusions, acceptance criteria, change order, payment schedule.
+#     3. Weasel / scope-creep ban-list ABSENT: "etc.", "as needed", "and more",
+#        "TBD" (in scope), unbounded "ongoing".  -> FAIL (these lose free-work fights)
+#     4. Binding-legal smuggle WARNING: "indemnif", "governing law",
+#        "limitation of liability", "intellectual property assigns/assignment".
+#        -> warn "route to contracts" (do not draft binding terms here).
+#     5. Executive-summary length 200–400 words -> warn if outside.
+#
+# EXIT CODES
+#   0  clean, or no target file to inspect (empty target is NOT a failure),
+#      or warn-only findings
+#   1  a required section is missing, or a banned weasel word is present
+#   2  bad usage
+#
+# HOW TO RUN (point it at YOUR draft, not the skills repo)
+#   ./verify.sh proposal.md            # lint one file
+#   ./verify.sh --path proposals/      # lint every *.md / *.markdown under a dir
+#   ./verify.sh                        # scan ./ ; if nothing matches, skip + exit 0
+#
+# Runs on stock macOS bash 3.2: no mapfile, no associative arrays.
+
+set -euo pipefail
+
+if [ -t 1 ]; then
+  RED=$'\033[31m'; GREEN=$'\033[32m'; YELLOW=$'\033[33m'; NC=$'\033[0m'
+else
+  RED=''; GREEN=''; YELLOW=''; NC=''
+fi
+
+ok_count=0; skip_count=0; warn_count=0; fail_count=0
+ok()   { printf '%s[ ok ]%s %s\n' "$GREEN"  "$NC" "$*"; ok_count=$((ok_count + 1)); }
+skip() { printf '%s[skip]%s %s\n' "$YELLOW" "$NC" "$*"; skip_count=$((skip_count + 1)); }
+warn() { printf '%s[warn]%s %s\n' "$YELLOW" "$NC" "$*"; warn_count=$((warn_count + 1)); }
+fail() { printf '%s[fail]%s %s\n' "$RED"    "$NC" "$*"; fail_count=$((fail_count + 1)); }
+
+usage() { sed -n '2,33p' "$0" | sed 's/^# \{0,1\}//'; }
+
+# --- arg parse --------------------------------------------------------------
+SCAN_PATH=""
+while [ $# -gt 0 ]; do
+  case "$1" in
+    --path)    SCAN_PATH="${2:?--path needs a value}"; shift 2 ;;
+    -h|--help) usage; exit 0 ;;
+    -*)        printf '%sUnknown argument: %s%s\n\n' "$RED" "$1" "$NC"; usage; exit 2 ;;
+    *)         SCAN_PATH="$1"; shift ;;
+  esac
+done
+[ -z "$SCAN_PATH" ] && SCAN_PATH="."
+
+if [ ! -e "$SCAN_PATH" ]; then
+  printf '%sPath not found: %s%s\n' "$RED" "$SCAN_PATH" "$NC"; exit 2
+fi
+
+have() { command -v "$1" >/dev/null 2>&1; }
+
+# --- collect candidate markdown files --------------------------------------
+# A single file is used as-is; a directory is searched for *.md / *.markdown.
+FILES=""
+if [ -f "$SCAN_PATH" ]; then
+  FILES="$SCAN_PATH"
+else
+  FILES="$(find "$SCAN_PATH" -type f \( -name '*.md' -o -name '*.markdown' \) 2>/dev/null || true)"
+fi
+
+# Empty / clean target is NOT a failure — nothing to lint, exit 0.
+if [ -z "$FILES" ]; then
+  skip "no proposal/SOW markdown found under '$SCAN_PATH' — nothing to lint"
+  printf '\nok=%d skip=%d warn=%d fail=%d\n' "$ok_count" "$skip_count" "$warn_count" "$fail_count"
+  exit 0
+fi
+
+# gci <pattern> <file>: case-insensitive grep, swallow no-match (so set -e is safe).
+gci() { grep -iE -e "$1" "$2" >/dev/null 2>&1; }
+
+# word_count_section <file> <start-heading-regex>: words from the first matching
+# heading until the next markdown "## " heading. 0 if the heading is absent.
+exec_summary_words() {
+  awk '
+    BEGIN { inseg=0; words=0 }
+    tolower($0) ~ /^#+ +(executive summary|exec summary|resumen ejecutivo|resum executiu)/ { inseg=1; next }
+    inseg && /^#{1,6} / { inseg=0 }
+    inseg { words += NF }
+    END { print words+0 }
+  ' "$1"
+}
+
+printf 'Linting %d file(s) under: %s\n\n' "$(printf '%s\n' "$FILES" | grep -c .)" "$SCAN_PATH"
+
+# --- per-file checks --------------------------------------------------------
+printf '%s\n' "$FILES" | while IFS= read -r f; do
+  [ -z "$f" ] && continue
+  printf '%s— %s%s\n' "$YELLOW" "$f" "$NC"
+
+  # 1. required proposal sections
+  gci 'executive summary|exec summary|resumen ejecutivo|resum executiu' "$f" \
+    && ok "  exec summary present" || fail "  missing executive summary"
+  gci '(^|[^a-z])scope([^a-z]|$)|what.?s included|abast|alcance' "$f" \
+    && ok "  scope present" || fail "  missing scope section"
+  gci 'pricing|investment|tiers?|inversi|preu|precio' "$f" \
+    && ok "  pricing/investment present" || fail "  missing pricing/investment section"
+  gci 'timeline|milestones?|calendari|cronograma' "$f" \
+    && ok "  timeline/milestones present" || fail "  missing timeline section"
+  gci 'next steps?|mutual action|propers passos|pr.ximos pasos|call to action' "$f" \
+    && ok "  next-step/close present" || fail "  missing next-step/close"
+
+  # 2. SOW-specific clauses (only if the doc declares itself a SOW)
+  if gci 'statement of work|scope of work|^#.*\bsow\b|abast del projecte' "$f"; then
+    ok "  detected SOW — checking SOW clauses"
+    gci 'exclud|exclusion|not (in scope|included)|out of scope|fora d.abast|excluido' "$f" \
+      && ok "    explicit exclusions present" || fail "    SOW missing explicit EXCLUSIONS"
+    gci 'acceptance criteria|accept(ed|ance)|criteris d.acceptaci|criterios de aceptaci' "$f" \
+      && ok "    acceptance criteria present" || fail "    SOW missing acceptance criteria"
+    gci 'change order|change.?request|written approval|ordre de canvi|orden de cambio' "$f" \
+      && ok "    change-order clause present" || fail "    SOW missing change-order clause"
+    gci 'payment (schedule|milestones?|terms)|on signature|on acceptance|calendari de pagament' "$f" \
+      && ok "    payment schedule present" || fail "    SOW missing payment schedule"
+  else
+    skip "  not a SOW (skipping SOW-specific clause checks)"
+  fi
+
+  # 3. weasel / scope-creep ban-list -> FAIL
+  weasel="$(grep -inE 'etc\.|[^a-z]as needed|and more|[^a-z]tbd[^a-z]|ongoing (support|work|maintenance)' "$f" 2>/dev/null || true)"
+  if [ -n "$weasel" ]; then
+    fail "  weasel / scope-creep words (bound them with a quantity):"
+    printf '%s\n' "$weasel" | head -n 5 | sed 's/^/        /'
+  else
+    ok "  no weasel / scope-creep words"
+  fi
+
+  # 4. binding-legal smuggle -> WARN (route to contracts)
+  legal="$(grep -inE 'indemnif|governing law|limitation of liability|intellectual property (assigns|assignment)|liability cap' "$f" 2>/dev/null || true)"
+  if [ -n "$legal" ]; then
+    warn "  binding-legal language found — route these to the contracts skill / MSA:"
+    printf '%s\n' "$legal" | head -n 5 | sed 's/^/        /'
+  else
+    ok "  no smuggled binding-legal clauses"
+  fi
+
+  # 5. exec-summary length 200–400 words -> WARN
+  w="$(exec_summary_words "$f")"
+  if [ "$w" -eq 0 ]; then
+    : # absence already reported in check 1
+  elif [ "$w" -lt 200 ] || [ "$w" -gt 400 ]; then
+    warn "  exec summary is $w words (aim 200–400)"
+  else
+    ok "  exec summary length ok ($w words)"
+  fi
+  printf '\n'
+done
+
+# The while-pipe runs in a subshell under bash 3.2, so its counters don't survive.
+# Re-derive the pass/fail decision from a second, quiet aggregate pass.
+agg_fail=0
+while IFS= read -r f; do
+  [ -z "$f" ] && continue
+  for p in \
+    'executive summary|exec summary|resumen ejecutivo|resum executiu' \
+    '(^|[^a-z])scope([^a-z]|$)|what.?s included|abast|alcance' \
+    'pricing|investment|tiers?|inversi|preu|precio' \
+    'timeline|milestones?|calendari|cronograma' \
+    'next steps?|mutual action|propers passos|pr.ximos pasos|call to action'
+  do
+    gci "$p" "$f" || agg_fail=$((agg_fail + 1))
+  done
+  if gci 'statement of work|scope of work|^#.*\bsow\b|abast del projecte' "$f"; then
+    for p in \
+      'exclud|exclusion|not (in scope|included)|out of scope|fora d.abast|excluido' \
+      'acceptance criteria|accept(ed|ance)|criteris d.acceptaci|criterios de aceptaci' \
+      'change order|change.?request|written approval|ordre de canvi|orden de cambio' \
+      'payment (schedule|milestones?|terms)|on signature|on acceptance|calendari de pagament'
+    do
+      gci "$p" "$f" || agg_fail=$((agg_fail + 1))
+    done
+  fi
+  if grep -iE 'etc\.|[^a-z]as needed|and more|[^a-z]tbd[^a-z]|ongoing (support|work|maintenance)' "$f" >/dev/null 2>&1; then
+    agg_fail=$((agg_fail + 1))
+  fi
+done <<EOF
+$FILES
+EOF
+
+printf 'Done. (re-run after fixing any [fail] lines above)\n'
+cat <<'NOTE'
+
+Note: [fail] = a broken section contract or scope-creep word (fix before sending).
+      [warn] = binding-legal language or an off-length exec summary (review/justify).
+NOTE
+
+if [ "$agg_fail" -gt 0 ]; then exit 1; fi
+exit 0

package/skills/prototype/LOGIC.md

@@ -0,0 +1,79 @@
+# Prototipo de Lógica
+
+Una mini-app de terminal interactiva que deja al usuario manejar un modelo de estados a mano. Úsala cuando la pregunta es sobre **lógica de negocio, transiciones de estado o forma de los datos** — ese tipo de cosa que parece razonable sobre el papel pero solo se siente mal cuando la empujas por casos reales.
+
+## Cuándo esta es la forma correcta
+
+- "No estoy seguro de si esta máquina de estados maneja el caso límite en que ocurre X y luego Y."
+- "¿Este modelo de datos realmente me deja representar el caso en que...?"
+- "Quiero tantear qué aspecto debería tener la API antes de escribirla."
+- Cualquier cosa donde el usuario quiera **pulsar botones y ver cómo cambia el estado**.
+
+Si la pregunta es "qué aspecto debería tener esto" — rama equivocada. Usa [UI.md](UI.md).
+
+## Proceso
+
+### 1. Enuncia la pregunta
+
+Antes de escribir código, anota qué modelo de estados y qué pregunta estás prototipando. Un párrafo, en el README del prototipo o en un comentario al principio del archivo. Un prototipo de lógica que responde a la pregunta equivocada es puro desperdicio — haz la pregunta explícita para poder comprobarla más tarde, tanto si el usuario está mirando ahora como si vuelve a ello después.
+
+### 2. Elige el lenguaje
+
+Usa el que use el proyecto anfitrión. Si el proyecto no tiene un runtime obvio (p. ej. un repo de documentación), pregunta.
+
+Sigue las convenciones de herramientas del proyecto — no añadas un gestor de paquetes o un runtime nuevo solo para el prototipo.
+
+### 3. Aísla la lógica en un módulo portable
+
+Pon la lógica de verdad — la parte que responde a la pregunta — detrás de una interfaz pequeña y pura que pueda extraerse y colocarse en el código real más tarde. La TUI que la rodea es desechable; el módulo de lógica no debería serlo.
+
+La forma correcta depende de la pregunta:
+
+- **Un reducer puro** — `(estado, acción) => estado`. Bueno cuando las acciones son eventos discretos y el estado es un único valor.
+- **Una máquina de estados** — estados y transiciones explícitos. Bueno cuando "qué acciones son siquiera legales ahora mismo" forma parte de la pregunta.
+- **Un pequeño conjunto de funciones puras** sobre un tipo de dato plano. Bueno cuando no hay un estado actual implícito — solo transformaciones.
+- **Una clase o módulo con una superficie de métodos clara** cuando la lógica realmente es dueña de un estado interno continuo.
+
+Elige la forma que mejor encaje con la pregunta que se hace, y *no* la que sea más fácil de conectar a una TUI. Mantenla pura: sin I/O, sin código de terminal, sin `console.log` para el flujo de control. La TUI la importa y la invoca; nada fluye en el otro sentido.
+
+Esto es lo que hace útil al prototipo más allá de su propia vida: cuando la pregunta ha sido respondida, el reducer / máquina / conjunto de funciones validado puede extraerse al módulo real por sí solo.
+
+### 4. Construye la TUI más pequeña que exponga el estado
+
+Constrúyela como una **TUI ligera** — en cada tick, limpia la pantalla (`console.clear()` / `print("\033[2J\033[H")` / equivalente) y vuelve a renderizar el frame entero. El usuario debe ver siempre una vista estable, no un scrollback que crece sin parar.
+
+Cada frame tiene dos partes, en este orden:
+
+1. **Estado actual**, impreso de forma bonita y fácil de comparar (un campo por línea, o JSON formateado). Usa **negrita** para nombres de campo o encabezados de sección y **atenuado** para el contexto menos importante (timestamps, IDs, valores derivados). Los códigos de escape ANSI nativos valen — `\x1b[1m` negrita, `\x1b[2m` atenuado, `\x1b[0m` reset. No hace falta traer una librería de estilos salvo que ya haya una en el proyecto.
+2. **Atajos de teclado**, listados abajo: `[a] añadir usuario  [d] borrar usuario  [t] avanzar reloj  [q] salir`. Pon la tecla en negrita y la descripción atenuada, o al revés — lo que se lea limpio.
+
+Comportamiento:
+
+1. **Inicializa el estado** — un único objeto/struct en memoria. Renderiza el primer frame al arrancar.
+2. **Lee una pulsación (o una línea)** cada vez, despáchala a un handler que muta el estado.
+3. **Vuelve a renderizar** el frame completo tras cada acción — no añadas, reemplaza.
+4. **Bucle hasta salir.**
+
+El frame entero debería caber en una pantalla.
+
+### 5. Hazlo ejecutable con un solo comando
+
+Añade un script al gestor de tareas existente del proyecto (`scripts` de `package.json`, `Makefile`, `justfile`, `pyproject.toml`). El usuario debería ejecutar `pnpm run <nombre-prototipo>` o equivalente — nunca tener que recordar una ruta.
+
+Si el proyecto anfitrión no tiene gestor de tareas, pon el comando al principio del README del prototipo.
+
+### 6. Entrégalo
+
+Dale al usuario el comando para ejecutarlo. Él lo manejará; los momentos interesantes son cuando dice "espera, eso no debería ser posible" o "anda, yo asumía que X sería distinto" — esos son los bugs de la _idea_, que es de lo que va todo esto. Si quiere que se añadan acciones nuevas, añádelas. Los prototipos evolucionan.
+
+### 7. Captura la respuesta y el prototipo
+
+Una vez el prototipo ha respondido a su pregunta, captura la respuesta y luego captura el prototipo como describe la [SKILL](SKILL.md). El mapeo específico de lógica: el reducer / máquina / conjunto de funciones validado se extrae al módulo real (la decisión, absorbida); la carcasa de la TUI acompaña a la rama desechable que conserva el prototipo como fuente primaria.
+
+## Antipatrones
+
+- **No añadas tests.** Un prototipo que necesita tests ya no es un prototipo.
+- **No lo conectes a la base de datos real.** Usa un almacén en memoria salvo que la pregunta sea específicamente sobre persistencia.
+- **No generalices.** Nada de "¿y si más adelante quisiéramos soportar X?". El prototipo responde a una pregunta.
+- **No mezcles la lógica y la TUI.** Si el reducer / máquina de estados referencia `console.log`, prompts o códigos de escape de terminal, ya no es portable. Mantén la TUI como una carcasa fina sobre un módulo puro.
+- **No lleves la carcasa de la TUI a producción.** La carcasa está optimizada para manejarse a mano desde una terminal. El módulo de lógica que hay detrás es lo que vale la pena conservar.

package/skills/prototype/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: prototype
+description: "Builds a throwaway prototype to answer a design question. Use when the user wants to check whether a state model or logic \\"feels right\\", or explore what a UI should look like."
+tags: ["prototyping", "design", "exploration"]
+profiles: [core, ui, full]
+---
+
+# Prototipo
+
+Un prototipo es **código desechable que responde a una pregunta**. La pregunta decide la forma.
+
+## Elige la rama
+
+Identifica qué pregunta se está respondiendo — a partir del mensaje del usuario, del código de alrededor, o preguntándole si está disponible:
+
+- **"¿Esta lógica / este modelo de estados se siente bien?"** → [LOGIC.md](LOGIC.md). Construye una mini-app de terminal interactiva que empuje la máquina de estados a través de casos difíciles de razonar sobre el papel.
+- **"¿Qué aspecto debería tener esto?"** → [UI.md](UI.md). Genera varias variaciones de UI radicalmente distintas en una sola ruta, conmutables mediante un parámetro de búsqueda en la URL y una barra flotante inferior.
+
+Las dos ramas producen artefactos muy diferentes — equivocarse aquí desperdicia el prototipo entero. Si la pregunta es genuinamente ambigua y el usuario no está localizable, elige por defecto la rama que mejor encaje con el código de alrededor (un módulo de backend → lógica; una página o componente → UI) y deja escrita la suposición al principio del prototipo.
+
+## Reglas que aplican a ambas ramas
+
+1. **Desechable desde el primer día, y marcado claramente como tal.** Ubica el código del prototipo cerca de donde se usará de verdad (junto al módulo o la página que está prototipando) para que el contexto sea obvio — pero nómbralo de forma que cualquier lector casual vea que es un prototipo, no producción. Para rutas de UI desechables, respeta la convención de rutas que el proyecto ya use; no inventes una estructura nueva de nivel superior.
+2. **Un solo comando para ejecutarlo.** Lo que el gestor de tareas del proyecto ya soporte — `pnpm <nombre>`, `python <ruta>`, `bun <ruta>`, etc. El usuario debe poder arrancarlo sin pensar.
+3. **Sin persistencia por defecto.** El estado vive en memoria. La persistencia es lo que el prototipo está _comprobando_, no algo de lo que deba depender. Si la pregunta implica explícitamente una base de datos, usa una BD de usar y tirar o un archivo local con un nombre claro tipo "PROTOTIPO — bórrame".
+4. **Sáltate el pulido.** Sin tests, sin manejo de errores más allá de lo que haga el prototipo _ejecutable_, sin abstracciones. El objetivo es aprender algo rápido.
+5. **Muestra el estado.** Tras cada acción (lógica) o en cada cambio de variante (UI), imprime o renderiza todo el estado relevante para que el usuario vea qué cambió.
+6. **Captúralo cuando termines.** Integra la decisión validada en el código real, y luego captura el prototipo en sí como **fuente primaria**: commitéalo a una rama desechable, fuera de main, y deja un puntero de contexto a esa rama en el issue de implementación. Captura también la respuesta — el veredicto y la pregunta que zanjó — en el issue o en un commit. La rama main conserva solo la decisión validada.

package/skills/prototype/UI.md

@@ -0,0 +1,112 @@
+# Prototipo de UI
+
+Genera **varias variaciones de UI radicalmente distintas** en una sola ruta, conmutables desde una barra flotante inferior. El usuario alterna entre variantes en el navegador, elige una (o roba trozos de cada una) y tira el resto.
+
+Si la pregunta es sobre lógica/estado en lugar de qué aspecto tiene algo — rama equivocada. Usa [LOGIC.md](LOGIC.md).
+
+## Cuándo esta es la forma correcta
+
+- "¿Qué aspecto debería tener esta página?"
+- "Quiero ver unas cuantas opciones para este dashboard antes de comprometerme."
+- "Prueba una disposición distinta para la pantalla de ajustes."
+- Cualquier momento en que el usuario, si no, se pasaría un día eligiendo entre tres mockups vagos que tiene en la cabeza.
+
+## Dos sub-formas — prefiere claramente la sub-forma A
+
+Una UI se juzga mucho mejor cuando está **pegada al resto de la app** — header real, sidebar real, datos reales, densidad real. Una ruta desechable por sí sola es un vacío: toda variante se ve bien aislada. Elige por defecto la sub-forma A siempre que haya una página existente plausible que aloje las variantes. Recurre a la sub-forma B solo si el prototipo genuinamente no tiene un hogar cercano.
+
+### Sub-forma A — ajuste sobre una página existente (preferida)
+
+La ruta ya existe. Las variantes se renderizan **en la misma ruta**, condicionadas por un parámetro de búsqueda `?variant=` en la URL. La obtención de datos, los parámetros y la autenticación existentes se mantienen — solo cambia el renderizado. Esta es la opción por defecto; elígela salvo que haya una razón específica para no hacerlo.
+
+Si el prototipo es para algo que aún no tiene página pero *viviría de forma natural dentro de una* (una sección nueva del dashboard, una tarjeta nueva en la pantalla de ajustes, un paso nuevo en un flujo existente) — eso sigue siendo sub-forma A. Monta las variantes dentro de la página anfitriona.
+
+### Sub-forma B — una página nueva (último recurso)
+
+Úsala solo cuando lo que se está prototipando genuinamente no tiene página existente donde vivir — p. ej. una superficie de nivel superior completamente nueva, o un flujo que no puede incrustarse en ningún sitio con sentido.
+
+Crea una **ruta desechable** siguiendo la convención de rutas que el proyecto ya use — no inventes una estructura nueva de nivel superior. Nómbrala de forma que sea obvio que es un prototipo (p. ej. incluye la palabra `prototype` en la ruta o el nombre de archivo). Mismo patrón `?variant=`.
+
+Antes de comprometerte con la sub-forma B, comprueba: ¿de verdad no hay ninguna página existente donde esto pudiera incrustarse? Una ruta vacía esconde problemas de diseño que una poblada sí expondría.
+
+En ambas sub-formas la barra flotante inferior es idéntica.
+
+## Proceso
+
+### 1. Enuncia la pregunta y elige N
+
+Por defecto, **3 variantes**. Más de 5 deja de ser radicalmente distinto y empieza a ser ruido — pon el tope ahí.
+
+Anota el plan en una línea, en la ubicación del prototipo o en un comentario al principio del archivo:
+
+> "Tres variantes de la página de ajustes, conmutables vía `?variant=`, en la ruta existente `/settings`."
+
+Esto funciona tanto si el usuario está aquí para rebatir como si no.
+
+### 2. Genera variantes radicalmente distintas
+
+Redacta cada variante. Somete cada una a:
+
+- El propósito de la página y los datos a los que tiene acceso.
+- La librería de componentes / sistema de estilos del proyecto (TailwindCSS, shadcn, MUI, CSS plano, lo que sea).
+- Un nombre de componente exportado claro, p. ej. `VariantA`, `VariantB`, `VariantC`.
+
+Las variantes deben ser **estructuralmente distintas** — distinta disposición, distinta jerarquía de información, distinta acción principal, no solo distintos colores. Tres rejillas de tarjetas ligeramente ajustadas no es un prototipo de UI, es papel pintado. Si dos borradores salen demasiado parecidos, rehaz uno con la indicación explícita de "no uses una rejilla de tarjetas".
+
+### 3. Conéctalas
+
+Crea un único componente conmutador en la ruta:
+
+```tsx
+// pseudocódigo — adáptalo al framework del proyecto
+const variant = searchParams.get('variant') ?? 'A';
+return (
+  <>
+    {variant === 'A' && <VariantA {...data} />}
+    {variant === 'B' && <VariantB {...data} />}
+    {variant === 'C' && <VariantC {...data} />}
+    <PrototypeSwitcher variants={['A','B','C']} current={variant} />
+  </>
+);
+```
+
+Para la sub-forma A (página existente): mantén toda la obtención de datos existente por encima del conmutador; solo cambia el subárbol renderizado por variante.
+
+Para la sub-forma B (página nueva): la ruta desechable bajo `/prototype/<nombre>` monta el mismo conmutador.
+
+### 4. Construye el conmutador flotante
+
+Una pequeña barra de posición fija en el centro-inferior de la pantalla con tres piezas:
+
+- **Flecha izquierda** — pasa a la variante anterior (da la vuelta al llegar al final).
+- **Etiqueta de variante** — muestra la clave de la variante actual y, si la variante exporta un nombre, también ese nombre. P. ej. `B — Disposición con sidebar`.
+- **Flecha derecha** — avanza (da la vuelta).
+
+Comportamiento:
+
+- Al pulsar una flecha se actualiza el parámetro de búsqueda de la URL (usa el router del framework — `router.replace` en Next, `navigate` en React Router, etc.) para que la variante sea compartible y estable al recargar.
+- Teclado: las teclas `←` y `→` también rotan. No interceptes las flechas cuando un `<input>`, `<textarea>` o `[contenteditable]` tenga el foco.
+- Visualmente distinta de la página (p. ej. una pastilla de alto contraste, sombra sutil) para que sea obvio que no forma parte del diseño que se está evaluando.
+- Oculta en builds de producción — condiciónala con `process.env.NODE_ENV !== 'production'` o una comprobación equivalente, para que un merge despistado del prototipo no pueda enviar la barra a los usuarios.
+
+Pon el conmutador en un único componente compartido para que ambas sub-formas puedan reutilizarlo. Ubícalo donde vivan los componentes de UI compartidos en el proyecto.
+
+### 5. Entrégalo
+
+Muestra la URL (y las claves `?variant=`). El usuario irá alternando cuando pueda. El feedback interesante suele ser **"quiero el header de B con el sidebar de C"** — ese es el diseño real que quiere.
+
+### 6. Captura la respuesta y limpia
+
+Una vez una variante ha ganado, captura la respuesta — qué variante y por qué — y luego captura el prototipo como describe la [SKILL](SKILL.md). Integra la ganadora en el código real y mueve el resto a la rama desechable, no a main:
+
+- **Sub-forma A** — integra la ganadora en la página existente; quita de main las variantes perdedoras y el conmutador.
+- **Sub-forma B** — promociona la variante ganadora a una ruta real; quita de main la ruta desechable y el conmutador.
+
+El conjunto completo de variantes es la fuente primaria, así que aterriza en la rama desechable, no en la papelera — los componentes de variantes y el conmutador que se quedan en main se pudren rápido y confunden al siguiente lector.
+
+## Antipatrones
+
+- **Variantes que solo difieren en color o texto.** Eso es un ajuste, no un prototipo. Las variantes reales discrepan sobre la estructura.
+- **Compartir demasiado código entre variantes.** Un `<Header>` compartido está bien; un `<Layout>` compartido arruina el propósito. Cada variante debe ser libre de tirar la disposición.
+- **Conectar las variantes a mutaciones reales.** Los prototipos de solo lectura están bien. Si una variante necesita mutar, apúntala a un stub — la pregunta es "qué aspecto debería tener esto", no "funciona el backend".
+- **Promocionar el prototipo directamente a producción.** El código de la variante se escribió bajo restricciones de prototipo (sin tests, manejo de errores mínimo). Reescríbelo bien cuando lo integres.

package/skills/prototype/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "Prototype"
+  short_description: "Prototype to answer a design question"

package/skills/prototype/evals/cases.yaml

@@ -0,0 +1,32 @@
+skill: prototype
+
+should_trigger:
+  - prompt: "Quiero un prototipo desechable para ver si esta logica se siente bien."
+    why: "Disparador directo de prototype."
+  - prompt: "Explora que aspecto deberia tener esta UI antes de construirla de verdad."
+    why: "Disparador directo de prototype."
+  - prompt: "Haz una prueba rapida de este modelo de estados."
+    why: "Disparador directo de prototype."
+  - prompt: "Build a throwaway prototype to test this interaction."
+    why: "Disparador directo de prototype."
+  - prompt: "Necesito ver si este flujo funciona antes de invertir tiempo en el."
+    why: "Disparador directo de prototype."
+
+should_not_trigger:
+  - prompt: "Implementa la version final de produccion de esta pantalla."
+    route_to: "implement"
+    why: "Implementar la version final de produccion es el trabajo de implement, no de prototype."
+  - prompt: "Escribe los tests unitarios de este modulo."
+    route_to: "none"
+    why: "Fuera del alcance de prototype."
+  - prompt: "Documenta la decision de arquitectura que tomamos."
+    route_to: "write-adr"
+    why: "Documentar una decision de arquitectura es el trabajo de write-adr, no de prototype."
+  - prompt: "Revisa el codigo que acabo de escribir."
+    route_to: "revision-de-cambios"
+    why: "Revisar el trabajo recien escrito y sin commitear es el trabajo de revision-de-cambios, no de prototype."
+
+capability:
+  - scenario: "El usuario quiere comprobar si una idea de diseno funciona antes de construirla."
+    must_include:
+      - "prototipo"