CAFEERON21br18/Daily_Master_Prompt

Créer une invite maîtresse quotidienne

Vue d'ensemble

Une invite maîtresse quotidienne est un fichier autonome, DAILY_PROMPT.md, que toute nouvelle session peut exécuter pour reprendre un projet, effectuer une journée de travail et le laisser prêt pour le lendemain. La mémoire du projet réside dans cinq fichiers d'état à côté de lui, jamais dans la conversation. Après la première exécution, l'utilisateur tape uniquement :

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

Saisie de l'utilisateur : $ARGUMENTS (un dossier et/ou une explication du projet ; les deux peuvent être absents).

Ce qui existe lorsque vous avez terminé

Tout se trouve dans le dossier du projet (<folder>), construit à partir des modèles dans ${CLAUDE_SKILL_DIR}/templates/ :

Fichier	Contenu	Modifications
DAILY_PROMPT.md	Mission, jalon, règles, carte de contexte, procédure de session	Uniquement lorsque l'utilisateur le demande
BACKLOG.md	Éléments de travail ordonnés avec identifiants et statut	À chaque exécution
DEVLOG.md	Journal daté en ajout seul de chaque exécution	À chaque exécution
HANDOFF.md	État actuel, 3 prochaines actions, avertissements	Réécrit à chaque exécution
QUESTIONS.md	Questions pour l'utilisateur, avec une recommandation chacune	Les exécutions posent des questions, l'utilisateur répond
APPROVALS.md	Actions risquées ou irréversibles en attente de oui/non	Les exécutions demandent, l'utilisateur décide

La progression va dans les fichiers d'état. DAILY_PROMPT.md ne contient que ce qui reste vrai pendant des semaines.

Étapes

1. Trouver le dossier. Utilisez le dossier dans les arguments. Sinon, utilisez le dossier contenant le cahier des charges ou le code du projet ; si plusieurs correspondent, demandez.
2. Rassembler le contexte en lisant, pas en demandant. L'explication de l'utilisateur ; README*, CLAUDE.md, AGENTS.md ; les spécifications (GDD, PRD, feuille de route, docs/) ; git log --oneline -30 et git status ; une arborescence de fichiers de 2 à 3 niveaux ; les manifestes et scripts qui révèlent les commandes de construction, de test, de lint et d'exécution ; les serveurs MCP connectés nécessaires au travail ; les notes TODO/FIXME ; tous les fichiers d'état existants. Séparez ce qui est fait de ce qui ne l'est pas.
3. Demandez uniquement ce que les fichiers ne disent pas, en un seul appel AskUserQuestion (max 4 questions), à partir de cette liste : le jalon actuel et sa définition de terminé ; comment un élément terminé est vérifié ; les règles strictes (ne jamais publier/déployer, demander avant de nouvelles dépendances, politique de branche et de push) ; si les exécutions sont supervisées, non supervisées, ou les deux. Si personne ne répond, prenez l'interprétation la plus sûre (non supervisé, pas de push, pas de publication) et enregistrez chaque hypothèse dans QUESTIONS.md avec sa ligne « Supposé jusqu'à réponse ».
4. Écrire DAILY_PROMPT.md à partir de DAILY_PROMPT.template.md. Chaque section nomme les chemins réels, commandes, outils et jalon de ce projet. Dans la ligne quotidienne, écrivez le dossier relatif à la racine du dépôt (là où l'utilisateur ouvre Claude), pas un chemin absolu ; lorsque le dossier est la racine elle-même, la ligne est Read DAILY_PROMPT.md and execute it. Si l'exécution ou le test du projet pourrait toucher des données réelles (fichiers utilisateur, comptes actifs, production, un lieu publié), ajoutez une règle de base et une méthode de vérification qui utilisent une copie temporaire ou de test à la place.
5. Créer les fichiers d'état à partir de leurs modèles. Si l'un existe déjà, fusionnez-le ; ne jamais écraser ou réorganiser l'historique de l'utilisateur. Amorcez BACKLOG.md à partir du jalon, des lacunes des spécifications, des TODOs et des objectifs de l'utilisateur, ordonnés de sorte que l'élément 1 puisse commencer aujourd'hui et que chaque élément tienne dans une session, chacun avec un « Terminé quand » concret. Amorcez HANDOFF.md avec l'état de départ. Un modèle dont l'entrée d'exemple ne s'applique pas encore conserve son en-tête et ses lignes de format, avec Aucun pour l'instant. à la place de l'entrée. Vérifiez : grep -n "{{" <folder>/*.md ne renvoie rien.
6. Valider les nouveaux fichiers si le dossier est dans un dépôt git (chore: add daily master prompt), en suivant les règles de validation du dépôt.
7. Première exécution. Sauf si l'utilisateur a dit de ne pas le faire, exécutez DAILY_PROMPT.md maintenant, exactement comme le ferait une nouvelle session. C'est le test du prompt : lorsqu'une étape était ambiguë, a échoué ou nécessitait des connaissances qui ne figurent pas dans les fichiers, corrigez le prompt et notez la correction dans DEVLOG.md.
8. Passer la main. Dites à l'utilisateur ce qui a été créé, ce que la première exécution a fait, et donnez la ligne quotidienne dans un bloc de code :

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

   Mentionnez /daily-master-prompt:run <folder> comme équivalent, et que la ligne fonctionne également comme prompt d'une tâche planifiée.

Mise à jour d'un prompt existant

Lorsque DAILY_PROMPT.md existe déjà, lisez-le ainsi que chaque fichier d'état d'abord. Appliquez la modification sur place, ou sous ## Addenda comme entrée datée lorsque l'utilisateur demande un addenda. Conservez tout l'état. Enregistrez la modification dans DEVLOG.md.

Erreurs courantes

Erreur	Résultat	Faire à la place
Prompt générique (« travailler sur le projet »)	Chaque exécution redécouvre le projet	Chemins réels, commandes, jalon, définition de terminé
Progression écrite dans DAILY_PROMPT.md	Le prompt devient obsolète et contredit les fichiers d'état	La progression réside dans BACKLOG/HANDOFF/DEVLOG
Aucune étape de vérification	Des éléments « terminés » qui ne fonctionnent pas	Une vérification concrète par élément (tests, build, playtest, lint)
Les exécutions s'arrêtent au premier obstacle	Les jours non supervisés ne produisent rien	Enregistrer dans QUESTIONS/APPROVALS, continuer avec l'élément suivant
Éléments du backlog trop volumineux	Travail à moitié fait chaque jour	Diviser jusqu'à ce qu'un élément tienne dans une session
Écrasement des fichiers d'état existants	L'utilisateur perd son historique	Fusionner