Workflow de Session Autonome

Que fait Workflow de Session Autonome ?

Une structure reproductible en 5 phases pour les sessions d'agents autonomes qui empêche le travail dupliqué, garantit la capture durable de l'apprentissage et maintient le biais de production vers des artefacts livrés significatifs plutôt que du simple mouvement.

Éprouvé sur des milliers de sessions autonomes basées sur l'architecture gptme. Les phases sont indépendantes de l'environnement d'exécution — adaptez les outils spécifiques à votre pile tout en conservant la structure des phases intacte.

Quand l'utiliser

• Au début de chaque session d'agent autonome (aucun humain ne dirige le travail en direct)
• Lorsque l'agent doit sélectionner son propre travail à partir d'un backlog ou d'une file d'attente
• Lorsque les sessions s'exécutent sans surveillance et doivent produire des artefacts durables

Quand ne pas l'utiliser

• Sessions interactives où un humain fournit la prochaine instruction à chaque tour — répondez simplement
• Invocations d'outils uniques avec un objectif fixe (aucune sélection nécessaire)
• Appels de sous-agents issus d'une tâche parente (le parent a déjà sélectionné le travail)

Les 5 Phases

Phase 1 : Chargement de Contexte

Chargez l'identité de l'agent, l'état de la session et le modèle de monde actuel.

# Lire les fichiers d'identité — personnalité, objectifs, contraintes de fonctionnement
# (adaptez à votre pile : CLAUDE.md, AGENTS.md, prompt système, etc.)

# Lire le contexte dynamique — journal récent, file de tâches, état git, notifications
# (adaptez : un script de contexte, une inclusion pilotée par configuration, ou une injection de prompt)

# Évaluer les points en suspens des sessions précédentes :
#   - Revendications obsolètes qui devraient être terminées ou abandonnées
#   - Réponses en attente sur des issues/PR que vous avez promis de clore
#   - Branches en cours ou worktrees ouverts

Question clé : « Qu'ai-je laissé inachevé et qu'est-ce qui a changé pendant que j'étais hors ligne ? »

Si un point en suspens peut être résolu en moins de 5 minutes, traitez-le ici. Sinon, notez-le et passez à la suite.

Phase 2 : Sélection de Travail

Essayez les niveaux dans l'ordre jusqu'à trouver un travail réalisable. Les niveaux empêchent l'agent d'inventer des tâches chronophages alors que de vraies tâches existent, et empêchent la famine lorsque toutes les tâches sont bloquées.

Niveau 1 — Tâches actives : travail déjà en cours ; priorité la plus élevée
Niveau 2 — Gains rapides du backlog : éléments prêts pour les dépendances que vous pouvez terminer cette session
Niveau 3 — Auto-amélioration : lorsque toutes les tâches sont bloquées de manière externe
  ├─ Backlog d'idées (avancez l'idée la mieux notée)
  ├─ Auto-révision / audit (trouvez et corrigez un vrai problème)
  ├─ Amélioration des outils internes
  ├─ Documentation (uniquement la documentation obsolète)
  ├─ Qualité du code (vérification de types, tests, lint)
  └─ Qualité des leçons (réparez les leçons nuisibles ou obsolètes)

Garde anti-monotonie : Si la même catégorie a dominé les N dernières sessions, ignorez-la même si elle semble être le meilleur choix. La diversité des catégories est une fonction de contrainte pour apprendre de nouveaux modes d'échec.

Quand tout est sec : Si toutes les tâches des Niveaux 1/2 sont bloquées de manière externe et que les voies du Niveau 3 sont saturées (limites quotidiennes atteintes), rédigez un court journal de retenue enregistrant ce que vous avez vérifié et délibérément sauté. Un NOOP justifié est préférable à fabriquer du travail.

Phase 3 : Revendication

Avant d'exécuter, acquérez une revendication de coordination exclusive. Cela empêche deux sessions concurrentes d'exécuter le même travail, d'inonder le même fil de discussion PR ou d'écrire le même fichier.

# Modèle de coordination générique — adaptez l'outil à votre pile :
claim_key="task:<task-id>"          # pour un travail basé sur une tâche
claim_key="github:<owner>/<repo>#<num>"  # pour un travail basé sur une issue
claim_key="content:<slug>:<date>"   # pour la création de contenu/artefact

# Acquérir une revendication (exemple à l'aide d'un CLI de coordination) :
coordination work-claim "<session-id>" "$claim_key" --ttl 60
# CLAIMED → procéder
# DENIED  → une autre session est déjà dessus ; choisissez le candidat suivant

Règle de notification avant revendication : Toute action visible par d'autres (publier un commentaire, envoyer un message, ouvrir une PR) doit d'abord être protégée par une revendication. Les actions sociales sans revendications convergent et génèrent du spam — un modèle revendiqué-puis-publié empêche l'inondation.

À la fin : coordination work-complete "<session-id>" "$claim_key" En cas de pivotement/échec : coordination work-abandon "<session-id>" "$claim_key"

Phase 4 : Exécution

Faites un vrai travail. La discipline clé est la livraison, pas la perfection.

- Commitez tôt et souvent (commits petits et bien décrits)
- Exécutez les tests avant de commiter (détectez les problèmes avant que CI ne le fasse)
- Utilisez les commits conventionnels : feat/fix/docs/refactor/chore
- Poussez vers l'origine avant la fin de la session
- Si bloqué pendant plus de 10 minutes, passez à autre chose — ne dilapidez pas le budget dans un terrier de lapin
- N'ajoutez pas de fonctionnalités non demandées ou de dérive de périmètre

Budget de 50 minutes : La plupart des sessions autonomes devraient terminer un travail significatif en 50 minutes. Si la tâche est plus grande, livrez une tranche incrémentale et créez une tâche de suivi pour le reste.

Phase 5 : Persistance

La phase la plus sous-estimée. Tout ce qui est fait dans les Phases 1 à 4 s'évapore entre les sessions à moins d'être durablement engagé.

# 1. Écrire l'entrée de journal (fichier spécifique à la session, ajout seulement)
cat > journal/$(date +%Y-%m-%d)/session-<HASH>.md << 'EOF'
# Session <HASH>
**Date** : AAAA-MM-JJ
**Résultat** : productif|bloqué|noop — une phrase
**Catégorie** : code|recherche|stratégique|maintenance|...

## Pourquoi ce travail
[Ce qui a conduit ici]

## Ce que j'ai fait
[Modifications concrètes avec liens de commit/PR]

## Vérification
- [Tests réussis ? CI vert ?]

## Apprentissage Persisté
- État de la tâche : <tâche> → terminé/en attente
- Nouvelles leçons : [le cas échéant]
- « Aucun retour durable cette session » — si rien de vraiment à ajouter

## Suite
[Prochaine action claire ou facteur bloquant]
EOF

# 2. Mettre à jour l'état de la tâche
task edit <task-id> --set state done   # ou en attente, si bloqué

# 3. Si un schéma d'échec récurrent a été découvert, écrire une leçon/règle
#    (fichier de contexte correspondant par mots-clés injecté au début de la session suivante)

# 4. Pousser tous les commits
git push origin master

Règle de persistance d'abord : Si vous avez découvert quelque chose d'utile, écrivez la leçon AVANT de l'appliquer au travail en cours. Une fois le correctif en place, le mode d'échec semble résolu et la leçon est ignorée. Le journal capture ce qui s'est passé ; la leçon capture quand le reconnaître à nouveau.

Installation

Claude Code

Copiez ce répertoire de compétence dans le dossier de compétences de votre agent :

cp -R skills/autonomous-session-workflow ~/.claude/skills/autonomous-session-workflow

Puis invoquez avec /autonomous-session-workflow pour charger la liste de contrôle en 5 phases dans le contexte.

Manuel / tout environnement d'exécution

Copiez SKILL.md dans le chemin de contexte de votre agent et chargez-le au début de la session. Les phases sont en markdown simple — incluez tout le fichier ou choisissez les sections pertinentes pour votre pile.

Rationalisations Courantes

Rationalisation	Réalité
« Je vais sauter la revendication — je suis la seule session qui tourne en ce moment »	Vous ne pouvez pas voir les autres sessions se lancer. Le déclenchement concurrent est la valeur par défaut sur les environnements d'exécution de production. La revendication est la barrière, pas l'observation.
« J'écrirai le journal après avoir terminé la prochaine tâche »	Les sessions sont interrompues. Le journal est sauté. Écrivez-le avant de pousser, pas après « une dernière chose ».
« Cette tâche est presque terminée — je vais sauter la Phase 5 et juste commiter »	L'apprentissage ne se cumule que s'il est persisté. La session qui a « presque » bouclé la boucle est celle dont la perspicacité disparaît à la prochaine exécution.
« Ma sélection est évidente — je n'ai pas besoin de parcourir les niveaux »	La sélection qui saute les niveaux est la principale source de travail redondant et de PR en double. Les niveaux existent parce que « l'évidence » n'est souvent pas ce qui doit réellement être fait.
« La leçon est trop spécifique pour être réutilisable »	Les leçons spécifiques (message d'erreur exact, commande exacte, mode d'échec exact) sont les plus précieuses — elles se déclenchent précisément quand nécessaire.
« Un NOOP justifié ressemble à un échec »	Ce n'est pas le cas. Un commit de remplissage pour éviter l'étiquette NOOP brûle du quota, alimente le churn de convergence et cache le blocage. Un journal de retenue EST la livraison.

Drapeaux Rouges

• Commencer l'exécution avant la revendication (risque de convergence)
• Session se terminant sans journal et sans état de tâche mis à jour
• Commiter « dans un instant » — si vous n'avez pas poussé avant de terminer, vous n'avez rien livré
• Trois sessions consécutives dans la même catégorie sans pause de diversité forcée
• « Je m'en souviendrai » — non, ce ne sera pas le cas ; écrivez la leçon maintenant

Vérification

Une session bien exécutée satisfait tous ces points avant de se fermer :

• Revendication acquise avant d'agir (ou justification expliquant pourquoi aucune revendication n'était nécessaire)
• Travail significatif commité et poussé
• Tests réussis (ou échec connu documenté avec raison)
• Entrée de journal écrite avec la section Apprentissage Persisté remplie
• État de la tâche mis à jour (active → done, active → waiting, etc.)
• Revendication terminée ou abandonnée (pas laissée comme bail en suspens)

Adaptation à Votre Pile

Concept gptme	Votre équivalent
gptodo	tout gestionnaire de tâches avec transitions d'état
coordination work-claim	un fichier de verrouillage, Redis SETNX, ou une barrière de commentaire GitHub
lessons/<category>/name.md	tout fichier de contexte correspondant par mots-clés injecté au début de la session
journal/<date>/session-<hash>.md	tout journal de session en ajout seulement
cascade-selector.py	votre heuristique de sélection de travail ou planificateur

Le modèle est la valeur, pas les outils spécifiques.

Connexes

• self-push (dans ce catalogue) — vérification paresseuse avant de livrer toute sortie
• pre-landing-review (dans ce catalogue) — barrière avant de fusionner des changements significatifs
• multi-lens-review (dans ce catalogue) — révision structurée de PR sous plusieurs angles
• five-element-spec (dans ce catalogue) — définition du périmètre avant de commencer le travail