Planning with Files est un skill pour agents créé par Ahmad Adi qui conserve le plan, les résultats de recherche et l’avancement d’une tâche dans les fichiers du projet. Utilisez-le lorsqu’une tâche de développement ou de recherche dure assez longtemps pour qu’une nouvelle conversation doive reconstituer les décisions antérieures. Ces fichiers fournissent à l’agent un historique qu’il peut lire et mettre à jour ; leur utilité dépend de leur exactitude.
Le point de départ pratique est constitué de trois fichiers Markdown : task_plan.md, findings.md et progress.md. Donnez à chacun une fonction distincte. Le plan suit le travail restant, les résultats de recherche expliquent ce qui a été appris, et le suivi d’avancement consigne ce qui s’est réellement passé. Copier le même paragraphe dans les trois complique la reprise.
Exemple fictif de planification Apple ; les retours cités et les pourcentages sont donnés à titre d’illustration. Ouvrir l’illustration en pleine taille.
Installer le dossier complet du skill
La page du skill Thrive Planning with Files fournit la source de l’éditeur examinée. Installez-le dans votre projet :
npx usethrive add planning-with-files --agent claudePour Codex, remplacez --agent claude par --agent codex. Le programme d’installation copie le dossier complet du skill épinglé, avec les modèles et les scripts. Il laisse les installations existantes intactes ; examinez donc une copie installée avant de la remplacer.
Installer un skill et installer un plugin dans un environnement sont deux opérations différentes. L’éditeur fournit aussi des intégrations pour les hooks de cycle de vie et la reprise des tâches. Copier un dossier n’enregistre pas automatiquement tous les hooks propres aux plugins de chaque environnement. Si vous souhaitez ces intégrations, suivez la documentation d’installation de l’éditeur pour votre agent et votre système d’exploitation.
Séparez le skill installé des fichiers de planification du projet. Le dossier installé contient les scripts et modèles réutilisables. Le répertoire de la tâche contient les traces du travail en cours. La procédure actuelle de l’éditeur peut sélectionner un répertoire de tâche ; si ce mode est activé, utilisez son outil d’initialisation et l’identifiant de tâche affiché au lieu de supposer que chaque tâche écrit à la racine du projet.
Donner à chaque fichier une fonction utile
Fichier | À y consigner | À éviter |
|---|---|---|
| L’objectif, les phases, les critères d’acceptation et la prochaine action | La transcription de tous les appels d’outils |
| Les éléments probants, les liens sources, les contraintes et les raisons des décisions | Une conclusion non étayée présentée comme un fait |
| Les étapes terminées, les résultats réels des tests et les échecs non résolus | Des contrôles prévus présentés comme terminés |
Pour une courte modification, ces fichiers peuvent demander plus de travail qu’ils n’en épargnent. Corriger un titre nécessite rarement un système de reprise. Une migration, une enquête à partir de plusieurs sources ou une fonctionnalité comportant plusieurs dépendances s’y prêtent mieux, car l’action suivante dépend des éléments recueillis auparavant.
Exemple : planifier une petite migration de contenu
Supposons que vous transfériez les archives d’une newsletter dans un CMS. Vous devez faire correspondre les titres, les dates, les tags et le contenu sans publier les brouillons privés. Commencez par un plan qui définit le résultat et les contrôles :
# Newsletter archive migration
## Objective
Import the approved public archive and preserve draft visibility.
## Phases
- [ ] Inventory source records and classify their visibility.
- [ ] Map source fields to the target content model.
- [ ] Import a small sample and check formatting.
- [ ] Import the approved remaining records.
- [ ] Verify counts, visibility, and representative links.
## Acceptance criteria
- Source and imported approved-record counts match.
- Draft records have no public snapshot.
- Sample links, headings, and publication dates are preserved.
## Next step
Inspect five representative source records before writing the mapper.Cet exemple est un modèle de planification, pas une affirmation qu’une migration a été effectuée. Remplacez ses contrôles par ceux qu’exigent vos systèmes source et cible. Si une correspondance demande une décision de l’éditeur, consignez cette dépendance au lieu de laisser l’agent deviner.
Dans findings.md, expliquez une décision de correspondance avec des éléments probants. Par exemple, « L’export contient published_at uniquement pour les entrées publiées ; conserver une valeur absente pour les brouillons » est utile si vous l’avez observé dans l’export. Consignez le fichier examiné et les champs concernés. N’écrivez pas cette conclusion simplement parce qu’elle semble plausible pour un CMS.
Dans progress.md, consignez le résultat réel de l’échantillon. « Cinq enregistrements importés ; une vidéo intégrée nécessite une règle de conversion distincte » indique à la session suivante ce qui reste à faire. « La migration semble bonne » ne fournit pas assez d’informations pour poursuivre sans risque.
Reprendre après une réinitialisation du contexte
Demandez à l’agent de lire les trois fichiers de la tâche sélectionnée et d’indiquer la phase actuelle, les décisions non résolues et la prochaine action avant toute modification. Comparez ce compte rendu au dépôt et aux systèmes externes utilisés par la tâche. Une case cochée dans Markdown peut être périmée ; l’agent doit vérifier le livrable concerné avant de s’y fier.
Si le plan indique que les tests ont réussi, le suivi d’avancement doit préciser la commande et le résultat. S’il indique qu’un déploiement est terminé, conservez son identifiant ou son URL. Ne placez pas de secrets dans ces fichiers, surtout si le dépôt est partagé. Consignez les noms des identifiants et les conditions d’accès plutôt que de copier des tokens.
L’éditeur inclut des outils de reprise de session avec des modes explicites. Utilisez le mode adapté à la tâche et à l’environnement. L’accès à un répertoire de projet n’autorise pas la collecte d’historiques de conversations locales sans rapport avec lui. Un plan de projet suffit souvent à retrouver le contexte utile de la tâche.
Éviter les plans périmés et les modifications concurrentes
Mettez le plan à jour lorsqu’une phase change et formulez l’étape suivante avec un verbe concret : examiner, comparer, réaliser ou vérifier. Une instruction vague telle que « poursuivre le développement » oblige une nouvelle session à reconstituer la décision.
Lorsque plusieurs agents participent, désignez un responsable unique du plan partagé. Les autres peuvent rendre compte dans les fichiers qui leur sont attribués ou par message. Cela facilite la mise en relation d’une tâche terminée avec un échec découvert ensuite. Des agents indépendants qui réécrivent le même document de suivi peuvent masquer involontairement le travail des autres.
Avant de clôturer la tâche, vérifiez le résultat au regard des critères d’acceptation. Laissez les points non résolus visibles. Planning with Files améliore la continuité du travail d’un agent ; le fait que son script de clôture accepte un plan ne suffit pas à établir que le résultat est correct.
Par quoi commencer
Installez le skill pour une tâche dont vous prévoyez déjà qu’elle prendra plusieurs sessions. Commencez par un objectif bref, quelques phases et une prochaine action vérifiable. Après la première session, ouvrez vous-même les fichiers et vérifiez si une autre personne pourrait reprendre le travail. Les décisions absentes ou les entrées de suivi vagues montrent ce qu’il faut améliorer avant que la tâche ne prenne de l’ampleur.
Pour les méthodes de travail qui produisent aussi des notes de recherche, consultez le skill Obsidian Markdown. Séparez les traces d’exécution du projet et les notes de référence personnelles lorsqu’elles ont des responsables ou des exigences de confidentialité différents.
