CAFEERON21br18/Daily_Master_Prompt

Crear un Prompt Maestro Diario

Resumen

Un prompt maestro diario es un archivo autocontenido, DAILY_PROMPT.md, que cualquier sesión nueva puede ejecutar para retomar un proyecto, realizar un día de trabajo y dejarlo listo para el día siguiente. La memoria del proyecto reside en cinco archivos de estado junto a él, nunca en la conversación. Después de la primera ejecución, el usuario solo escribe:

Read <carpeta>/DAILY_PROMPT.md and execute it.

Entrada del usuario: $ARGUMENTS (una carpeta y/o una explicación del proyecto; cualquiera puede faltar).

Qué existe al finalizar

Todo en la carpeta del proyecto (<carpeta>), construido a partir de las plantillas en ${CLAUDE_SKILL_DIR}/templates/:

Archivo	Contiene	Cambios
DAILY_PROMPT.md	Misión, hito, reglas, mapa de contexto, procedimiento de sesión	Solo cuando el usuario lo pide
BACKLOG.md	Elementos de trabajo ordenados con IDs y estado	Cada ejecución
DEVLOG.md	Registro diario con fecha, solo añadir	Cada ejecución
HANDOFF.md	Estado actual, siguientes 3 acciones, advertencias	Se reescribe cada ejecución
QUESTIONS.md	Preguntas para el usuario, con una recomendación cada una	Las ejecuciones preguntan, el usuario responde
APPROVALS.md	Acciones arriesgadas o irreversibles en espera de sí/no	Las ejecuciones solicitan, el usuario decide

El progreso va en los archivos de estado. DAILY_PROMPT.md solo contiene lo que sigue siendo cierto durante semanas.

Pasos

1. Encontrar la carpeta. Usa la carpeta indicada en los argumentos. De lo contrario, usa la carpeta que contenga la especificación o el código del proyecto; si hay varias posibles, pregunta.
2. Recopilar contexto leyendo, no preguntando. La explicación del usuario; README*, CLAUDE.md, AGENTS.md; especificaciones (GDD, PRD, hoja de ruta, docs/); git log --oneline -30 y git status; un árbol de archivos de 2-3 niveles; manifiestos y scripts que revelen comandos de compilación, prueba, lint y ejecución; servidores MCP conectados que el trabajo necesite; notas TODO/FIXME; cualquier archivo de estado existente. Separa lo que está hecho de lo que no.
3. Pregunta solo lo que los archivos no digan, en una sola llamada AskUserQuestion (máximo 4 preguntas), de esta lista: el hito actual y su definición de terminado; cómo se verifica un elemento terminado; reglas estrictas (nunca publicar/desplegar, preguntar antes de nuevas dependencias, política de ramas y push); si las ejecuciones son atendidas, no atendidas o ambas. Si nadie responde, toma la lectura más segura (no atendida, sin push, sin publicar) y registra cada suposición en QUESTIONS.md con su línea "Asumido hasta que se responda".
4. Escribir DAILY_PROMPT.md a partir de DAILY_PROMPT.template.md. Cada sección nombra las rutas reales, comandos, herramientas e hito de este proyecto. En la línea diaria, escribe la carpeta relativa a la raíz del repositorio (donde el usuario abre Claude), no una ruta absoluta; cuando la carpeta es la raíz misma, la línea es Read DAILY_PROMPT.md and execute it. Si ejecutar o probar el proyecto pudiera tocar datos reales (archivos de usuario, cuentas activas, producción, un lugar publicado), agrega una regla base y un método de verificación que use una copia temporal o de prueba.
5. Crear los archivos de estado a partir de sus plantillas. Si uno ya existe, fusiona; nunca sobrescribas ni reordenes el historial del usuario. Siembra BACKLOG.md a partir del hito, las brechas de la especificación, los TODOs y los objetivos del usuario, ordenados para que el elemento 1 pueda comenzar hoy y cada elemento quepa en una sesión, cada uno con un "Terminado cuando" concreto. Siembra HANDOFF.md con el estado inicial. Una plantilla cuya entrada de ejemplo aún no aplique conserva su encabezado y líneas de formato, con Ninguno aún. en lugar de la entrada. Verifica: grep -n "{{" <carpeta>/*.md no devuelve nada.
6. Hacer commit de los nuevos archivos si la carpeta está en un repositorio git (chore: add daily master prompt), siguiendo las reglas de commit del repositorio.
7. Primera ejecución. A menos que el usuario haya dicho que no, ejecuta DAILY_PROMPT.md ahora, exactamente como lo haría una sesión nueva. Esta es la prueba del prompt: cuando un paso fue ambiguo, falló o necesitó conocimiento que no está en los archivos, corrige el prompt y anota la corrección en DEVLOG.md.
8. Entrega. Informa al usuario qué se creó, qué hizo la primera ejecución, y da la línea diaria en un bloque de código:

   Read <carpeta>/DAILY_PROMPT.md and execute it.
   

   Menciona /daily-master-prompt:run <carpeta> como lo mismo, y que la línea también funciona como el prompt de una tarea programada.

Actualizar un prompt existente

Cuando DAILY_PROMPT.md ya existe, léelo y lee cada archivo de estado primero. Aplica el cambio en el lugar correspondiente, o bajo ## Addenda como una entrada fechada cuando el usuario solicite un addendum. Conserva todo el estado. Registra el cambio en DEVLOG.md.

Errores comunes

Error	Resultado	Hacer en su lugar
Prompt genérico ("trabajar en el proyecto")	Cada ejecución redescubre el proyecto	Rutas reales, comandos, hito, definición de terminado
Progreso escrito en DAILY_PROMPT.md	El prompt se vuelve obsoleto y contradice los archivos de estado	El progreso vive en BACKLOG/HANDOFF/DEVLOG
Sin paso de verificación	Elementos "terminados" que no funcionan	Una comprobación concreta por elemento (pruebas, compilación, test de juego, lint)
Las ejecuciones se detienen en el primer bloqueo	Los días no atendidos no producen nada	Registrar en QUESTIONS/APPROVALS, continuar con el siguiente elemento
Elementos del backlog demasiado grandes	Trabajo a medio terminar cada día	Dividir hasta que un elemento quepa en una sesión
Sobrescribir archivos de estado existentes	El usuario pierde el historial	Fusionar