@damiangilgonzalez/harness 1.3.7

package/skills/tauri/scripts/verify.sh

@@ -0,0 +1,178 @@
+#!/usr/bin/env bash
+# verify.sh — read-only static lint for a Tauri v2 project (src-tauri/ tree).
+#
+# Mirrors the SKILL.md anti-patterns so the advice is checkable. It scans the
+# target for the failure modes people actually ship. It is a LINT — no build,
+# no network, no Cargo, deterministic, CI-safe. Read-only: never writes anything.
+#
+# Severity model (per the spec — heuristic + advisory):
+#   WARN  — likely-wrong, advisory. Does NOT fail the run.
+#   FAIL  — a hard structural break (v1 allowlist in a v2 config). Fails the run.
+#
+# Checks:
+#   1. FAIL  legacy v1 `"allowlist"` key in tauri.conf.json (v2 uses capabilities).
+#   2. WARN  src-tauri/ present but no capabilities/*.json — default-deny means zero IPC,
+#            usually a mistake unless the app makes no Rust calls.
+#   3. WARN  a capability lists no permissions (empty/absent "permissions").
+#   4. WARN  a command in generate_handler![...] has no matching #[tauri::command] fn.
+#   5. WARN  a fallible-looking command (read/write/fetch/load/save/delete/open) whose
+#            signature returns no `Result` — likely should return Result<T, E>.
+#   6. WARN  no CSP set anywhere in tauri.conf.json (app.security.csp).
+#
+# Exits 0 on a clean OR empty target, and on WARN-only. Exits 1 only on a FAIL.
+# Usage: verify.sh [TARGET_DIR]   (default ".")
+
+set -uo pipefail
+
+TARGET="${1:-.}"
+fail=0
+warned=0
+
+warn() { printf 'WARN [%s] %s — %s\n' "$1" "$2" "$3" >&2; warned=1; }
+hard() { printf 'FAIL [%s] %s — %s\n' "$1" "$2" "$3" >&2; fail=1; }
+note() { printf '%s\n' "$1"; }
+
+if [ ! -e "$TARGET" ]; then
+  note "verify: target does not exist: $TARGET — nothing to check."
+  exit 0
+fi
+
+# Locate the src-tauri dir (the target may be it, contain it, or be a single file).
+srctauri=""
+if [ -d "$TARGET/src-tauri" ]; then
+  srctauri="$TARGET/src-tauri"
+elif [ -d "$TARGET" ] && [ "$(basename "$TARGET")" = "src-tauri" ]; then
+  srctauri="$TARGET"
+else
+  found=$(find "$TARGET" -type d -name src-tauri -not -path '*/.git/*' 2>/dev/null | head -n1)
+  [ -n "$found" ] && srctauri="$found"
+fi
+
+# --- tauri.conf.json checks (run wherever a conf is found) ---------------------
+conf_files=()
+while IFS= read -r f; do conf_files+=("$f"); done < <(
+  find "$TARGET" -type f -name 'tauri.conf.json' -not -path '*/.git/*' 2>/dev/null
+)
+
+if [ "${#conf_files[@]}" -eq 0 ] && [ -z "$srctauri" ]; then
+  note "verify: no Tauri project found under $TARGET (no src-tauri/, no tauri.conf.json) — nothing to check."
+  exit 0
+fi
+
+for conf in "${conf_files[@]}"; do
+  content=$(tr -d '\r' < "$conf")
+
+  # Rule 1 (FAIL): v1 allowlist key.
+  if printf '%s' "$content" | grep -Eq '"allowlist"[[:space:]]*:'; then
+    ln=$(grep -nE '"allowlist"[[:space:]]*:' "$conf" | head -n1 | cut -d: -f1)
+    hard "v1-allowlist" "$conf:${ln:-?}" 'v1 "allowlist" key in a v2 config — replace with capabilities/*.json'
+  fi
+
+  # Rule 6 (WARN): no CSP.
+  if ! printf '%s' "$content" | grep -Eq '"csp"[[:space:]]*:'; then
+    warn "no-csp" "$conf" 'no app.security.csp set — the WebView runs any loaded script; set a CSP for prod'
+  fi
+done
+
+# --- capabilities checks -------------------------------------------------------
+if [ -n "$srctauri" ]; then
+  capdir="$srctauri/capabilities"
+  cap_files=()
+  if [ -d "$capdir" ]; then
+    while IFS= read -r f; do cap_files+=("$f"); done < <(
+      find "$capdir" -type f -name '*.json' 2>/dev/null
+    )
+  fi
+
+  # Rule 2 (WARN): src-tauri present but no capability files.
+  if [ "${#cap_files[@]}" -eq 0 ]; then
+    warn "no-capabilities" "$srctauri" 'no capabilities/*.json — default-deny means zero IPC access; add a scoped capability'
+  fi
+
+  # Rule 3 (WARN): a capability with no permissions.
+  for cap in ${cap_files[@]+"${cap_files[@]}"}; do
+    capc=$(tr -d '\r' < "$cap")
+    if ! printf '%s' "$capc" | grep -Eq '"permissions"[[:space:]]*:[[:space:]]*\['; then
+      warn "cap-no-perms" "$cap" 'capability has no "permissions" array — it grants nothing (or is malformed)'
+    elif printf '%s' "$capc" | grep -Eq '"permissions"[[:space:]]*:[[:space:]]*\[[[:space:]]*\]'; then
+      warn "cap-no-perms" "$cap" 'capability "permissions" is empty — grants nothing'
+    fi
+  done
+fi
+
+# --- command checks (Rust) -----------------------------------------------------
+if [ -n "$srctauri" ]; then
+  rs_files=()
+  while IFS= read -r f; do rs_files+=("$f"); done < <(
+    find "$srctauri" -type f -name '*.rs' -not -path '*/target/*' 2>/dev/null
+  )
+
+  # Gather the set of #[tauri::command] fn names and their (multi-line) signatures.
+  declared_names=""
+  for rs in ${rs_files[@]+"${rs_files[@]}"}; do
+    # Find lines with the command attribute, then the fn name on a following line.
+    # awk: when we see the attribute, capture the next fn <name>.
+    while IFS= read -r name; do
+      [ -n "$name" ] && declared_names="$declared_names $name"
+    done < <(awk '
+      /#\[tauri::command/ { armed=1; next }
+      armed && /fn[ \t]+[A-Za-z_][A-Za-z0-9_]*/ {
+        match($0, /fn[ \t]+[A-Za-z_][A-Za-z0-9_]*/)
+        s=substr($0, RSTART, RLENGTH); sub(/fn[ \t]+/, "", s); print s; armed=0
+      }
+      armed && NF==0 { next }
+    ' "$rs")
+  done
+
+  # Rule 4 (WARN): names inside generate_handler![...] with no declared command.
+  for rs in ${rs_files[@]+"${rs_files[@]}"}; do
+    # Extract the comma list between generate_handler![ and the closing ].
+    handler=$(tr -d '\r' < "$rs" | tr '\n' ' ' | grep -oE 'generate_handler!\[[^]]*\]' || true)
+    [ -z "$handler" ] && continue
+    inner=$(printf '%s' "$handler" | sed -E 's/.*generate_handler!\[//; s/\].*//')
+    # Split on commas, strip module paths (mod::cmd -> cmd) and whitespace.
+    IFS=',' read -ra regs <<< "$inner"
+    for r in "${regs[@]}"; do
+      r=$(printf '%s' "$r" | tr -d ' \t')
+      r="${r##*::}"
+      [ -z "$r" ] && continue
+      case " $declared_names " in
+        *" $r "*) : ;;
+        *) warn "unregistered-cmd" "$rs" "generate_handler! lists '$r' but no #[tauri::command] fn '$r' was found" ;;
+      esac
+    done
+  done
+
+  # Rule 5 (WARN): fallible-looking command without Result in its signature.
+  for rs in ${rs_files[@]+"${rs_files[@]}"}; do
+    while IFS= read -r nm; do
+      [ -n "$nm" ] && warn "no-result" "$rs" "command '$nm' looks fallible but returns no Result<T, E> — Err should become a rejected JS promise"
+    done < <(awk '
+      /#\[tauri::command/ { armed=1; sig=""; next }
+      armed {
+        sig = sig " " $0
+        if (sig ~ /\{/ || sig ~ /;/) {
+          # signature complete (body brace or decl end)
+          if (match(sig, /fn[ \t]+[A-Za-z_][A-Za-z0-9_]*/)) {
+            nm=substr(sig, RSTART, RLENGTH); sub(/fn[ \t]+/, "", nm)
+            if (nm ~ /^(read|write|fetch|load|save|delete|open|get|put|post)_/ && sig !~ /Result[ \t]*</) {
+              print nm
+            }
+          }
+          armed=0
+        }
+      }
+    ' "$rs")
+  done
+fi
+
+if [ "$fail" -ne 0 ]; then
+  note "verify: Tauri lint FAILED — fix the structural issue(s) above."
+  exit 1
+fi
+if [ "$warned" -ne 0 ]; then
+  note "verify: Tauri lint passed with advisory warnings (review above; not fatal)."
+  exit 0
+fi
+note "verify: Tauri project passes the static lint."
+exit 0

package/skills/teach/GLOSSARY-FORMAT.md

@@ -0,0 +1,35 @@
+# Formato de GLOSSARY.md
+
+`GLOSSARY.md` es el lenguaje canónico de este workspace de enseñanza. Todos los explicadores, ejercicios y registros de aprendizaje deben respetar su terminología. Construirlo es en sí mismo parte del aprendizaje: comprimir un concepto en una definición ajustada es evidencia de que el usuario lo entiende.
+
+## Estructura
+
+```md
+# Glosario de {Tema}
+
+{Una o dos frases que describan el tema que cubre este glosario.}
+
+## Términos
+
+**Hipertrofia**:
+Crecimiento muscular impulsado por tensión mecánica y estrés metabólico a lo largo de sesiones de entrenamiento repetidas.
+_Evitar_: Volumen, ponerse grande
+
+**Sobrecarga progresiva**:
+Aumentar sistemáticamente la demanda sobre un músculo con el tiempo, vía carga, volumen o intensidad.
+_Evitar_: Apretar más, subir de nivel
+
+**RPE (Rate of Perceived Exertion)**:
+Autovaloración de 1 a 10 de lo dura que se sintió una serie, donde 10 es el fallo y 8 significa que quedaban dos repeticiones en el tanque.
+_Evitar_: Puntuación de esfuerzo, valoración de intensidad
+```
+
+## Reglas
+
+- **Añade un término solo cuando el usuario lo entienda.** El glosario es un registro de conocimiento comprimido, no un diccionario que el usuario lee para aprender. Si al usuario se le acaba de presentar un concepto, espera a que pueda usarlo correctamente antes de promoverlo aquí.
+- **Sé opinante.** Cuando existan varias palabras para el mismo concepto, elige la mejor y lista las demás como alias a evitar. Así es como se comprime el lenguaje.
+- **Mantén las definiciones ajustadas.** Una o dos frases. Define qué ES el término, no qué hace ni cómo se hace.
+- **Usa los propios términos del glosario dentro de las definiciones.** Una vez que un término está en el glosario, prefiérelo en todas partes, incluso dentro de otras definiciones. Esto es lo que hace más fáciles de captar los términos complejos más adelante.
+- **Agrupa bajo subtítulos** cuando emerjan grupos naturales (p. ej. `## Anatomía`, `## Programación`). Una lista plana está bien cuando los términos cohesionan.
+- **Marca las ambigüedades explícitamente.** Si un término se usa de forma laxa en el campo más amplio, anota la resolución: "En este workspace, 'serie' siempre significa serie efectiva; los calentamientos se registran aparte".
+- **Revisa a medida que el entendimiento se profundiza.** Una definición que el usuario escribió en la semana uno puede estar mal en la semana seis. Actualiza en su sitio; no dejes entradas obsoletas.

package/skills/teach/LEARNING-RECORD-FORMAT.md

@@ -0,0 +1,46 @@
+# Formato de los registros de aprendizaje
+
+Los registros de aprendizaje viven en `./learning-records/` y usan numeración secuencial: `0001-slug.md`, `0002-slug.md`, etc. Crea el directorio de forma perezosa: solo cuando se escriba el primer registro.
+
+Son el equivalente docente de los ADR: capturan lecciones no obvias, aprendizajes clave y conocimiento previo declarado que orientarán futuras sesiones. Se usan para calcular la zona de desarrollo próximo.
+
+## Plantilla
+
+```md
+# {Título corto de lo aprendido o establecido}
+
+{1-3 frases: qué se aprendió (o qué conocimiento previo se estableció), y por qué importa para futuras sesiones.}
+```
+
+Ese es todo el formato. Un registro de aprendizaje puede ser un único párrafo. El valor está en registrar _que_ esto ya se sabe y _por qué_ cambia lo que conviene enseñar a continuación, no en rellenar secciones.
+
+## Secciones opcionales
+
+Inclúyelas solo cuando aporten valor real. La mayoría de los registros no las necesitarán.
+
+- **Status** en el frontmatter (`active | superseded by LR-NNNN`): útil cuando un entendimiento anterior resulta ser erróneo y se reemplaza.
+- **Evidencia**: cómo demostró el usuario el entendimiento (una pregunta respondida, un ejercicio completado, experiencia previa citada). Útil cuando la afirmación pueda revisarse.
+- **Implicaciones**: qué desbloquea o descarta para futuras sesiones. Vale la pena registrarlo cuando no es obvio.
+
+## Numeración
+
+Escanea `./learning-records/` en busca del número más alto existente e incrementa en uno.
+
+## Cuándo escribir un registro de aprendizaje
+
+Escribe uno cuando se cumpla alguna de estas condiciones:
+
+1. **El usuario demostró entendimiento genuino de algo no trivial**: no solo exposición, sino evidencia de que puede usar el concepto correctamente. Esto fija un nuevo suelo para lo que enseñar a continuación.
+2. **El usuario reveló conocimiento previo**: "ya sé X". Regístralo para que futuras sesiones no lo reenseñen. Registra también la _profundidad_ declarada.
+3. **Se corrigió una idea errónea**: el usuario creía algo equivocado y ahora ve por qué. Estos son muy valiosos: predicen futuros tropiezos en temas relacionados.
+4. **La misión cambió como respuesta al aprendizaje**: el usuario descubrió que le importaba algo distinto de lo que pensaba. Enlaza a [[MISSION.md]] y actualízala.
+
+### Qué _no_ califica
+
+- Material que simplemente se cubrió. Cobertura no es aprendizaje. Espera a la evidencia.
+- Cualquier cosa ya capturada de forma escueta en [[GLOSSARY.md]] como definición de término. No dupliques.
+- Registros de actividad sesión a sesión. Los registros de aprendizaje no son un diario: son aprendizajes con calidad de decisión.
+
+## Supersesión
+
+Cuando un registro posterior contradiga a uno anterior (el entendimiento del usuario se profundizó o se corrigió), marca el registro antiguo con `Status: superseded by LR-NNNN` en lugar de borrarlo. La historia de cómo evolucionó el entendimiento es en sí misma señal útil.

package/skills/teach/MISSION-FORMAT.md

@@ -0,0 +1,31 @@
+# Formato de MISSION.md
+
+`MISSION.md` vive en la raíz del workspace. Captura la _razón_ por la que el usuario está aprendiendo este tema. Toda decisión de enseñanza —qué enseñar a continuación, qué recursos sacar a la luz, qué ejercicios diseñar— debe poder rastrearse hasta este documento.
+
+## Plantilla
+
+```md
+# Misión: {Tema}
+
+## Por qué
+{1-3 frases. El objetivo concreto del mundo real que persigue el usuario. ¿Qué cambia en su vida o su trabajo cuando tenga esta habilidad? Evita formulaciones abstractas como "entender X": empuja hacia el resultado subyacente.}
+
+## El éxito se ve así
+- {Algo específico y observable que el usuario será capaz de hacer}
+- {Otra cosa específica}
+- {…}
+
+## Restricciones
+- {Tiempo, presupuesto, compromisos previos, preferencias de aprendizaje, cualquier cosa que acote el enfoque}
+
+## Fuera de alcance
+- {Temas adyacentes que el usuario explícitamente no quiere perseguir ahora; protege la zona de desarrollo próximo}
+```
+
+## Reglas
+
+- **Una misión por workspace.** Si el usuario quiere aprender dos cosas no relacionadas, son dos workspaces.
+- **Concreto antes que abstracto.** "Correr una media maratón en octubre" supera a "ponerme en forma". "Entregar una CLI en Rust a mi equipo" supera a "aprender Rust".
+- **Insiste ante la vaguedad.** Si el usuario no sabe articular el porqué, entrevístalo antes de escribir nada. Una mala misión es peor que ninguna misión.
+- **Revisa cuando la realidad cambie.** Las misiones cambian. Cuando el objetivo del usuario se mueva, actualiza este archivo; no dejes una misión obsoleta dirigiendo futuras sesiones.
+- **Hazlo corto.** Si `MISSION.md` se pasa de una pantalla, ha dejado de ser una brújula y ha empezado a ser un plan.

package/skills/teach/RESOURCES-FORMAT.md

@@ -0,0 +1,32 @@
+# Formato de RESOURCES.md
+
+`RESOURCES.md` es el conjunto curado de fuentes de confianza para este tema. El conocimiento de los explicadores debe extraerse de aquí, no de conjeturas paramétricas. La sabiduría proviene de las comunidades listadas aquí.
+
+## Estructura
+
+```md
+# Recursos de {Tema}
+
+## Conocimiento
+
+- [Libro: _The Science and Practice of Strength Training_ — Zatsiorsky & Kraemer](https://example.com)
+  Texto fundamental sobre programación y adaptación. Úsalo para: todo lo relacionado con periodización, recuperación, zonas de intensidad.
+- [Artículo: "How Much Should I Train?" — Greg Nuckols (Stronger By Science)](https://example.com)
+  Revisión basada en evidencia de los rangos de volumen. Úsalo para: objetivos semanales de series por grupo muscular.
+
+## Sabiduría (Comunidades)
+
+- [r/weightroom](https://reddit.com/r/weightroom)
+  Subreddit de alta señal, moderado contra la "bro-science". Úsalo para: crítica de programas, resolución de estancamientos.
+- Presencial: clase de fuerza de los martes en {nombre del gimnasio}
+  Úsala para: feedback de entrenamiento en tiempo real sobre los levantamientos.
+```
+
+## Reglas
+
+- **Solo alta confianza.** Prefiere fuentes primarias, expertos reconocidos, trabajo revisado por pares y comunidades con moderación fuerte. Si un recurso es marketing disfrazado de educación, déjalo fuera.
+- **Anota cada entrada.** Un enlace pelado es inútil dentro de tres meses. Añade una línea: qué cubre y cuándo recurrir a él.
+- **Agrupa por Conocimiento / Sabiduría.** Refleja la filosofía de [SKILL.md](./SKILL.md). Está bien que un recurso aparezca en un solo grupo.
+- **Saca a la luz los huecos explícitamente.** Si no existe un buen recurso para un área que la misión necesita, escribe una sección `## Huecos` listando lo que falta. Esto impulsa la búsqueda futura.
+- **Poda sin piedad.** Un recurso que resultó ser erróneo, superficial o desalineado con la misión debe eliminarse, no enterrarse. Mejor cinco fuentes afiladas que treinta mediocres.
+- **Registra las preferencias sobre comunidades.** Si el usuario ha decidido no unirse a comunidades, anótalo aquí para que futuras sesiones no sigan proponiéndolas.

package/skills/teach/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: teach
+description: "Teaches the user a new skill or concept within this workspace. Use when the user wants to learn a topic across multiple sessions."
+tags: ["teaching", "learning", "mentoring"]
+disable-model-invocation: true
+profiles: [minimal, core, ui, full]
+---
+
+El usuario te ha pedido que le enseñes algo. Es una petición con estado: pretende aprender el tema a lo largo de varias sesiones.
+
+## Workspace de enseñanza
+
+Trata el directorio actual como un workspace de enseñanza. El estado de su aprendizaje vive en este directorio repartido en varios archivos:
+
+- `MISSION.md`: documento que captura la _razón_ por la que el usuario quiere aprender el tema. Debe servir de base para toda la enseñanza. Usa el formato de [MISSION-FORMAT.md](./MISSION-FORMAT.md).
+- `./reference/*.html`: directorio de materiales de referencia. Son el aprendizaje comprimido de las lecciones: chuletas, algoritmos de referencia, sintaxis, posturas de yoga, glosarios. Son las unidades crudas de conocimiento. Deben ser documentos bonitos, que impriman bien y estén pensados para consulta rápida.
+- `RESOURCES.md`: lista de recursos que se pueden explorar para fundamentar la enseñanza en conocimiento contextual, o para adquirir conocimiento y sabiduría. Usa el formato de [RESOURCES-FORMAT.md](./RESOURCES-FORMAT.md).
+- `./learning-records/*.md`: directorio de registros de aprendizaje, que capturan lo que el usuario ha aprendido. Son aproximadamente equivalentes a los architectural decision records del desarrollo de software: capturan lecciones no obvias y aprendizajes clave que quizá haya que revisar más adelante, o que impulsan futuras sesiones. Se usan para calcular la zona de desarrollo próximo. Se titulan `0001-<nombre-en-guiones>.md`, donde el número se incrementa cada vez. Usa el formato de [LEARNING-RECORD-FORMAT.md](./LEARNING-RECORD-FORMAT.md).
+- `./lessons/*.html`: directorio de lecciones. Una **lección** es un único archivo HTML autocontenido que enseña una cosa muy acotada y ligada a la misión. Es la unidad principal de enseñanza en este workspace.
+- `NOTES.md`: un cuaderno de notas para que apuntes las preferencias del usuario o tus notas de trabajo.
+
+## Filosofía
+
+Para aprender a un nivel profundo, el usuario necesita tres cosas:
+
+- **Conocimiento**, capturado de recursos de alta calidad y alta confianza.
+- **Habilidades**, adquiridas mediante lecciones interactivas muy relevantes que diseñas tú a partir del conocimiento.
+- **Sabiduría**, que surge de interactuar con otros aprendices y practicantes.
+
+Antes de que `RESOURCES.md` esté bien poblado, tu prioridad debe ser encontrar recursos de alta calidad que ayuden al usuario a adquirir conocimiento. Nunca confíes en tu conocimiento paramétrico.
+
+Algunos temas requieren más habilidades que conocimiento. Aprender física teórica puede ser más basado en conocimiento; el yoga, más basado en habilidades.
+
+### Fuerza de fluidez vs. fuerza de almacenamiento
+
+Distingue con cuidado entre dos tipos de aprendizaje:
+
+- **Fuerza de fluidez**: recuperación del conocimiento en el momento.
+- **Fuerza de almacenamiento**: retención del conocimiento a largo plazo.
+
+La fluidez puede dar una sensación ilusoria de dominio, pero el objetivo real es la fuerza de almacenamiento. Diseña lecciones que construyan retención a largo plazo mediante dificultad deseable:
+
+- Usando práctica de recuperación (recordar de memoria).
+- Espaciado (distribuir la práctica en el tiempo).
+- Intercalado (mezclar temas distintos pero relacionados en la práctica; solo para práctica de habilidades).
+
+## Lecciones
+
+Una lección es lo principal que produces: la unidad en la que el conocimiento y las habilidades llegan al usuario. Cada lección es un único archivo HTML autocontenido, guardado en `./lessons/` y titulado `0001-<nombre-en-guiones>.html`, donde el número se incrementa cada vez.
+
+Una lección debe ser **bonita** —tipografía y maquetación limpias y legibles— porque el usuario volverá a ellas más adelante para repasar. Piensa en Tufte.
+
+La lección debe ser corta y completable muy rápido. La memoria de trabajo del aprendiz es muy pequeña y hay que mantenerse dentro de ella. Pero cada lección debe dar al usuario una única victoria tangible sobre la que construir. Debe estar directamente ligada a la misión y situarse en la zona de desarrollo próximo del usuario.
+
+Si es posible, abre el archivo de la lección para el usuario ejecutando un comando de CLI.
+
+Cada lección debe enlazar, mediante anclas HTML, a otras lecciones y documentos de referencia.
+
+Cada lección debe recomendar una fuente primaria para que el usuario lea o vea. Debe ser el recurso de mayor calidad y confianza que hayas encontrado sobre el tema.
+
+Cada lección debe contener un recordatorio para que el usuario haga preguntas de seguimiento al agente. El agente es su profesor y puede ayudar con cualquier cosa que no quede clara.
+
+## La misión
+
+Toda lección debe estar ligada a la misión: la razón por la que el usuario quiere aprender el tema.
+
+Si el usuario no tiene clara la misión, o `MISSION.md` no está poblado, tu primera tarea es preguntarle por qué quiere aprender esto.
+
+No entender la misión hará que la adquisición de conocimiento no esté anclada en objetivos del mundo real. Las lecciones se sentirán demasiado abstractas. No tendrás forma de juzgar qué debería hacer el usuario a continuación.
+
+Las misiones pueden cambiar a medida que el usuario desarrolla más habilidades y conocimiento. Es normal: actualiza `MISSION.md` y añade un registro de aprendizaje que capture el cambio. Confirma con el usuario antes de cambiar la misión.
+
+## Zona de desarrollo próximo
+
+En cada lección, el usuario debe sentir siempre que se le reta "lo justo".
+
+El usuario puede indicar exactamente qué quiere aprender. Si no lo hace, calcula su zona de desarrollo próximo:
+
+- Leyendo sus `learning-records`.
+- Decidiendo qué conviene enseñarle según su misión.
+- Enseñando lo más relevante que encaje en su zona de desarrollo próximo.
+
+## Conocimiento
+
+Las lecciones deben diseñarse en torno a una habilidad que el usuario va a aprender. El conocimiento de la lección debe ser solo el necesario para adquirir esa habilidad. Enseña primero el conocimiento y luego haz que el usuario practique las habilidades mediante un bucle de retroalimentación interactivo.
+
+El conocimiento debe obtenerse primero de recursos de confianza. Usa `RESOURCES.md` para llevar el control. Las lecciones deben estar plagadas de citas —enlaces a recursos externos que respalden cualquier afirmación—. Esto aumenta la fiabilidad de la lección.
+
+Para adquirir conocimiento, la dificultad es el enemigo. Se come la memoria de trabajo que necesitas para comprender.
+
+## Habilidades
+
+Si el conocimiento va de adquisición, las habilidades van de durabilidad y flexibilidad. Haz que el conocimiento se fije.
+
+Para adquirir habilidades, la dificultad es la herramienta. La recuperación esforzada es lo que construye fuerza de almacenamiento. Las habilidades se enseñan mediante lecciones interactivas. Tienes varias herramientas a tu disposición:
+
+- Lecciones interactivas, con cuestionarios y tareas ligeras en el navegador.
+- Lecciones que guían al usuario por una lista de pasos reales que dar (por ejemplo, posturas de yoga).
+
+Cada una debe basarse en un **bucle de retroalimentación** donde el usuario reciba feedback sobre su rendimiento. Ese bucle debe ser lo más estrecho posible, dando feedback inmediato e, idealmente, automático.
+
+En los cuestionarios, cada respuesta debe tener exactamente el mismo número de palabras (y de caracteres, si es posible). No des al usuario pistas sobre la respuesta a través del formato.
+
+## Adquirir sabiduría
+
+La sabiduría surge de la interacción real con el mundo: poner a prueba tus habilidades fuera del entorno de aprendizaje.
+
+Cuando el usuario haga una pregunta que parezca requerir sabiduría, tu postura por defecto debe ser intentar responder, pero en última instancia delegar en una **comunidad**.
+
+Una comunidad es un lugar (online u offline) donde el usuario puede poner a prueba sus habilidades en el mundo real. Puede ser un foro, un subreddit, una clase presencial (si el presupuesto lo permite) o un grupo de interés local.
+
+Debes intentar encontrar comunidades de alta reputación a las que el usuario pueda unirse. Si el usuario expresa que no quiere unirse a una comunidad, respétalo.
+
+## Documentos de referencia
+
+Al crear lecciones, debes crear también documentos de referencia. Las lecciones pueden remitir a estos documentos: son útiles para registrar unidades crudas de conocimiento que sirven en varias lecciones.
+
+Las lecciones rara vez se revisitan; los documentos de referencia sí. Deben ser la esencia comprimida de la lección, en un formato pensado para consulta rápida.
+
+Algunos temas se prestan especialmente a la referencia:
+
+- Sintaxis y snippets de código para programación.
+- Algoritmos y diagramas de flujo para procesos.
+- Posturas y secuencias para yoga.
+- Ejercicios y rutinas para fitness.
+- Glosarios para cualquier tema con nomenclatura propia.
+
+El glosario, en particular, es una referencia esencial. Una vez creado, debe respetarse en todas las lecciones. Usa el formato de [GLOSSARY-FORMAT.md](./GLOSSARY-FORMAT.md).
+
+## `NOTES.md`
+
+A veces el usuario expresará preferencias sobre cómo quiere que se le enseñe, o cosas que debes tener en cuenta. Este es el sitio para registrar esas preferencias, de modo que puedas consultarlas al diseñar lecciones o trabajar con el usuario.

package/skills/teach/evals/cases.yaml

@@ -0,0 +1,32 @@
+skill: teach
+
+should_trigger:
+  - prompt: "Ensename como funciona este concepto a lo largo de varias sesiones."
+    why: "Disparador directo de teach."
+  - prompt: "Quiero aprender esta habilidad dentro de este workspace."
+    why: "Disparador directo de teach."
+  - prompt: "Explicame este tema poco a poco en sesiones sucesivas."
+    why: "Disparador directo de teach."
+  - prompt: "Teach me this concept over several sessions in this workspace."
+    why: "Disparador directo de teach."
+  - prompt: "Ayudame a entender este area del proyecto como quien aprende."
+    why: "Disparador directo de teach."
+
+should_not_trigger:
+  - prompt: "Ponme ejercicios de practica de Python."
+    route_to: "muscle-memory"
+    why: "Generar katas de practica es el trabajo de muscle-memory, no de teach."
+  - prompt: "Implementa esta funcionalidad directamente."
+    route_to: "implement"
+    why: "Implementar la funcionalidad es el trabajo de implement, no de teach."
+  - prompt: "Revisa mi solucion a este kata."
+    route_to: "muscle-memory"
+    why: "Revisar la solucion a un kata es el trabajo de muscle-memory, no de teach."
+  - prompt: "Documenta la decision de arquitectura."
+    route_to: "write-adr"
+    why: "Documentar una decision de arquitectura es el trabajo de write-adr, no de teach."
+
+capability:
+  - scenario: "El usuario quiere aprender un tema a lo largo de varias sesiones."
+    must_include:
+      - "aprender"