Agents de codage parallèles avec tmux et spécifications en Markdown

Manuel Schipper exécute des agents de codage en parallèle avec une configuration légère utilisant tmux, des fichiers Markdown, des alias bash et six commandes slash. Ce sont des agents standards sans profils de sous-agents ou orchestrateurs, utilisant une convention de nommage de rôle par fenêtre tmux : Planificateur (construit les spécifications Markdown), Travailleur (implémente à partir des spécifications terminées) et Chef de Projet (tri du backlog et déversement d'idées).

Système de Conception de Fonctionnalités

La plupart de l'écriture de code se fait à partir de spécifications terminées appelées Feature Designs (FD). Un FD est un fichier Markdown contenant :

• Le problème à résoudre
• Toutes les solutions envisagées avec les avantages et inconvénients de chacune
• La solution finale avec le plan d'implémentation incluant les fichiers à mettre à jour
• Les étapes de vérification

Après avoir adopté ce système, Schipper peut travailler en parallèle avec 4 à 8 agents. Au-delà de 8 agents, la qualité des décisions se dégrade. Le système a été construit manuellement dans un projet avec 300+ spécifications, puis porté vers de nouveaux projets en utilisant une commande /fd-init qui initialise la configuration dans n'importe quel dépôt.

Suivi et Cycle de Vie des FD

Chaque FD obtient un fichier de spécification numéroté (FD-001, FD-002...) suivi dans un index couvrant tous les FD. Les fichiers se trouvent dans docs/features/ et passent par 8 étapes :

• Planifié : Identifié, pas encore conçu
• Conception : En train de concevoir la solution
• Ouvert : Conçu, prêt pour l'implémentation
• En Cours : Actuellement en cours d'implémentation
• En Attente de Vérification : Code terminé, en attente de vérification en exécution
• Terminé : Vérifié fonctionnel, prêt à archiver
• Reporté : Reporté indéfiniment
• Fermé : Ne sera pas fait

Commandes Slash

Six commandes slash gèrent le cycle de vie complet :

• /fd-new : Créer un nouveau FD à partir d'un déversement d'idées
• /fd-status : Afficher l'index : ce qui est actif, en attente de vérification et terminé
• /fd-explore : Initialiser une session : charger la documentation d'architecture, le guide de développement, l'index des FD
• /fd-deep : Lancer 4 agents Opus en parallèle pour explorer un problème de conception difficile
• /fd-verify : Relire le code, proposer un plan de vérification, commiter
• /fd-close : Archiver le FD, mettre à jour l'index, mettre à jour le journal des modifications

Chaque commit est lié à son FD (par exemple, "FD-049 : Implémenter la reconstruction incrémentale de l'index"). Le journal des modifications s'accumule automatiquement au fur et à mesure que les FD se terminent.

Exemple de Fichier FD

FD-051 : Classification de documents multi-étiquettes
Statut : Ouvert
Priorité : Moyenne
Effort : Moyen
Impact : Meilleur rappel pour le filtrage en aval

Problème
Les documents entrants reçoivent une seule étiquette de catégorie, mais beaucoup couvrent plusieurs sujets. Les filtres en aval manquent des documents pertinents car le classificateur impose un seul meilleur ajustement.
Solution
Remplacer la classification à étiquette unique par une classification multi-étiquettes :

Utiliser un LLM pour attribuer des scores de confiance par catégorie.
Accepter toutes les étiquettes avec une confiance supérieure à 0,90.
Pour les scores ambigus (0,50-0,90), exécuter un deuxième passage LLM avec des exemples few-shot pour confirmer.
Stocker toutes les étiquettes avec leurs scores afin que les requêtes en aval puissent définir un seuil flexible.

Fichiers à Modifier

src/classify/multi_label.py (nouveau : logique multi-étiquettes basée sur LLM)
src/classify/prompts.py (nouveau : modèles few-shot pour les cas ambigus)
sql/01_schema.sql (ajouter la table document_labels avec les scores)
sql/06_classify_job.sql (nouveau : classification planifiée après ingestion)

Vérification

Exécuter le classificateur sur la table de documents de staging
Vérifier qu'il n'y a pas d'erreurs dans le journal d'opération, exécuter les contrôles de santé
Vérification ponctuelle : les documents avec un contenu multi-sujets connu ont les étiquettes attendues
Exécuter les tests, confirmer que les filtres en aval respectent le seuil de confiance

Initialisation du Système

Exécuter /fd-init dans n'importe quel dépôt :

• Infère le contexte du projet à partir de CLAUDE.md, des configurations de paquets et du journal git
• Crée la structure de répertoires (docs/features/, docs/features/archive/)
• Génère un FEATURE_INDEX.md personnalisé pour le projet
• Crée un modèle de FD
• Installe les six commandes slash
• Ajoute les conventions du cycle de vie des FD au CLAUDE.md du projet

Les fichiers créés incluent docs/features/FEATURE_INDEX.md (index des fonctionnalités), docs/features/TEMPLATE.md (modèle de fichier FD), docs/features/archive/ (répertoire d'archive), CHANGELOG.md (format Keep a Changelog), et des mises à jour de CLAUDE.md avec les conventions du projet incluant le système FD.