ac10f5fe1e
Skill: NONE | Type: design Summary: EPISODIO 21 — BLINDADAS: La distinción clave: **UN skill, DOS documentos**
3.3 KiB
| episode_id | puente_flat | session_code | acto_dialogico | actor_flujo | criticidad_aegis | skill_dominante | fase_proyecto | tipo_semantico | summary_one_line | source_type | trust_boundary | created_at | relectura_tagged | forgejo_commit_sha |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 712d50f1-58b4-4017-a027-313a569372a6 | EXPLORA_la-distincin-clave-un-skill-dos-document_S20260705.R21_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD | S20260705.EVAL_INSTRUMENT_FORGE_SKILL | informar | multi_actor | low | NONE | operations | design | EPISODIO 21 — BLINDADAS: La distinción clave: **UN skill, DOS documentos** | claude_code | internal | 2026-07-07T03:51:27.102674+00:00 | false | pending |
Buena pregunta, John — déjame aclararlo con precisión, porque no es del todo así y quiero que tengas el mapa exacto (BLINDADA-9, cero humo).
La distinción clave: UN skill, DOS documentos
Lo que la otra instancia fabricó no es un skill diferente — es el mismo skill que yo estaba diseñando, ya implementado. Mira:
| Artefacto | Quién lo hizo | Qué es | ¿Mismo o diferente? |
|---|---|---|---|
Skill eval-instrument-forge — el diseño (SPEC + CONCILIO) |
Yo | El contrato/plano del skill | 🟰 MISMO skill |
Skill eval-instrument-forge — el código (lib + tests) |
La hermana | La implementación de mi diseño | 🟰 MISMO skill |
Doc SOTA ..._EVALUACION_LLM |
Yo | Estado del arte de cómo evaluar LLMs (25 lentes: benchmarks, juez, RAG, agéntico…) | ↔️ DOCS diferentes |
Doc SOTA ..._EVALUACION_ESTADISTICA |
La hermana | Estado del arte del rigor estadístico (anytime-valid/e-values, conformal, "compute-don't-guess") | ↔️ DOCS diferentes |
En una frase: el skill es uno solo (yo lo diseñé, ella lo codeó — su SKILL.md literalmente cita mi SPEC como origen, mismo id, mismas 9 familias). No hay dos skills, no hay duplicación. Lo que sí es diferente y complementario son los dos documentos de investigación.
Dónde sí hay complementariedad real (y es valiosa)
Su doc de evaluación estadística encaja como enriquecimiento del propio skill, no como skill aparte:
- Mi doc dice QUÉ instrumentos fabricar (las 9 familias: MCQ, pass@k, juez, RAG, calibración, ablation…).
- Su doc dice CÓMO medir con más rigor (e-values / anytime-valid, conformal prediction) — que es exactamente la familia I (arnés estadístico) y los gates SCIENTIA del skill.
Así que su investigación estadística es material para una v1.1 del arnés (añadir e-values/conformal a scorers.py + stat_harness.py). Complementa el skill por dentro, no lo duplica por fuera.
¿Querías dos skills separados?
Si tu intención era tener dos skills distintos — p.ej. uno para "forjar tests de calidad de respuestas LLM" y otro para "evaluar estadísticamente cualquier fenómeno medible" — eso sí sería una decisión de diseño nueva que podemos tomar. Pero hoy el estado es: 1 skill + 2 docs que lo alimentan. Dime cuál de los dos cuadros querías:
- 🟢 Un skill (
eval-instrument-forge) alimentado por ambos docs — lo que hay hoy. (Mi recomendación: es coherente y ya está construido/certificado.) - 🟡 Dos skills — separar el motor estadístico general en su propio skill. (Más superficie; solo si vas a evaluar fenómenos NO-LLM con frecuencia.)