DigiAye/agent-skills

assemble

Quatre modèles, une réponse, plusieurs tours. Chaque tour lit la meilleure réponse actuelle, la critique depuis un rôle donné, et écrit une version améliorée. La progression est stockée dans des fichiers, pas dans la conversation, donc chaque tour démarre avec un contexte frais (la technique Ralph Wiggum).

Commandes

Commande	Action
assemble <tâche>	Démarrer une session avec le calendrier par défaut (36 tours).
assemble --quick <tâche>	Un seul bloc de 2 passes x 4 modèles (8 tours).
assemble resume [<slug>]	Continuer la session inachevée la plus récente (ou nommée).
assemble cancel [<slug>]	Mettre status: cancelled dans le fichier d'état et arrêter.
assemble status	Afficher l'itération, le bloc, les éléments MUST ouverts et les modèles utilisés.

Avant de commencer

1. Charger .assemble/config.json s'il existe, sinon assets/config.example.json.
2. Choisir l'adaptateur de modèle (voir ci-dessous) et indiquer à l'utilisateur quels quatre modèles seront exécutés, et où le texte de la tâche sera envoyé. Si un modèle est en dehors de allowedModels, ou si localOnly est vrai et qu'un modèle est distant, le retirer et le signaler.
3. Reformuler la tâche et les critères d'acceptation en un court paragraphe. Si la tâche n'est pas claire, demander à l'utilisateur avant de dépenser des tours.
4. Créer .assemble/<slug>/ avec task.md, answer.md (vide), et state.md comme décrit dans references/state-format.md. S'assurer que .assemble/ est dans .gitignore.

Le calendrier

Un tour est un passage de modèle. Une passe est le passage des quatre modèles chacun à leur tour, dans l'ordre.

Bloc	Passes	Tours	Total cumulé
1	4	16	16
2	3	12	28
3	2	8	36

Après le tour 36, afficher le rapport et demander à l'utilisateur s'il souhaite exécuter un autre bloc. Ne jamais dépasser 36 tours sans demander.

Les rôles tournent à chaque passe pour que chaque modèle joue chaque rôle : dans la passe p (base 0), le modèle m joue roles[(m + p) % 4] depuis references/roles.md.

Chaque tour

Construire l'invite du tour uniquement à partir des fichiers, en utilisant references/handoff-format.md :

• task.md
• la answer.md actuelle
• la critique du tour précédent (depuis le dernier round-NN.md)
• la carte de rôle pour ce tour

N'inclure ni les tours précédents, ni le modèle qui a écrit la réponse actuelle. Ensuite :

1. Envoyer l'invite au modèle de ce tour en utilisant l'adaptateur choisi.
2. Analyser la réponse en une critique (chaque problème étiqueté MUST ou NICE), une réponse révisée et un verdict.
3. Si la tâche est du code et que des checks sont configurés, appliquer la réponse révisée dans une copie temporaire, exécuter les vérifications, et ajouter les échecs à la critique comme éléments MUST.
4. Écrire round-NN.md (rôle, identifiant du modèle, critique, résultats des vérifications, verdict, taille du diff de lignes) et écraser answer.md avec la réponse révisée.
5. Mettre à jour state.md : itération, bloc, passe, nombre de MUST ouverts et la séquence sans changement.
6. Donner à l'utilisateur une note de progression d'une ligne : Tour 7/36 · sceptique · 2 MUST, 1 NICE · diff 14 lignes.

Si un modèle génère une erreur ou expire, le journaliser dans round-NN.md, sauter le tour et continuer. Si deux modèles échouent consécutivement, faire une pause et en informer l'utilisateur.

Arrêt

Un tour est considéré comme sans changement lorsqu'il ne soulève aucun élément MUST et modifie moins de noChangeLines lignes de answer.md.

Arrêter prématurément lorsque :

• quatre tours consécutifs (une passe complète) sont sans changement, ou
• un tour se termine par <promise>CONVERGED</promise> et le tour suivant confirme sans aucun élément MUST.

Si le nombre de MUST ouverts n'a pas diminué pendant un bloc entier, arrêter et écrire une courte note de « blocage » : ce qui bloque, ce qui a été essayé, et ce que l'utilisateur pourrait décider pour débloquer.

Rapport

Lorsque la session se termine, écrire .assemble/<slug>/report.md et l'afficher :

• la réponse finale
• les tours effectués et la raison de l'arrêt
• les principaux changements dans chaque bloc
• les éléments NICE ouverts
• les modèles utilisés, avec les échecs
• une estimation approximative des tokens et du coût (somme des tailles d'invite et de réponse, multipliée par les prix du config s'ils sont fournis)

Adaptateurs de modèles

Utiliser le premier disponible, et indiquer à l'utilisateur lequel a été choisi.

1. Sous-agents internes. Si l'hôte peut lancer des sous-agents et choisir leur modèle, en utiliser un par tour. Cursor peut mélanger les fournisseurs. Claude Code et Kiro n'offrent ici que des modèles Claude, donc les quatre seront des variantes de Claude.
2. CLIs de fournisseurs. Exécuter scripts/run-model.sh <id-modèle> <fichier-invite> une fois par tour. C'est l'option multi-fournisseur réelle. Vérifier que chaque CLI existe (command -v) avant le début de la session.
3. Modèle unique. Exécuter chaque tour soi-même, en jouant le rôle de ce tour. Lire uniquement les fichiers du tour, et traiter chaque tour comme un nouveau départ.

Des aides optionnelles spécifiques à l'outil, comme un hook d'arrêt pour Claude Code en mode non supervisé, se trouvent dans le dossier adapters/ du dépôt.