🎯 Con esta guía vas a convertir una idea en una app en desarrollo, dirigida por IA: un documento de especificaciones (el plano maestro), un roadmap de tickets ejecutables, y un tablero donde cada ticket se ejecuta solo con el modelo correcto — sin quemarte el uso incluido de tu plan de Claude.
Así es exactamente como estamos construyendo Audigital, una app que audita expedientes para cumplimiento de PLD. Los 3 prompts vienen con espacios [ASÍ] para que los adaptes a tu proyecto. Lo que necesitas antes de empezar:
- Claude Code instalado y autenticado (la terminal donde vive todo esto)
- Un plan de Claude (Pro o Max)
- Tu idea — aunque sea en servilleta
Paso 1 — El plano maestro (con Opus 4.8)
Antes de tocar una sola línea de código, le dices a Opus todas las funcionalidades que tu app requiere y él te escribe el documento completo de especificaciones. Ese documento es la fuente de verdad que los demás agentes van a leer.
Eres el arquitecto de producto de [NOMBRE DE TU PROYECTO].
Escribe el documento `[Proyecto]-Plano-Maestro.md` en la raíz del repositorio.
Es el plano maestro (PRD + blueprint técnico) del MVP: la única fuente de
verdad que otros agentes de IA van a leer para planear y construir la app.
Lo que la app tiene que hacer:
- [FUNCIONALIDAD 1 — descríbela como se la contarías a un amigo]
- [FUNCIONALIDAD 2]
- [FUNCIONALIDAD 3… agrega todas las que quieras]
Contexto del negocio:
- Quién lo va a usar: [USUARIOS]
- El problema que resuelve: [PROBLEMA]
- Restricciones: [ej. es regulatorio, hay plazo, presupuesto limitado]
El documento debe incluir, con encabezados claros:
1. Visión y alcance del MVP (qué entra y qué NO entra)
2. Usuarios y flujos principales, pantalla por pantalla
3. Especificación de cada funcionalidad con criterios de aceptación
4. Modelo de datos propuesto
5. Stack técnico recomendado y por qué
6. Riesgos y decisiones abiertas
Reglas:
- No escribas código. Solo el documento.
- Si algo es ambiguo, decide y explica tu decisión en una nota.
- Sé específico: nada de "el sistema debe ser rápido" — números y
comportamientos concretos.💡 Tip de Erik: entre más detalle le des en las funcionalidades, menos decisiones inventa la IA. Nosotros escribimos la lista completa primero y luego pegamos el prompt — el documento de Audigital salió de una sola corrida.
Paso 2 — El roadmap (con Fable 5)
Aquí entra el modelo más potente: le das el plano maestro y te regresa el plan de construcción completo — tickets por fases, con criterios, pruebas y hasta qué modelo debe ejecutar cada uno.
Audita este repositorio de [NOMBRE DE TU PROYECTO].
Antes de escribir, lee:
- `[Proyecto]-Plano-Maestro.md`
- el código y las pruebas relevantes en `src/` y `tests/` [ajusta a tus carpetas,
o borra esta línea si tu repo está vacío]
Crea ÚNICAMENTE `roadmap.md` en la raíz.
El roadmap debe traducir la visión del plano maestro en tickets por fases,
ejecutables por agentes de código. Lo van a ejecutar Fable 5, Opus 4.8 y
Sonnet 5. Cada ticket debe incluir:
- ID y título
- rutas de archivo concretas y verificadas
- archivos probables a crear, si aplica
- dependencias y orden
- criterios de aceptación técnicos explícitos
- pruebas o verificación requerida
- comandos exactos a correr cuando sea posible
- invariantes y notas de "no tocar"
- el modelo que debe ejecutar el ticket (Fable 5, Opus 4.8 o Sonnet 5)
Límites de ejecución:
- No modifiques, crees ni borres archivos de código.
- No implementes arreglos.
- No crees ramas ni commits.
- Evalúa y detente.
- Si estás sopesando opciones de arquitectura, escribe tu recomendación directa.
- Solo propone tickets para rutas que verificaste físicamente en el workspace.
- No expliques tu razonamiento paso a paso en el output.💡 Tip de Mel: la línea de oro es la del modelo por ticket. Fable es carísimo para todo — así que él mismo reparte: lo difícil se lo queda Fable, lo rutinario se va a Sonnet. En nuestro roadmap de Audigital salieron 39 tickets en 8 fases, cada uno con su modelo asignado.
Paso 3 — El tablero que ejecuta solo (con Fable 5 u Opus)
El paso que lo cambia todo: un kanban local donde cada ticket tiene su botón de Ejecutar. Le picas, y Claude Code corre ese ticket en segundo plano con el modelo recomendado.
Lee `roadmap.md`. Crea un tablero local de ejecución en
`tools/roadmap-dashboard/` con DOS archivos: `server.mjs` (Node 18+, sin
dependencias externas) e `index.html`.
Qué debe hacer:
1. KANBAN: columnas Por hacer / En curso / Bloqueado / Completado. Una card
por ticket del roadmap con: ID, título, descripción corta, dependencias
(marcando cuáles ya están completas) y el modelo recomendado que dice el
roadmap.
2. BITÁCORA: crea `roadmap-status.md` como libro de registro del estado de
cada ticket. El tablero LEE roadmap.md pero solo ESCRIBE en la bitácora —
nunca edita el roadmap.
3. BOTÓN EJECUTAR por card: valida que el ticket esté pendiente y sin
dependencias incompletas, lo marca "en curso" en la bitácora, y lanza
Claude Code en segundo plano con el modelo recomendado (editable por card
con un select):
claude --model <id-del-modelo> -p "<prompt del ticket>" --output-format stream-json --verbose
IDs exactos: Fable 5 = claude-fable-5 · Opus 4.8 = claude-opus-4-8 ·
Sonnet 5 = claude-sonnet-5.
El prompt del ticket le ordena al agente: ejecutar el ticket tal como está
escrito en roadmap.md, respetar sus invariantes, correr sus verificaciones,
y al terminar (o bloquearse) actualizar la bitácora y dejar un comentario.
4. LOGS: guarda la salida de cada corrida en `logs/<ticket>-<timestamp>.log`,
visible desde la card.
5. COMENTARIOS por ticket: un hilo en `comments/<TICKET>.jsonl` (una línea
JSON por comentario). El agente los lee ANTES de empezar — mis notas son
vinculantes — y reporta ahí al terminar.
6. REFRESCO: el tablero se actualiza solo cada pocos segundos leyendo la
bitácora.
7. Solo escucha en 127.0.0.1. Arranque: node tools/roadmap-dashboard/server.mjs💡 Tip de Erik: sobre permisos — nosotros corremos los agentes con permisos automáticos porque revisamos todo por bitácora y comentarios. Si prefieres que te pidan permiso, agrega
--permission-mode acceptEditsa la línea de claude en vez del bypass. Empieza así y suéltales la rienda cuando les agarres confianza.
Cómo adaptarlo a TU proyecto
- Rellena los
[CORCHETES]del Paso 1 con tu idea — es el único paso donde tú pones el contenido. - Los Pasos 2 y 3 casi no se tocan: solo el nombre del proyecto y las carpetas de tu repo.
- Si tu proyecto no es una app (es un sitio, una automatización, un curso), el flujo aguanta igual: plano maestro → roadmap → tablero.
- El orden importa: sin plano maestro, el roadmap inventa; sin roadmap, el tablero no tiene qué ejecutar.
🤝 ¿Lo armaste para tu proyecto? Cuéntanos cómo te fue — te leemos en los comentarios del video. Y si quieres más recursos como este, en la bóveda están todos:boveda.hazlotuyoia.com