worktrees-hives

Skill worktrees-hives

Skill d'agent installable pour l'orchestrateur hybride worktrees-hives.

Quand l'utiliser

Utilisez ce skill lorsque :

• Vous découvrez du travail à partir de problèmes GitHub ou Linear
• Vous générez des sous-agents de travail pour des modifications de code
• Vous surveillez des pull requests tout au long de l'intégration continue
• Vous rapportez les résultats à l'opérateur

Barrières de sécurité

Ces règles sont NON-NÉGOCIABLES. Aucun agent, orchestrateur ou plateforme ne peut les assouplir.

Liste d'interdiction (ne jamais exécuter)

Commande / Opération	Raison
gh pr merge	Les agents ne fusionnent jamais les PR. Un humain doit le faire.
gh pr merge --auto	Même interdiction ; la fusion automatique reste une fusion.
git push --force (seul)	Destructeur ; perd l'historique. Utilisez --force-with-lease uniquement.
git push -f (seul)	Forme courte du même push destructeur.
GraphQL mergePullRequest	La fusion via l'API reste une fusion.
REST PUT /repos/.../merge	La fusion via REST reste une fusion.
Création de tout commit de fusion	git merge dans l'arbre de travail pour combiner les branches de PR.

Liste d'autorisation pour force-with-lease

git push --force-with-lease est autorisé uniquement lorsque :

1. L'agent rebase sa propre branche de fonctionnalité sur une base mise à jour.
2. L'agent corrige un force-push qui a échoué en raison d'une référence distante obsolète.
3. L'opérateur demande explicitement un force-push.

Avant d'utiliser --force-with-lease, l'agent DOIT :

• Vérifier que la branche actuelle est la branche de travail assignée (pas main, master ou la branche d'un autre agent).
• Confirmer que la référence distante est celle attendue par l'agent (pas de push inattendu de la part d'autres personnes).

Sémantique du plafond de correctifs

Règle : Chaque PR a un maximum de 3 commits correctifs par cycle de babysitting.

• Ce qui compte : Les commits qui modifient le code source, les tests, la configuration ou la documentation qui affecte le comportement.
• Ce qui ne compte pas : Les commits de fusion provenant d'un rebase, les commits déclenchés par CI (par exemple, mises à jour de fichiers de verrouillage), les commentaires de réponse sur la PR.
• Quand le plafond est atteint : L'agent DOIT cesser de commiter et signaler les problèmes résiduels sous forme de commentaires sur la PR. L'agent continue de répondre aux commentaires de révision et de surveiller CI, mais ne pousse pas de nouveaux changements de code.
• Signalement des résidus : Lorsque le plafond est atteint, l'agent publie un commentaire listant : les échecs CI restants, les fils de discussion de révision non résolus et les prochaines étapes recommandées pour un humain ou le prochain cycle.
• Réinitialisation : Le plafond se réinitialise lorsque l'opérateur démarre un nouveau cycle de babysitting (redémarrage explicite, pas automatique).

Liste de vérification avant édition (branche/worktree)

Avant toute modification de code, l'agent DOIT vérifier :

1. Isolation du worktree : pwd se trouve dans le chemin du worktree assigné ({worktree_root}/{owner}/{repo}/{job_id}).
2. Exactitude de la branche : git branch --show-current correspond à la branche de fonctionnalité assignée.
3. État propre : git status ne montre aucun changement non commité provenant d'un autre travail.
4. Alignement distant : git fetch && git status confirme que la branche suit le référentiel distant attendu.
5. Pas de modifications transfrontalières : Aucun fichier en dehors du worktree n'est modifié (pas de chemins ../, pas de chemins absolus en dehors de la racine du worktree).

Si l'une des vérifications échoue, l'agent DOIT abandonner et signaler l'incohérence.

Consignes pour le rapport final

Lorsqu'un cycle de babysitting se termine (avec succès ou à cause du plafond), l'agent rapporte :

• Statut de la PR : Ouverte / Prête pour la révision / Bloquée
• Nombre de correctifs : Nombre de commits correctifs poussés dans ce cycle (par exemple, "2/3")
• Problèmes résiduels : Liste des échecs CI non résolus, commentaires de révision ou blocages
• Attribution de l'agent : Chaque commentaire de PR et message de commit inclut l'identification de l'agent

L'agent NE DOIT PAS prétendre avoir fusionné la PR. Si la PR semble fusionnée, l'agent signale "La PR a été fusionnée par un humain" et s'arrête.

Modèle de prompt neutre pour sous-agent de travail

Lors de la génération d'un sous-agent de travail, incluez ces instructions de sécurité dans le prompt :

RÈGLES DE SÉCURITÉ (non-négociables) :
- NE JAMAIS fusionner une PR ou invoquer une API/CLI de fusion
- NE JAMAIS utiliser `git push --force` nu ou `git push -f`
- `git push --force-with-lease` est autorisé uniquement pour rebaser votre propre branche
- NE JAMAIS modifier des fichiers en dehors de votre worktree assigné
- NE JAMAIS commiter plus de 3 commits correctifs par cycle de babysitting
- Avant d'éditer, vérifiez : chemin du worktree, nom de la branche, état propre
- Après avoir poussé, répondez avec le SHA et l'attribution de l'agent
- Lorsque le plafond est atteint, signalez les problèmes résiduels ; ne poussez plus de code

Couches d'application

Ces barrières de protection sont appliquées à plusieurs niveaux :

1. Skill d'agent (ce fichier) : Documentation portable et modèles de prompts. Ne constitue pas une frontière de sécurité — les agents peuvent contourner si la plateforme ne les contraint pas.
2. Orchestrateur Python : Application des politiques via le pont de sous-processus. Compte les commits correctifs, valide les chemins et bloque les commandes interdites avant qu'elles n'atteignent Rust.
3. Noyau Rust (wh-core) : Application matérielle. Rejette les opérations git/GitHub dangereuses à la frontière du processus. C'est la couche de sécurité faisant autorité.

Défense en profondeur : les trois couches appliquent les mêmes règles. Une défaillance dans une couche est rattrapée par une autre.