17 Mar 2026
3 min
tlotp sdd ia symfony playwright

San Patricio 2026: del prompt al prod en una sesión con TLOTP y SDD

El 17 de marzo de 2026, TLOTP especificó y orquestó la feature de San Patricio: requirements.md, design.md, tasks.md y un equipo de agentes que implementaron en paralelo. Del prompt al verde irlandés en una sesión.

San Patricio 2026: del prompt al prod en una sesión con TLOTP y SDD

El 17 de marzo de 2026 esta web amaneció con tema irlandés. Fuente celta, tréboles cayendo, un botón 🍀 en el header que sustituye al toggle de dark mode y un leprechaun escondido en algún lugar. Todo esto fue especificado e implementado en una sola sesión usando TLOTP y Gandalf SDD.

Qué es TLOTP

TLOTP (The Lord of the Prompt) es un super-prompt interactivo creado por Pépeton hijo de Móreuton y Claudeton hijo de Codeton: "Un prompt para dominarlos a todos". No tiene instalación — es copy-paste del prompt en Claude Code. Sin setup. Sin configuración previa.

Se organiza como épicas del universo de Tolkien, cada una con su banner ASCII, menú interactivo y modos de operación:

  • 🔮 Palantír — Gestor de configuraciones de Claude Code (CLAUDE.md, settings.json, rules/, hooks)
  • 🌳 Ents — Guardianes del CI/CD: analizan, sugieren mejoras y crean GitHub Actions consultando documentación oficial en tiempo real
  • ⚒️ Celebrimbor — Gestor de skills: buscar, instalar, actualizar y eliminar skills de ~/.claude/skills/
  • 🏹 Bardo — Proveedor de MCPs y plugins: analiza el stack, recomienda e instala con confirmación
  • 👑 Aragorn — Gestor de agentes y Agent Teams para trabajo paralelo
  • ⚡ Gandalf — El Mago Blanco. Spec-Driven Development

Cada épica consulta documentación oficial en tiempo real, nunca actúa sin confirmación y se adapta al entorno del usuario (Linux, macOS, Windows).

Este portfolio tiene TLOTP configurado a fondo: CLAUDE.md, settings, rules, hooks y más de 30 agentes especializados instalados y listos para invocar. La épica Aragorn gestiona todo ese arsenal — desde listar y buscar agentes hasta armar Agent Teams para trabajo paralelo.

Qué es Gandalf SDD

Gandalf SDD se presenta como "El Antídoto al Vibe Coding". Su filosofía: sin especificación no hay expedición. Sin mapa no hay victoria.

El flujo arranca con los Exploradores Rohirrim: cinco agentes que cabalgan en paralelo para mapear el proyecto antes de que el usuario espere. Stack tecnológico, arquitectura existente, CI/CD, estado del repo, decisiones tomadas. Cuando regresan, Gandalf tiene el contexto completo.

Con ese mapa, genera en orden:

  1. requirements.md — Requisitos en formato EARS (Event-driven, Unwanted, Option, Ubiquitous) con criterios de aceptación precisos
  2. design.md — Arquitectura de la solución con ADRs (Architecture Decision Records) y diagramas Mermaid
  3. tasks.md — Desglose atómico de implementación con grafo de dependencias entre tareas
  4. san-patricio-team.yml — Y aquí entra el detalle clave: con el contexto del SDD ya generado y conociendo los más de 30 agentes disponibles en el entorno, diseñó el team completo. No eligió agentes al azar — los asignó según el rol que cada uno cubre mejor: php-pro para el Controller, javascript-pro para el JS del tema, test-automator para los E2E, architect-reviewer y code-reviewer para las revisiones, scrum-master en reserva para desbloqueos.

El desarrollador revisa y aprueba cada documento antes de pasar al siguiente. La IA no improvisa durante la implementación: todo está decidido antes de escribir una línea de código.

La sesión del 17 de marzo: lo que realmente pasó

Gandalf SDD generó para esta feature:

  • 6 requisitos funcionales (RF-01 a RF-06): activación del tema vía localStorage, expiración automática a las 23:59:59 Europe/Madrid, sustitución del botón darkmode por 🍀, desactivación al hacer clic, aislamiento de E2E existentes y artículo Code & AI. Y ese límite temporal no era un detalle técnico — era la gracia de la feature. La spec lo estableció como requisito MUST desde el primer borrador: el tema debía existir solo el 17 de marzo, morir a medianoche y no volver. Una feature con fecha de caducidad bakeada en el diseño
  • 3 requisitos no funcionales: performance (<100ms overhead), mantenibilidad (archivos aislados) y testabilidad (E2E limpian localStorage)
  • 3 ADRs: localStorage vs cookies, stylesheet dinámico vs class toggle en body, verificación dual server+client de la expiración
  • 7 tareas con grafo de dependencias explícito (T1→T3, T2→T4→T5, T1+T2+T3+T4+T5→T6)
  • 1 team.yml con 8 miembros: Sauron (orchestrator), Gandalf (PHP), Frodo (fullstack), Legolas (JS), Eowyn (E2E), Aragorn (architect-reviewer), Gimli (code-reviewer), Bilbo (scrum-master, en reserva)

Cómo ejecutó el team: las interacciones reales

Sauron (el orchestrator) leyó los docs del SDD y lanzó la primera oleada en paralelo:

Oleada 1 — Gandalf y Frodo simultáneos:

  • Gandalf (php-pro) recibió su misión: SanPatricioController.php, ruta /san_patricio, verificación de fecha con DateTimeZone('Europe/Madrid'). Leyó PortfolioController para entender el patrón existente, creó el Controller y verificó PHPStan level 9 antes de declararse listo.
  • Frodo (fullstack-developer) trabajó en paralelo en dos frentes: añadir el script tag en base.html.twig y redactar el artículo en data/articles.json. Aquí encontró su primer obstáculo — usó {{ asset('js/san_patricio.js') }} de Symfony, pero symfony/asset no estaba instalado en el proyecto.

Oleada 2 — Tres agentes en paralelo cuando Oleada 1 terminó:

  • Gandalf (de nuevo, ahora con T1 en verde) creó templates/pages/san_patricio/index.html.twig: página festiva con mensaje irlandés, Guinness, Sláinte! y emojis de trébol.
  • Legolas (javascript-pro) recibió las tareas más densas: san_patricio.js (gestión del tema via localStorage, activación/desactivación, verificación de fecha client-side) y san_patricio.css (estilos aislados, botón trébol con mismas dimensiones que el darkmode toggle). Revisó el HTML del header antes de escribir una línea para asegurarse de usar el ID correcto (theme-toggle).
  • Aragorn (architect-reviewer) revisó el Controller en paralelo. Su veredicto: "Aprobado con sugerencias" — la lógica de fecha en el Controller viola el patrón hexagonal estricto, pero es pragmáticamente justificable para una feature efímera de un día.

Oleada 3 — Gimli y Eowyn en paralelo cuando T1-T5 estaban completos:

  • Gimli (code-reviewer) ejecutó PHPStan, CS Fixer, ESLint y validó el JSON. Encontró dos should-fix: el campo section extra en articles.json y la falta de try/catch alrededor de localStorage. Ninguno bloqueante.
  • Eowyn (test-automator) fue quien detectó el bug de Frodo: {{ asset() }} rompía todas las páginas con un 500 de Symfony. Lo corrigió a /js/san_patricio.js (ruta directa, coherente con el resto del proyecto) y continuó con los tests. Siguió el patrón POM del proyecto — no playwright/pages/ como especificaban los docs, sino playwright/components/ con index.ts + selectors.ts porque así estaba el resto. También detectó que el pre-existing test de SEO esperaba 9 artículos pero el nuevo artículo de T7 lo dejaba en 10. Lo actualizó.

Resultado al terminar la sesión:

PHPUnit:    263/263  ✅
PHPStan:    0 errors ✅  (level 9)
CS Fixer:   0 fixes  ✅
ESLint:     0 errors ✅
E2E:      101/101    ✅

Por qué SDD con IA funciona

La IA sin spec improvisa. Toma decisiones de arquitectura durante la implementación, introduce inconsistencias entre archivos y el desarrollador no sabe qué esperar hasta que ve el código. Con SDD, el orden se invierte: primero spec, luego código.

El coste real no está en escribir código — está en corregirlo. Arreglar un requirements.md antes de implementar cuesta cero. Arreglar una decisión de arquitectura después de que cinco agentes ya han escrito código encima es caro.

Además, la spec revisable convierte al desarrollador en revisor técnico antes de que exista código. Es el momento más barato para detectar problemas.

El próximo experimento

Esta sesión fue una feature dentro de un proyecto existente. El siguiente paso es más ambicioso: SDD full-project desde cero hasta producción en una sesión, con métricas reales:

  • Tiempo total por fase (exploración, spec, implementación, QA)
  • Tokens consumidos
  • Ratio correcciones pre-implementación vs post-implementación
  • Calidad del código entregado (PHPStan, cobertura)

Si la hipótesis se sostiene —especificar bien cuesta menos que corregir mal— los números lo mostrarán.

La web que estás viendo ahora mismo, con la fuente irlandesa y los tréboles cayendo, es el output de esa sesión. No hay nada retocado a mano en los archivos que generaron los agentes.

Easter egg: el leprechaun escondido 🧙

Esta feature tiene un detalle que Gandalf SDD no especificó: hay un leprechaun escondido en algún lugar de la web, visible solo con el tema activo.

Si lo encuentras hoy, el 17 de marzo, escríbeme — te invito a una Guinness. 🍺