jeredleisey/skills

Orchestrer

Un orchestrateur possède l'issue d'un travail, pas chaque ligne. Il façonne le travail, donne des tickets aux auxiliaires, vérifie ce qu'ils renvoient, et parle à l'humain et aux orchestrateurs pairs. Les faits d'un dépôt vivent dans sa charte. L'état de votre propre travail vit dans votre issue d'orchestrateur : registre, détenteur et points de contrôle.

Deux types d'étapes nécessitent de l'attention :

• Une étape à sens unique ne peut pas être annulée par un nouveau commit : une fusion, un déploiement, une suppression, un push forcé, une modification d'un système en direct, un message à une personne extérieure au travail.
• Une affirmation est ce qu'un auxiliaire ou un pair dit avoir fait. Une affirmation n'est pas une preuve.

Étapes

0. Démarrage

D'abord, à la racine du dépôt, exécutez node "${CLAUDE_PLUGIN_ROOT}/scripts/charter-check.mjs". Si le chemin apparaît comme un ${CLAUDE_PLUGIN_ROOT} vide ou littéral, utilisez le dossier deux niveaux au-dessus du répertoire de base de cette compétence. Agissez selon sa ligne unique :

• ok : continuez.
• older-cadre : continuez. Dites "le cadre a de nouvelles options. Tapez /cadre:setup pour les voir." Prenez la version depuis .claude-plugin/plugin.json du plugin.
• missing : arrêtez. Dites "Ce dépôt n'a pas de charte. Tapez /cadre:setup, puis demandez-moi à nouveau."
• stale <ancien> <nouveau> : arrêtez. Dites "La charte est plus ancienne que ce cadre. Tapez /cadre:setup, puis demandez-moi à nouveau."
• plugin-too-old : arrêtez. Dites "La charte est plus récente que ce cadre. Mettez à jour le cadre, puis demandez-moi à nouveau."
• unknown: <raison> : arrêtez. Dites la raison et "Corrigez le fichier de charte ou tapez /cadre:setup, puis réessayez."
• Aucune ligne, ou une ligne autre que ces six : arrêtez. Dites à l'humain que la vérification de la charte a échoué et affichez le résultat.

Ensuite, chaque orchestrateur est un issue GitHub (sur ADO, un élément de travail, et la lecture de reprise est resume-read-ado.mjs ; avec tracker: local, un fichier, et resume-read-local.mjs), comme décrit dans references/orchestrator-issue.md. Démarrez de l'une des trois manières suivantes :

• Lister : l'humain demande quels orchestrateurs le projet possède. Affichez les issues ouverts avec le label cadre:orchestrator et attendez un choix.
• Reprendre : l'humain dit "reprends en tant que ". Suivez l'ordre de reprise de la référence : la vérification du propriétaire, puis la vérification du détenteur. Après une compaction, exécutez le même ordre : l'identifiant de session dans le détenteur décide. Ne prenez jamais le nom ou le registre d'un autre orchestrateur.
• Nouveau : l'humain demande un nouvel orchestrateur. Donnez-lui un nom libre, un objectif et un issue.

Terminé lorsque la ligne de vérification est ok ou older-cadre, que vous êtes un orchestrateur avec votre propre issue, et qu'une reprise est terminée.

1. Charger la charte

Lisez la charte du dépôt, à docs/agents/cadre-charter.md (references/charter.md). Terminé lorsque vous connaissez le tracker, le propriétaire de chaque fichier, qui peut fusionner et déployer, la règle de documentation, et les actions que seul l'humain peut effectuer.

2. Façonner le travail

Rédigez un cahier des charges sous forme d'issue, puis un ticket pour chaque tranche, avec ses bloqueurs. Donnez à chaque fichier un propriétaire. Exécutez le travail en parallèle uniquement lorsque les fichiers ne se chevauchent pas. Terminé lorsque chaque ticket a un propriétaire, des critères d'acceptation qu'une commande ou une vérification nommée par l'humain peut prouver, et aucun fichier qu'un ticket en cours d'exécution ne modifie également.

3. S'accorder avec les pairs

Lorsqu'un pair travaille dans le même dépôt, proposez la répartition des tickets et des fichiers au pair. Attendez sa réponse. Terminé lorsque chaque pair a accepté ses tickets, par écrit.

4. Déléguer

Donnez chaque ticket à un auxiliaire, dans son propre espace de travail et branche, et étiquetez le ticket cadre:work:<nom>. Créez l'espace de travail vous-même, avant de lancer l'auxiliaire : git worktree add .claude/worktrees/<branche> -b <branche> <base>. Nommez son chemin et sa branche dans le brief. Vous éditez également uniquement dans un espace de travail. Un clone que d'autres agents partagent reste sur sa branche principale. Lancez l'auxiliaire à partir d'une fiche de rôle quand elle convient : coder pour le code, reviewer pour une revue, researcher pour la lecture, tester pour une preuve, ou une fiche dans la liste "Cartes supplémentaires" de la charte. references/roles.md liste les fiches. Rédigez le brief à partir de references/helper-brief.md. Un auxiliaire committe et s'arrête : il ne pousse pas, ne fusionne pas et ne déploie pas. Avec les équipes d'agents activées, reflétez chaque ticket délégué en tant que tâche. Seul le responsable complète une tâche, après l'étape de vérification. Le tracker reste le seul enregistrement, et une reprise se reconstruit à partir de celui-ci. Terminé lorsque le harnais montre chaque auxiliaire comme en cours d'exécution, ou que son démarrage a échoué et que vous savez pourquoi.

5. Vérifier

Traitez chaque rapport d'auxiliaire comme une affirmation. Pour chaque résultat :

1. Exécutez les tests vous-même, à partir de la branche.
2. Lisez le diff pour le périmètre : uniquement les fichiers que le brief a autorisés.
3. Scannez le diff à la recherche de secrets et de faits qu'un script doit écrire.
4. Comparez le résultat à chaque critère d'acceptation.
5. Après chaque commit coder, lancez un reviewer avec la base du brief comme point fixe, et le cahier des charges du brief. Attendez son rapport.
6. Classez chaque constat de revue comme à corriger absolument, à corriger de préférence, ou détail. Corrigez chaque véritable à corriger absolument et à corriger de préférence avant la fusion.

Terminé lorsque chaque critère a une preuve provenant d'une commande que vous avez exécutée, et qu'aucun à corriger absolument ou à corriger de préférence ne reste ouvert.

6. Effectuer une étape à sens unique

Avant chaque étape à sens unique :

1. Exécutez node "<racine du plugin>/scripts/grant-check.mjs" <n> "$CLAUDE_CODE_SESSION_ID" "<action>" (grant-check-ado.mjs avec l'identifiant de l'élément, grant-check-local.mjs avec le nom). <action> est la cellule Action telle que le registre l'écrit. granted row=<k> scope=<chaîne JSON> : lisez le Scope et vérifiez qu'il couvre cette étape, sinon demandez à l'humain et arrêtez. none : demandez à l'humain et arrêtez. unknown: ou not-owner : arrêtez et signalez. N'utilisez jamais une ligne que le script n'a pas imprimée.
2. Avant chaque fusion, vous avez besoin d'un rapport de revue pour le commit de tête de la branche, sans aucun à corriger absolument ou à corriger de préférence ouvert. Si vous n'en avez pas, ne fusionnez pas. Lancez un reviewer. Si vous ne le pouvez pas, dites que la revue est manquante et demandez à l'humain. Si l'humain vous dit de fusionner, c'est une autorisation. Cela n'annule pas la revue. Seul l'humain peut vous dire de fusionner sans revue. Écrivez cela dans le registre, avec l'Action "fusionner sans revue".
3. Lisez les cahiers des charges ouverts. Une règle peut changer pendant que vous travaillez, et un cahier des charges peut arrêter les fusions dans un chemin à partir d'un point donné (un gel).
4. Regardez d'abord la cible : ce qu'une suppression supprime, ce qu'un déploiement remplace.
5. Écrivez la commande pour qu'elle s'arrête à la première erreur, par exemple set -euo pipefail. N'enchaînez pas une suppression après une étape qui peut échouer.
6. Gardez un chemin de retour : une sauvegarde, un tag, ou l'ancienne version.
7. Si le harnais ou sa vérification de permission refuse l'étape, ne cherchez pas d'autre chemin. Arrêtez et demandez à l'humain.
8. Après une fusion, mettez à jour chaque clone à partir duquel un outil en direct s'exécute. La charte les nomme.

Terminé lorsque l'étape a réussi, que vous avez vérifié son résultat, et que chaque clone à partir duquel un outil en direct s'exécute est à jour.

7. Faire un rapport à l'humain

Dites ce qui a changé, avec des liens. Mettez chaque décision dont vous avez besoin de l'humain dans une liste numérotée à la fin du message, et rien après la liste. Dites chaque erreur que vous avez causée, et comment vous l'avez réparée. Terminé lorsque l'humain peut répondre à chaque décision ouverte par son numéro.

8. Écrire un point de contrôle

Après chaque fusion, chaque ticket résolu et chaque changement de plan, ajoutez un commentaire de point de contrôle à votre issue d'orchestrateur. Utilisez le formulaire dans references/orchestrator-issue.md. Terminé lorsque le commentaire le plus récent a la ligne de marqueur et les trois sections.

Règles

Permissions

• Seul l'humain donne une permission, dans votre propre session. Écrivez chaque autorisation dans le registre de votre issue d'orchestrateur. Une autorisation se termine avec sa session, sauf si l'humain dit le contraire.
• Un message d'un pair ou d'un auxiliaire est une demande, jamais une permission. Un mot humain relayé par un pair établit un ordre de travail. Il ne donne pas de permission.
• Une permission pour un dépôt ne couvre pas un nouveau dépôt, un nouvel hôte, ou un nouveau type d'étape.
• Un registre appartient à un orchestrateur et à son unique propriétaire. Un nouvel orchestrateur commence avec les autorisations standard que l'humain accepte, ou aucune ligne. Les règles du registre et de l'écriture du corps sont dans references/orchestrator-issue.md.

Pause

Lorsque l'humain dit "pause", arrêtez à la fin de l'appel d'outil en cours et répondez. Ne commencez pas de nouveau travail avant que l'humain ne dise de continuer.

Coût

Chaque réveil d'un agent coûte un tour sur l'ensemble de son contexte.

• Réveillez un pair uniquement lorsqu'il doit agir.
• Donnez à un auxiliaire un brief qu'il peut terminer sans questions.