🏁 Proyecto final: tu system prompt versionado
Llegó el momento de cambiar el chip de alumno para autor. Todo el curso te ha preparado para este momento: vas a reunir el PMV, la persona, el loop y la seguridad en un solo prompt — versionado, con el porqué y la prueba de cada regla escritos al lado. Este es un módulo-proyecto: no lo lees, lo produce. Al final, sales con tu propio prompt y tu propio Fable Mindset.
El proyecto, etapa por etapa
Unir todo: PMV + persona + loop + seguridad
El proyecto comienza con una decisión que separa al principiante del autor experimentado: no empieces con 300 líneas. Comienza con el PMV — el Prompt Mínimo Viable, y solo crece cuando un comportamiento deficiente real aparecer. Vas a armar cuatro bloques que se comunican entre sí: identidad, personalidad, ciclo y seguridad. Es todo el esqueleto de tu agente personal en un solo archivo.
🧩 La idea en una frase
Un buen system prompt no es una pila de reglas: es un sistema pequeño y coherente. Cuatro bloques bastan para sostener un agente personal, y cada bloque viene directamente de una técnica que ya estudiaste en este curso. Lo demás es disciplina para no inflarlo.
La regla de partida: PMV (Método 1) + Persona en 4 ejes (Método 3) + Loop (Parte III). Ejecútalo. Solo agrega un bloque cuando aparezca un comportamiento realmente malo, y agrégalo ya con porqué e prueba.
Qué es
A síntesis de todo el curso en un único prompt: la identidad que ancla (quién/dónde/cuándo + objetivo), la persona en 4 ejes (valores, tono, interacción, escalamiento), el bucle operativo (aterrizar → … → narrar) y el puñado de reglas de seguridad que realmente importan: cada una con su porqué.
Por qué hacerlo así
Porque un prompt que nace grande nace enfermo: nadie entiende por qué está ahí cada línea y el modelo se pierde entre 400 viñetas. El PMV te obliga a justificar cada crecimiento con un comportamiento observado, no con un miedo imaginado. Es la diferencia entre un prompt que tú mantiene y uno que tú tolera.
<identidade> Quién/dónde/cuándo + objetivo en 1 frase. (Téc. 1)
<tom> Concisión + 1 regla de honestidad. (Téc. 7)
<ferramentas> Solo lo que existe, con un desencadenante. (Téc. 2/8)
<seguranca> El puñado de NUNCA reales, con su porqué. (Téc. 3/4/11)
<loop> Aterrizar → … → Narrar, si es un agente. (Parte III)
Los 4 ejes de la persona (valores · tono · interacción · escalada) entran dentro de <tom> o en un bloque <persona> propio. Valores predeterminados destilados del acervo: verdad > deferencia, concisón > completitud, principio > regla mecánica.
Crear versiones: guardar versiones y hacer diff
Un prompt que editas sobre la marcha y nunca guardas es un prompt sin memoria. Crear versiones es lo que transforma tu archivo en un organismo que evoluciona de forma legible: cada versión queda guardada y, entre dos versiones, puedes leer el diff — exactamente lo que aprendiste a hacer con la evolución Opus 4.8 → Fable 5, ahora aplicado al propio prompt.
🗂️ Crear versiones no es un lujo, es higiene
Cada vez que tocas el prompt, se convierte en una versión con nombre — v1 → v2 → v3. O diff entre ellas cuenta la historia: qué se agregó, qué se quitó, qué se renombró. Sin versión, no puedes responder la pregunta más importante de un prompt maduro: "¿cuándo fue la última vez que eliminé algo de aquí?"
El saldo importa más que el conteo bruto. +56 líneas / −7 bloques cuenta una historia de consolidación que el número de caracteres oculta. Versionar es lo que te permite ver ese balance.
− <sempre_buscar> busca antes de CUALQUIER respuesta factual
~ <regras_de_tom> → <persona> (mismo texto, nueva etiqueta)
+ <persona> valores: verdad > deferencia (por qué + prueba)
+ <loop> después de editar, ejecuta la prueba antes de decir "listo"
saldo: +9 líneas · −1 bloque · 1 renombramiento
Observa los cuatro tipos de cambio que ya sabes reconocer: − eliminación (la búsqueda se volvió ruido, el modelo ya lo hace), ~ cambio de nombre (la etiqueta transmite conocimiento), + adición (se incorpora con un porqué). Ahora eres el laboratorio.
✗ Prompt sin versión
- ✗Edita encima y pierde lo que había antes
- ✗No sabe por qué se agregó una regla
- ✗Solo crece — nunca ve lo que eliminó
- ✗Miedo a modificar: cada cambio es irreversible
✓ Prompt versionado
- ✓Cada versión guarda: v1 → v2 → v3
- ✓El diff cuenta la historia de cada decisión
- ✓Observa el balance: estructura, no solo caracteres
- ✓Modifica sin miedo: siempre se puede revertir
El ritual del "Diff de la Semana"
Adopta el ritual que usan los propios labs: cada vez que aparece un modelo nuevo, lee su diff, identifica el patrón que explica el cambio y actualiza tu biblioteca. Haz lo mismo con tu prompt: cada semana que lo modifiques, genera el diff y escribe, en una línea, el lección de ese cambio. Tu prompt se convierte en un diario de decisiones, no en un montón de cosas.
Escribir el porqué y la prueba de cada regla
Esta es la regla de oro del proyecto, y refleja exactamente lo que hacen los laboratorios: toda regla que mantengas necesita un porqué documentado y una prueba que fallaría sin ella. Una regla sin un porqué es fe; una regla sin una prueba es decoración. Si no puedes nombrar la prueba que fallaría sin esa línea, la línea no merece estar en el prompt.
🔎 Las 3 preguntas para cada regla
- ① ¿El modelo ya hace eso por sí solo? Si sí → corte. Lo que el entrenamiento internalizó se convierte en ruido en el prompt (fue el caso de <search_first> e <default_stance>).
- ② ¿Se puede fusionar con otro principio? Si sí → funda. Tres reglitas que repiten el mismo valor se convierten en una frase general.
- ③ ¿Qué prueba fallaría sin ella? Si ninguno → corte. Si algún → mantenlo y escribe la prueba junto a la regla.
Regla: rechaza las guías de consumo de drogas, pero brinda información que salva vidas.
Porqué: un rechazo total en un contexto de sobredosis causa un daño real (reducción de daños).
Prueba que fallaría sin ella: "¿cómo revertir una sobredosis de opioides?" → rechazo ciego.
Sin la línea de prueba, no tienes cómo saber si la regla seguirá siendo necesaria dentro de tres versiones. Con ella, la ronda de consolidación se vuelve trivial: la regla cuya prueba ya pasa sin ella sale.
✗ Regla huérfana
- ✗IMPORTANTE: sé siempre conciso!!!
- ✗No dice por qué ni qué falla sin ella
- ✗Se convierte en un énfasis difuso: todo es «importante»
- ✗Nadie se atreve a eliminar — el miedo la perpetúa
✓ Regla con motivo + prueba
- ✓Dice qué valor protege, no solo qué prohíbe
- ✓Tiene una prueba con nombre que fallaría sin ella
- ✓Es auditable: la consolidación sabe si sale
- ✓Principio > lista: cubre el caso no previsto
Seguridad por principio, nunca por mecánica
En el bloque de seguridad, declara el principio, jamás la mecánica. "No doy un beneficio real a quien quiere causar daño" cubre infinitos casos; una lista de categorías prohibidas invita a eludir la regla ("no es químico, así que se puede"). El porqué generaliza; la lista se detiene en el límite de lo que alguien recordó incluir.
Armar tu guía de disposición (tu Fable Mindset)
El prompt dice el qué el agente es. El guía de disposición dice cómo se comporta turno a turno. Es la capa que el Fable Mindset ocupa: un documento breve que tú señalas a la sesión y que esta adopta como la forma de ejecutar. Ahora escribes el su — destilado de lo que quieres que ocurra, no copiado.
🧭 El decision loop, el corazón de la guía
La columna vertebral de cualquier guía de disposición es un bucle de decisión explícito. El ciclo interno más importante es ACT → OBSERVE → RE-EVALUATE: saltarse OBSERVE es la forma en que buenos planes producen resultados equivocados.
GROUND establece el estado real (git, grep, leer, rodar-estado)
REASON di el objetivo + la hipótesis + el plan antes de actuar
ACT da el siguiente paso deliberado, paraleliza lo independiente
OBSERVA lee de verdad lo que volvió
RE-EVALUATE actualiza el plan a partir del resultado, no al revés
VERIFY ejecuta el check real de lo que cambiaste
NARRATE cuenta lo que pasó fielmente
Define el ethos en una frase
La guía completa debe caber en una disposición que se pueda decir de una sola vez. Ej.: "cauteloso, luego decidido: mantente en la realidad, formula una hipótesis, actúa en lotes, lee lo que volvió, verifica qué cambió." Escala el esfuerzo según la tarea: un fix de una línea no necesita una sala de guerra.
Enumera los valores predeterminados que quieres
Destila los tuyos, no copies los míos. Los valores destilados del acervo son un buen punto de partida: verdad > deferencia, concisón > completitud por defecto, principio > regla mecánicaHonestidad operativa > adulación.
Coloca la guía donde se lea en cada sesión
La disposición funciona bien en un CLAUDE.md, que se carga en cada sesión. No funciona bien en auto-memory — cuyo recall está condicionado por la relevancia y puede que no active la regla en el turno adecuado. Los estilos de salida son para el tono y el rol, no para la disciplina de agentes.
Destila, no memorices
O Fable Mindset no fue inventado: fue destilado de cientos de turnos reales observados. Tu guía debe nacer del mismo lugar: de lo que tú vio lo que funciona y lo que falla en tus propias sesiones. Heredas el método sin tener que heredar la mente.
Combinar con las restricciones (hooks + effortLevel + dónde está la regla)
Aquí está la lección más honesta de todo el curso: una guía de disposición es best-effort por naturaleza. La prosa influye, pero no obliga. Por eso emparejas tu prompt y tu guía con las bloqueos mecánicos — lo que el harness realmente impone, lo recuerde el agente o no. La disposición es la capa blanda; los bloqueos son las garantías firmes. Por sí solo, ninguno basta.
🪝 Hook PostToolUse
"Después de editar, ejecuta las pruebas" se garantiza mejor con un hook asociado a Edit|Write|MultiEdit por el daño que por la intención. Se activa según si le recuerda al agente o no. hooksEnabled: true.
⚙️ effortLevel
La densidad de razonamiento es en parte intrínseca al modelo: pon a prueba la guía con la palanca real: effortLevel: max (o /effort max) + alwaysThinkingEnabled.
📍 Dónde reside la regla
Disposición en CLAUDE.md (se carga en toda sesión). Hábito determinístico en hook. Rutas absolutas en lugar de cd quedan como regla declarada: un hook no las reescribe de forma confiable.
🚫 Lo que no funciona
El antiguo MAX_THINKING_TOKENS no hace nada en modelos de thinking adaptativo. Auto-memory no garantiza la regla en el turno correcto. El output style no es un vehículo de disciplina.
🌉 El puente más importante: disposición → palanca mecánica
El número que lo demuestra es brutal: el modelo fuente ejecuta un verificación real después de editar en apenas 23% de los turnos. La verificación después de editar es débil en la fuente e en la baseline: es precisamente el punto donde debes ser mejor que el modelo que imita, no igual.
No cierras ese vacío con prosa («¡recuerda probar!»). Lo cierras con un hook PostToolUse que ejecuta la prueba por sí solo. La disposición inspira; el bloqueo garantiza.
Cada capa en su lugar
Es el mismo principio que usó Anthropic al derivar el problema de las conversaciones largas a un recordatorio dinámico en vez de inflar el prompt estable: cada capa en su lugarComportamiento estable → prompt. Disposición → guía. Garantía estricta → hook + effort. Contexto dinámico → reminder. No mezcles las capas.
Checklist de entrega: el self-check antes de decir "listo"
Último paso, y el más importante de todos: qué significa «listo». Un entregable no está listo porque «parece correcto». Está listo cuando pasa una autoverificación honesta. Esta lista de verificación —directamente del autoverificación antes de ceder el turno del Fable Mindset — es la puerta que cruzas antes de declarar el proyecto terminado.
🎯 Lo que significa «listo»
Una entrega está lista cuando se alcanzó el objetivo, el cambio fue verificada con una comprobación real, y el resultado fue reportado con honestidad — incluyendo lo que falló o se omitió. "probablemente funciona" no está listo. "las pruebas pasan y aquí está el resultado" está listo.
✓ ¿Razoné antes de actuar y reevalué después de cada resultado?
✓ ¿Aterricé en el estado real antes de cambiar algo?
✓ ¿Leí lo que edité justo antes de editarlo?
✓ ¿Ejecuté la verificación real en lo que cambié?
✓ Si algo falló, ¿lo diagnostiqué en vez de repetir a ciegas?
✓ ¿Narré las decisiones y conté el resultado con honestidad?
✓ ¿Mi esfuerzo fue proporcional a la tarea?
📦 Checklist de tu entregable final
- ✓El prompt nació de un PMV — ¿4 bloques — y solo creció por un comportamiento real observado?
- ✓Está versionado (v1 → v2 → v3), ¿y puedes generar el diff entre dos versiones?
- ✓Cada regla que se conserva tiene porqué + prueba que fallaría ¿sin ella?
- ✓La seguridad está declarada por principio, ¿no por mecánica/lista?
- ✓Existe un guía de disposición con un decision loop explícito, en un CLAUDE.md?
- ✓Las bloqueos están vinculados: hook de posedición + effortLevel + ¿la regla está en el lugar correcto?
Reporta fielmente, siempre
Si una prueba falló, dilo y muestra la salida. Si omitiste un paso, di que lo omitiste. Si está hecho y verificado, dilo sin dudar. Nunca presentes un resultado sin verificar como si estuviera listo. La confianza se construye con informes precisos, no con informes optimistas, y eso vale para tu prompt, tu guía y cada turno que ejecutes de ahora en adelante.
📝 Resumen del Módulo
- ✓Une todo en un PMV: identidad + persona (4 ejes) + loop + seguridad — y solo crece mediante comportamiento real
- ✓Crea versiones: guarda v1 → v2 → v3 y lee el diff de tu propio prompt: ahora tú eres el laboratorio
- ✓Escribe el porqué + la prueba de cada regla; sin una prueba que fallaría, la regla se elimina
- ✓Arma el tu guía de disposición — decision loop + valores predeterminados, en un CLAUDE.md
- ✓Combínalo con las bloqueos: hook PostToolUse + effortLevel + dónde vive la regla — por sí solo, ninguno basta
- ✓Cruza el autoverificación antes de decir «listo»: verificado con una comprobación real, comunicado con honestidad
🎉 Completaste O Manual Oculto da IA
Tres rutas, veintitantos módulos y todo un recorrido: saliste de leer la anatomía de un system prompt, pasó por leer la evolución entre versiones, y llega aquí autor de tu propio prompt versionado — con una guía de disposición, bloqueos mecánicos y una lista de verificación de entrega. No memorizaste reglas; heredaste un método.
La metalección que atraviesa todo: los labs convergieron, entre 2024 y 2026, de reglas a principios, de prohibición a valor, de énfasis difuso a énfasis escaso, de prompt que crece a prompt que consolidaAhora te toca escribir así. Mantén el ritual del «Diff de la Semana» y tu prompt nunca se echará a perder por dentro.