aigengame/skills

État

Maintenez STATE.md à la racine du dépôt : un rapport quotidien cross-session léger permettant au prochain worker de savoir en ~15 lignes où en est le projet, ce que la dernière session a fait, quelle expérience immédiate réutiliser, par quoi continuer, et quels éléments non terminés ne doivent pas être oubliés. C'est la boucle de rétroaction qui fait que l'expérience de développement s'accumule au lieu de redécouvrir l'état du projet à chaque session.

STATE.md est transitoire (« où en sommes-nous / quoi faire ensuite », écrasé à chaque session) et autonome — ce n'est pas le lieu pour les décisions durables, l'architecture ou un glossaire, et il ne doit pas les dupliquer. Il est créé paresseusement : s'il n'existe pas encore, la première exécution le crée.

Lorsque le projet dispose d'une autorité de planification (un gestionnaire de tickets, des jalons), cette autorité détient le quoi du travail ; elle ne prescrit pas l'ordre ni la manière de l'exécution — les tickets sont exécutés en parallèle, un ticket s'étend sur plusieurs sessions, du travail inséré prime sur le travail planifié. STATE.md est le rapport d'exécution du worker : résultats, et l'orchestration actuelle du travail suivi (par quoi commencer ensuite, ce qui a été interrompu et mis de côté). Il enregistre l'état d'exécution ; il ne devient jamais une seconde autorité de planification.

Cette compétence est autonome et orthogonale à tout ce qu'un projet pourrait utiliser par ailleurs (gestion de versions, traceur de tickets/de tâches, documents de conception). Elle suppose que de tels outils peuvent exister mais ne dépend d'aucun en particulier — lisez les sources que le projet possède, ignorez le reste.

Écrivez avec parcimonie — omettez plutôt que d'induire en erreur. Chaque puce de contenu dans le modèle est facultative. La date de mise à jour est obligatoire à chaque réécriture du fichier. N'écrivez une ligne de contenu que lorsqu'elle est exacte et utile pour la session suivante. Si une valeur est manquante, obsolète, non vérifiée ou pas clairement utile, laissez-la de côté. Une ligne fausse ou de remplissage est pire qu'une ligne manquante. Le Backlog utilise une règle de suppression différente ; suivez l'étape 4.

Quand exécuter

• À la fin d'une session de travail / en wrap-up — votre runtime agent peut suggérer cela via un hook de fin de session, ou vous l'exécutez vous-même.
• À la demande, invoquez la compétence state en utilisant la syntaxe explicite de la compétence de l'hôte.

Le worker principal met à jour STATE.md une fois par session. Les sous-tâches parallèles et sous-agents ne le mettent pas à jour. Cette règle évite les écritures concurrentes ou en double.

Garde de non-opération : si la session n'a effectué aucun travail matériel (par exemple, un tour de questions-réponses trivial), laissez STATE.md inchangé — au maximum rafraîchissez la date. Ne modifiez pas le fichier pour un non-progrès.

Workflow

1. Rassemblez ce que cette session a réellement accompli ou changé. La source principale est la conversation en cours. Si le projet dispose d'outils de support, recoupez légèrement (historique récent du gestionnaire de versions, le traceur de tickets/tâches) — traitez-les comme facultatifs, non obligatoires.
2. Indiquez la phase macro seulement si vous connaissez la phase actuelle. Ne rapportez PAS la phase du précédent STATE.md par défaut — si elle a pu évoluer, ou si vous ne pouvez pas confirmer l'étape actuelle cette session, omettez la ligne plutôt que d'affirmer une phase obsolète. (Une phase terminée écrite comme si elle était actuelle est une désinformation.) Utilisez les propres termes du projet.
3. Sélectionnez le prochain travail recommandé — les éléments ouverts par lesquels une nouvelle session devrait commencer, dans l'ordre d'exécution. Promouvez les éléments du Backlog ici lorsqu'ils sont le bon prochain point de départ.
4. Conciliez le Backlog. Appliquez cet algorithme aux éléments cross-session non terminés :
   • Héritage par filtrage. Commencez avec le Backlog précédent et tout élément « Next up » qui n'a pas été exécuté. Supprimez un élément uniquement lorsque la preuve montre qu'il est terminé, obsolète, sélectionné pour « Next up », ou enregistré dans le traceur du projet. Une référence de traceur est la preuve que l'élément a un nouveau domicile. Vérifiez la conversation et recoupez avec le traceur s'il en existe un. Gardez l'élément lorsque son statut est incertain.
   • Rétrogradez le travail non terminé. Déplacez le travail déplacé vers le Backlog uniquement lorsqu'il n'est pas sélectionné pour « Next up ». Le travail qui doit reprendre à la session suivante appartient à « Next up ».
   • Stationnez le travail différé. Ajoutez un élément nouvellement accepté lorsqu'il est différé au-delà de la session suivante et n'a pas d'autre domicile.
   • Donnez à chaque élément un seul domicile. Placez-le dans « Next up » ou le Backlog, jamais les deux.
   • Estampez chaque élément du Backlog. Enregistrez sa date d'entrée sous depuis YYYY-MM-DD.
   • Appliquez le budget de cinq éléments. Lorsque le Backlog dépasse cinq éléments, ou qu'un élément est clairement substantiel, déplacez les éléments vers le traceur du projet du plus ancien au plus récent. Supprimez un élément uniquement après que le traceur fournit une référence. Si aucun traceur n'existe, gardez chaque élément. Gardez également chaque élément lorsque aucun rédacteur autorisé ne peut créer l'enregistrement du traceur. Le débordement visible est le signal que les éléments ont encore besoin d'un domicile durable.
5. Ajoutez de l'expérience seulement si elle sert « Next up ». Incluez une note uniquement lorsque le travail de cette session est continu ou lié au travail recommandé suivant, afin que la note soit effectivement réutilisée. Si le travail suivant n'est pas lié, omettez-la — l'expérience qui n'aide pas la tâche suivante est du bruit, pas une archive d'histoires de guerre. Lorsque le projet possède un PITFALLS.md, conservez-y les conseils durables sur l'environnement, les outils, les autorisations, les bacs à sable et l'invocation d'outils. STATE.md peut pointer vers une entrée pertinente ; il ne doit pas copier cette entrée.
6. Réécrivez STATE.md à partir du modèle. Écrasez le fichier ; n'ajoutez jamais. Gardez-le à 15 lignes ou moins. Si la règle de non-perte à l'étape 4 laisse plus de cinq éléments de Backlog, autorisez une ligne supplémentaire pour chaque élément supplémentaire. Ne supprimez pas un élément pour respecter la limite de lignes. Omettez les puces de contenu qui ne sont pas exactes et utiles. Réémettez le Backlog filtré dans le nouvel instantané. Estampez la date de mise à jour.
7. Ne committez pas automatiquement. Laissez simplement le STATE.md réécrit dans l'arbre de travail. Qu'il soit suivi ou conservé comme aide de travail locale est le choix du projet — cette compétence ne le commit jamais.

Modèle

# ÉTAT — <projet>

_Rapport quotidien cross-session (~15 lignes, réécrit à chaque session via la compétence `state`). Les décisions durables vivent ailleurs, pas ici._

- **Phase/jalon :** <étape actuelle, dans les propres termes du projet — omettre si vous ne pouvez pas confirmer l'étape *actuelle*>
- **Dernière session :** <ce qui a été accompli/changé ; une ligne, par ex. ticket n°N>
- **Expérience :** <expérience transitoire qui aide « Next up », ou un lien vers une entrée `PITFALLS.md` pertinente ; sinon omettre>
- **Next up :** <éléments recommandés pour COMMENCER ensuite, dans l'ordre d'exécution, par ex. ticket n°N>
- **Backlog :** <éléments cross-session non terminés NON sélectionnés pour « Next up » ; une ligne par élément>
  - <élément interrompu ou mis de côté, ancré à une référence de traceur (#N) s'il en existe une> _(depuis YYYY-MM-DD)_
  - <élément pas encore dans le traceur — promouvez-le là du plus ancien au plus récent lorsque la liste déborde> _(depuis YYYY-MM-DD)_

_Mis à jour : <YYYY-MM-DD>_

(Chaque puce de contenu est facultative. _Mis à jour est obligatoire à chaque réécriture du fichier.)

Garde-fous

• Suivez l'étape 4 pour chaque modification du Backlog. Ne supprimez jamais du travail non terminé pour respecter un budget.
• Suivez l'étape 6 pour les réécritures et les limites de lignes. STATE.md est un instantané actuel, pas un historique.
• Enregistrez uniquement le delta de cette session. Le Backlog est le seul champ qui porte l'état filtré vers l'avant.
• Gardez le fichier autonome. Ne dupliquez pas les décisions durables et ne dépendez pas d'un traceur ou d'un outil spécifique.
• Utilisez le vocabulaire établi du projet.