Módulo 3.1 · Escribiendo el playbook

📜 Qué es un playbook

Un playbook es un único archivo .md procesable. Captura el delta que mediste no como una narrativa ("Fable parecía más cuidadoso") ni como una impresión del video, sino como REGLAS: instrucciones imperativas que el modelo de destino puede seguir — "piensa antes de actuar", "lee antes de editar". Una regla se puede inyectar; una impresión, no.

🎯 Qué hace un playbook honesto

•1 archivo: cabe en el contexto sin inflar la sesión.
•Imperativo: cada línea es una orden, no una descripción.
•Números reales incorporados: los +45 pts vienen de TU corpus.
•Honesto: dice qué NO se transfiere y qué NO copiar.

✓ Es un playbook

✓"En una tarea no trivial, planifica en 2–5 líneas antes de la 1.ª herramienta."
✓"Nunca edites un archivo que no hayas leído en este contexto."
✓Cada regla debe poder comprobarse y seguirse.

✗ NO es un playbook

✗"Fable es un modelo muy reflexivo." (impresión)
✗Un ensayo sobre cómo el modelo "piensa".
✗Copiar Fable a ciegas, incluidos sus defectos.

⚙️ make_playbook.py — genera a partir de compare.json

El generador es el make_playbook.py. Tiene dos modos: o pasas el compare.json ya medido en la Trilha 2 (vía --from-json, más rápido), o mide el historial en el momento. En ambos casos, el punto clave es el mismo: los NÚMEROS reales se incluyen en el texto de las reglas — no impresiones genéricas.

# reusa o compare já medido (rápido):
python make_playbook.py --from-json compare.json \
    --out ../playbook/fable-mindset-playbook.md

# ou mede o histórico na hora:
python make_playbook.py --target claude-opus-4-8 \
    --model-fable claude-fable-5

›

`--from-json compare.json`

Reutiliza la medición ya hecha por el compare_models.py. El mismo número, sin volver a recorrer miles de sesiones.

›

Números inyectados en el texto

O build_playbook() escribe "99% contra 54% (+45 puntos)" leyendo los valores del dict de métricas — no constantes codificadas en el código.

💡 Consejo práctico

Genera el compare.json una vez (Ruta 2) y versiona junto con el playbook. Así cualquiera puede regenerar el .md con --from-json en segundos, sin acceso a tu historial sin procesar.

📶 Ordenar por FUERZA de la señal

El orden de las reglas no sigue el orden del video ni el del código: sigue la fuerza de la señal medida. El delta robusto es el pensar-antes-de-agir (+45 pts): va primero. Leer antes de editar y probar después se incorporan luego, como buenas prácticas que conviene adoptar, con la salvedad honesta de que la muestra es pequeña; no como un delta estadísticamente sólido.

Piensa antes de actuar delta firme · +45 pts

Fable razonó en el 99% de los turnos vs. el 54% de Opus. La mayor palanca, la que más se transfiere — en lo más alto de la lista.

⚠ Actualización: medido después con una muestra grande (4.892 pasos), el número honesto es ~85% (no 99%) y la brecha baja a +31 pts — y aparece una brecha oculta en prueba-después-de-editar (41% frente a 2%). Consulta la Ruta 4 · La prueba real.

Herramienta con propósito densidad

6,57 vs 7,86 herr./turno: Fable fue más económico. Densidad, no thrashing.

Leer antes de editar buena práctica

~34% / ~38% en ambos: modesto en los dos. Disciplina para SUBIR al 100%, no para copiar.

Cerrar el ciclo: prueba/build buena práctica

Muestra ruidosa (0% / 3%). Se incluye como hábito que conviene adoptar, con la salvedad.

⚠️ Muestra pequeña de Fable (7 sesiones)

Trata leer antes de editar y probar después de editar como BUENAS PRÁCTICAS que debes incorporar, no como un delta firme. El make_playbook.py incluso avisa cuando hay menos de 30 sesiones. La única señal robusta aquí es el razonamiento antes de actuar.

🔄 Corregir, no copiar

Aquí está la parte que distingue un playbook honesto de una copia ingenua: invierte los hábitos débiles de Fable en lugar de replicarlos. Razonar en el 99% de los turnos es ideal para lo difícil, y un desperdicio para renombrar una línea. Un playbook que copia todo también importaría los defectos.

✗ Hábito débil de Fable

✗Pensar demasiado en tareas simples — razonamiento incluso al cambiar el nombre.
✗Verbosidad — narra demasiado lo que va a hacer.
✗Plan que se convierte en ensayo — planificar durante demasiado tiempo.

✓ Corrección en el playbook

✓Razonamiento proporcional a la dificultad — lo mecánico va directo al grano.
✓Actúa; el resumen viene después y es breve, con las rutas y lo que se verificó.
✓El plan cabe en pocas líneas; la profundidad se reserva para la ejecución.

🔎 Por qué esto importa

El objetivo no es convertirse en Fable, sino mejorar la ejecución del modelo objetivo. Importar un defecto junto con la virtud anula la ganancia. Corregir conserva solo lo que ayuda: el buen ritmo, sin el roce.

🧭 Las reglas transferibles

Estas son las reglas que el modelo objetivo realmente adopta: el corazón del playbook. Todas convergen en una secuencia canónica de trabajo.

🧩 Las seis reglas que se transfieren

1.Piensa antes en lo no trivial (2–5 líneas de plan antes de la primera herramienta).
2.Herramienta con propósito: densidad, no agitación; llamadas independientes en el mismo turno.
3.Leer antes de editar → 100%: nunca editar un archivo que no se haya leído en este contexto.
4.Cerrar el ciclo con prueba/build e informar el resultado REAL.
5.Secuencia canónica: entender → planificar → leer → editar → probar → informar.
6.Detente cuando tengas suficiente para actuar — no vuelvas a derivar hechos ya establecidos.

✅ La lista de verificación de una línea

Todo el playbook se destila en una sola línea que pegas al inicio de las tareas de código. Es el recordatorio mínimo, de costo de contexto insignificante, que incluye la secuencia canónica y las correcciones. Esta es la lista final, exactamente como sale del generador:

entender → plano curto → ler → editar → testar → relatar (com output)  ·
pense-antes-no-não-trivial · ferramenta-com-propósito · read-before-edit→100% ·
teste-depois-de-edit · sem-verbosidade · sem-over-think-no-trivial

Dónde pegar

parte superior de la tarea de código

Costo

despreciable (1 línea)

Carga

secuencia + correcciones

inyectar automáticamente (3.2)

💡 Consejo práctico

Esta lista de verificación es el resumen; el playbook completo (con la tabla del delta y la sección «NO copies esto») es lo que inyectas. En el Módulo 3.2 veremos cómo hacer que ese archivo se incorpore al contexto automáticamente en cada sesión.

📜 Resumen del módulo

✓

Playbook = 1 .md de reglas — accionable, imperativo, no narrativo.

✓

make_playbook.py inyecta los números reales — del compare.json o midiéndolo en el momento.

✓

Orden según la FUERZA de la señal — pensar antes (+45 pts) primero; el resto, como buena práctica.

✓

Corregir, no copiar — revierte el over-thinking, la verbosidad y el plan-ensayo.

✓

Secuencia canónica — entender → planificar → leer → editar → probar → informar.

✓

Lista de verificación de una línea — pégalo al principio de las tareas de código.

Próximo módulo:

3.2 — Inyectando en el modelo (y sin datos propios)

← Volver a la ruta Próximo módulo →