Plan admin

Que fait Plan admin ?

Trois routines pour gérer plusieurs projets en parallèle : commencer la journée, la clôturer et faire le point sur la semaine. La compétence fournit la méthode ; chaque projet fournit les données (calendrier, règles, quel projet va quel jour, où est stockée la prochaine action) dans ses instructions et son gestionnaire de projet. Ainsi, la même compétence fonctionne dans n'importe quel projet sans copier ses données, et chaque donnée reste à un seul endroit.

Parlez à l'utilisateur dans la langue qu'il utilise, y compris les libellés des formats ci-dessous.

Avant toute routine

Vérifier la date

Obtenez la date et l'heure actuelles à partir de l'outil disponible (un outil d'horloge dans la session, ou date dans un terminal), dans le fuseau horaire de l'utilisateur. Ne les déduisez pas de la conversation ou de la dernière note : un mauvais jour compromet tout le plan.

Rassembler les données du projet

Vérifiez quels outils la session possède (y compris les outils différés) et lisez, dans cet ordre :

1. Instructions du projet, CLAUDE.md et préférences de l'utilisateur. Ils indiquent quelles phrases déclenchent chaque routine, quel bloc vient toujours en premier, quels jours sont chômés, où se trouve l'état et ce qui peut être écrit sans demander. Tout ce qu'ils disent prévaut sur cette compétence.
2. La page de calendrier et de règles, si les instructions en nomment une (par exemple, une page de revue hebdomadaire dans Notion avec le calendrier actuel, les règles, les éléments en attente de révision et un modèle de revue). Elle indique quel projet va dans quel bloc chaque jour.
3. La base de projets : statut, priorité, date clé et prochaine action pour chaque projet.
4. La base de tâches, s'il y en a une : les tâches non terminées avec une date.
5. S'il n'y a pas de gestionnaire de projet, les sections de statut et d'éléments en attente de CLAUDE.md, ou la note du projet dans l'application de notes de l'utilisateur.

Ne demandez rien que ces sources détiennent déjà. Si vous n'avez pas l'adresse d'une base de données ou d'une page, cherchez-la par le nom que les instructions donnent ; si elle ne se trouve pas, dites-le en une ligne et continuez avec ce que vous avez.

Si une source contredit une autre (les instructions disent une chose sur le calendrier et la page en dit une autre), signalez-le et ne choisissez pas pour l'utilisateur.

S'il n'y a pas de calendrier

Dans un projet sans calendrier ni blocs (un dépôt autonome, par exemple), chaque routine se réduit à un seul bloc : le projet de la session, avec sa prochaine action et son premier pas. N'inventez pas de calendrier. Si l'utilisateur en veut un, aidez-le à l'écrire dans son gestionnaire de projet ou ses instructions, avec son approbation.

Ce qui compte comme une prochaine action

Quelque chose de physique et concret qui peut être fait en moins de deux heures, sauf si les instructions fixent une limite différente. « Écrire l'e-mail pour demander un devis » fonctionne ; « faire avancer le projet » ne fonctionne pas. Le premier pas est encore plus petit : ce qui se fait dans les cinq premières minutes (« ouvrir le brouillon d'hier et relire le dernier paragraphe »). Il existe pour faciliter le démarrage les jours où il est difficile de commencer.

Lorsqu'un projet n'a pas de prochaine action, suggérez-en une et marquez-la comme proposition, en indiquant d'où vous la tenez (la dernière note, une tâche ouverte, le statut). Ne l'écrivez pas dans le gestionnaire de projet avant que l'utilisateur ne l'approuve.

Avant de qualifier quelque chose d'en attente

Les gestionnaires de projet prennent du retard : du travail est effectué sous un autre nom, dans une autre tâche, ou dans une session qui ne l'a jamais enregistré. Avant de dire que quelque chose est encore en attente ou en retard, cherchez des signes qu'il a déjà été fait : la tâche marquée comme terminée, une note ultérieure ou un journal de session, un commit, une entrée dans la revue hebdomadaire. S'il y en a, marquez-le « à confirmer » au lieu de en attente. Un faux « ce n'est toujours pas fait » coûte la confiance dans tout le reste.

1. Plan quotidien

Commencez uniquement lorsque l'utilisateur le demande. Dans toute autre conversation, ne donnez pas le plan de la journée sauf si on vous le demande.

1. Jour chômé. Si les règles disent qu'aujourd'hui est un jour chômé, dites-le en une phrase et arrêtez-vous. Ne suggérez pas de travailler ou de rattraper.
2. Blocs d'aujourd'hui. Prenez dans le calendrier quel projet va dans quel bloc. Si les instructions définissent un bloc qui vient toujours en premier, mettez-le en premier.
3. Pour chaque bloc : le projet, sa prochaine action (depuis le gestionnaire de projet, ou une proposition marquée) et un premier pas de quelques minutes.
4. Alertes de dates. Vérifiez les dates clés et les tâches datées dans tous les projets actifs, pas seulement ceux d'aujourd'hui. Tout ce qui est dû aujourd'hui ou demain va tout en haut, avant les blocs. Tout ce qui est dû dans les sept prochains jours va sur une seule ligne à la fin. Tout ce qui est plus éloigné reste à l'écart, sauf si la préparation doit commencer maintenant pour y parvenir.
5. Empilement d'engagements. Si plusieurs dates clés tombent la même semaine dans les quatorze prochains jours, ou si deux projets ont besoin de la même ressource, personne ou argent en même temps, dites-le en une ligne et indiquez exactement ce qui se chevauche. Ne dites pas ce qui doit céder : c'est à l'utilisateur de décider.
6. Retour après une absence. Si la dernière activité enregistrée (la dernière clôture de journée, la dernière modification d'une prochaine action, la dernière session) remonte à plus de trois jours ouvrables selon le calendrier (ou plus de quatre jours calendaires s'il n'y a pas de calendrier), commencez par ce qui est devenu dû entre-temps, en une ligne, et donnez le reste comme d'habitude. Pas de reproche pour l'intervalle. Si une compétence d'ouverture de session a déjà dit cela dans la session, ne le répétez pas.
7. Éléments en attente de révision. Si la page de calendrier liste des éléments en attente de révision dont la condition est maintenant remplie (une date passée, une étape atteinte), mentionnez-le en une ligne.

Format, court et dans cet ordre (laissez de côté tout ce qui est vide) :

**Dû aujourd'hui :** <uniquement si quelque chose est dû aujourd'hui ou demain>
**<Bloc fixe, le cas échéant> :** <projet>. Prochaine action : <...>. Premier pas : <...>.
**Principal :** <projet>. Prochaine action : <...>. Premier pas : <...>.
**Secondaire :** <projet>. Prochaine action : <...> (proposition, de <source>). Premier pas : <...>.
**Cette semaine :** <dates dans les sept prochains jours, sur une ligne>
**Alerte :** <chevauchements, éléments en attente de révision ou sources en désaccord>

Utilisez les noms de blocs que le calendrier utilise ; « Principal » et « Secondaire » ne sont que les valeurs par défaut pour une journée à deux blocs.

2. Clôture de journée

1. Demandez en une ligne où en est chaque bloc d'aujourd'hui, en les nommant (« Où en êtes-vous avec la proposition client et la copie du site web ? »). Si la conversation le rend déjà clair, ne demandez pas.
2. Reconnaissez ce qui a été fait, en une phrase concrète : ce qui a réellement avancé, sans exagérer. Si un bloc n'a pas bougé, dites-le simplement et sans reproche ; une journée lente aussi est enregistrée.
3. Proposez les prochaines actions, en suivant la règle ci-dessus :
   • Pour chaque projet travaillé aujourd'hui, la prochaine action qui découle de là où il a été laissé.
   • Pour les blocs du prochain jour ouvrable (qui peuvent être des projets différents), vérifiez que leur prochaine action est décidée. Si elle manque ou est obsolète, proposez-en une. Si demain est un jour chômé, regardez le prochain jour ouvrable.
4. N'écrivez que ce qui est approuvé, dans le champ que les instructions nomment (par exemple, un champ « Prochaine action » dans la base de projets). Ce champ est le seul endroit où il est enregistré où chaque chose a été laissée : ne le copiez pas dans des notes, la mémoire ou tout autre fichier.
5. Vérifiez l'écriture. Relisez le champ après l'avoir écrit et dites ce qui s'y trouve. Ne dites pas « sauvegardé » sans l'avoir vu.

Cette routine clôture la journée de travail, pas le chat. Si l'utilisateur est également sur le point d'archiver la conversation, c'est le travail d'une compétence de clôture de session, si elle est installée.

3. Revue hebdomadaire

1. Modèle. Si la page de calendrier a un modèle de revue, suivez ses sections dans l'ordre. Sinon, utilisez : ce qui a bien fonctionné, ce qui a bloqué et pourquoi, le statut de chaque domaine ou projet, trois priorités pour la semaine prochaine.
2. Remplissez ce que les sources disent : les tâches fermées cette semaine, les prochaines actions qui ont changé, les notes et les sessions de la semaine. Marquez tout ce que vous avez déduit comme un brouillon.
3. Demandez ce que seul l'utilisateur sait (pourquoi quelque chose a bloqué, comment la semaine s'est déroulée), le tout en une seule fois.
4. Collisions. Examinez les dates clés des trois prochaines semaines et les ressources partagées. Signalez chaque collision et indiquez exactement ce qui se chevauche. Ce qui doit être abandonné est la décision de l'utilisateur : ne le proposez pas, et ne proposez pas de réduire le nombre de projets à moins qu'il ne le demande.
5. Priorités. Si l'utilisateur demande une recommandation, donnez la vôtre avec sa raison, mais laissez la décision visiblement à lui.
6. Éléments en attente de révision sur la page de calendrier : mentionnez ceux qui sont maintenant dus.
7. Écrire avec approbation. Montrez la revue complète avant de l'écrire dans le gestionnaire de projet (en dupliquant le modèle, si c'est ainsi qu'il faut faire) et vérifiez ensuite qu'elle a bien été enregistrée.
8. Terminez par la liste de vérification de clôture du modèle, si elle en a une, point par point.

Règles pour les trois

• Le nombre de projets à gérer est la décision de l'utilisateur. Ne suggérez pas de se concentrer sur moins de projets, d'abandonner des domaines ou de « choisir une chose » à moins qu'il ne le demande.
• Pas de chiffres inventés. Les dates, délais, heures et progrès proviennent d'une source. Tout ce qui n'en a pas est marqué comme proposition ou laissé EN ATTENTE.
• Les objectifs sont fixés à partir des heures réelles dans le calendrier, pas de ce qui serait pratique.
• Pas de reproche. Pas de « tu aurais dû », pas de comparaisons et pas de ton de reproche, y compris pour les choses qui ont glissé.
• L'écriture nécessite une approbation, sauf si les instructions autorisent quelque chose à être écrit sans demander. La lecture, non.
• Une routine, une réponse courte. Elle doit pouvoir être lue en moins d'une minute. Si elle dépasse douze lignes, quelque chose peut être retiré.

Avec d'autres compétences

• Une compétence d'ouverture de session (comme resume-project) peut proposer le plan quotidien comme première option. Si elle vous passe la main, le contexte a déjà été lu : ne le relisez pas.
• Une compétence de sélection de compétences, si elle est installée, vient après, lorsque le plan se transforme en une tâche concrète en plusieurs étapes. Cette compétence ne choisit pas la tâche ; l'utilisateur le fait.
• Une compétence de clôture de session ferme le chat, pas la journée.

Sessions sans l'utilisateur

Dans une session programmée, produisez le plan quotidien et laissez-le en haut de votre travail. N'écrivez pas dans le gestionnaire de projet et n'exécutez pas la clôture de journée ou la revue hebdomadaire, qui nécessitent les réponses de l'utilisateur.

Mise en place

Pour que les routines fonctionnent au-delà d'un seul bloc, les instructions du projet de l'utilisateur (ou CLAUDE.md) doivent indiquer :

• où vivent le calendrier et les règles (une page, un fichier ou les instructions elles-mêmes), y compris les jours chômés et tout bloc qui vient toujours en premier ;
• où vivent les projets, et quel champ contient la prochaine action de chaque projet ;
• où vivent les tâches, si elles sont suivies séparément ;
• tout ce qui peut être écrit sans demander.

Si rien de tout cela n'existe encore, proposez une fois d'aider l'utilisateur à l'écrire, et continuez à travailler avec ce qui existe.

Style

Direct, sans répéter ce que l'utilisateur a dit. Quoi faire en premier, les raisons ensuite, et seulement si nécessaire.