Compétences de Claude Code

Le dépôt fournit un ensemble de skills Claude Code sous .claude/skills/ qui automatisent les parties les plus lourdes du flux de travail du mainteneur : revues de PR, triage des issues, squash-merge, génération du changelog, et plus encore.

Chaque compétence réside dans son propre répertoire avec un fichier SKILL.md. Claude Code les charge automatiquement lorsque vous ouvrez le dépôt ; vous pouvez les invoquer en décrivant ce que vous souhaitez en langage naturel, ou par référence explicite (par exemple, /squash-merge 1234).

Compétences disponibles

Flux de travail de revue de PR

Le skill github-pr-review-session est l’outil principal pour les journées de revue. Une session typique ressemble à :

> review 1234

La compétence lit AGENTS.md, le manuel du réviseur, ainsi que la différence (diff) et les commits de la PR, puis rédige une revue. Elle utilise :

• Commentaires de diff en ligne pour chaque constatation 🔴 bloquante, 🟡 avertissement ou 🔵 suggestion liée à une ligne spécifique
• Corps de la revue pour le verdict global, le résumé de compréhension, les références croisées et les problèmes au niveau du modèle non liés à une ligne
• Hachages de commit bruts (jamais entourés de backticks : GitHub les transforme automatiquement en liens)
• Noms d’utilisateurs précédés de @ dans tout le contenu des commentaires

Les constats suivent la taxonomie de retours : 🔴 [blocking] bloque la PR, 🟡 [warning] devrait être traité, 🔵 [suggestion] est facultatif, 🟢 [praise] souligne ce qui fonctionne, et ✅ [resolved] confirme qu’un constat a été traité lors d’une nouvelle revue. Le PR Review Protocol fait référence pour les niveaux et le format Markdown du corps de la revue.

La compétence affiche toujours un brouillon pour approbation avant publication. Les revues sont publiées sous l’identité du relecteur humain, et non en tant que bot.

Re-vérifier après les modifications :

> re-review 1234

Ou travaillez à travers la file d’attente :

> go through the queue

Flux de travail de tri des problèmes

Le skill github-issue-triage exécute des balayages autonomes du backlog dans les limites d’autorité définies. Sans argument, il effectue une passe de comptabilisation (état du backlog, puis demande un mode) ; sinon, les modes sont :

• Triage : traiter les issues sans labels de triage : classifier, appliquer les labels, lier aux PRs ouvertes, signaler les rapports de bugs incomplets, rediriger les issues de sécurité
• Sweep : passage complet du backlog par ordre de priorité (corrigé-par-PR-fusionnée → doublons → r:support → candidats obsolètes)
• Obsolète : appliquer la politique canonique relative aux issues obsolètes (status:stale, délai de réponse, exclusions et réengagement)
• Won’t-fix : fermer les issues qui violent une contrainte d’ingénierie fondamentale nommée, en citant la contrainte et sa référence dans AGENTS.md/la RFC
• Unique : traiter une issue par numéro ou URL

Les définitions des labels se trouvent dans Labels ; les labels de triage appliqués par le skill (r:needs-repro, r:support, stale-candidate, les labels de cycle de vie status:* et les labels de résolution) y sont tous définis. La procédure de gestion des issues obsolètes est décrite dans le protocole du skill issue-triage, avec le contexte côté relecteur dans Reviewer playbook → Issue triage. Le skill fait remonter toute ambiguïté à l’utilisateur avant d’agir.

Stratégie de fusion squash

ZeroClaw utilise la fusion par écrasement (squash-merge) pour toutes les PR. La compétence squash-merge génère à la fois le badge violet Fusionné et un message de squash au format conventional-commits avec l’historique complet des commits dans le corps du message.

Pourquoi cette compétence existe

Fusion par écrasement par défaut de GitHub :

• Omet le numéro de la PR du sujet
• Formate le corps de manière incohérente
• Ne correspond pas aux conventions du projet

Pousser directement un squash sur master contourne le mécanisme de fusion des PR : la PR affiche « Closed » au lieu de « Merged » (pas de badge violet, pas de fermeture automatique de l’issue liée, pas d’association de fusion). La skill utilise gh pr merge --subject --body pour obtenir à la fois le badge et le commit correctement formaté.

Format

• Sujet : <PR title> (#<number>) : doit respecter les conventional commits (feat(scope): …, fix: …, etc.)
• Corps (PR multi-commit) : liste à puces de - <sha court> <sujet du commit> depuis la branche du PR
• Corps (PR à un seul commit) : corps complet du commit, ou vide s’il n’y en a pas

Vérifications préliminaires

La compétence s’arrête à :

1. PR non ouverte
2. La PR cible une branche autre que master.
3. Conflits de fusion présents (l’utilisateur doit demander à l’auteur de rebaser)
4. CHANGES_REQUESTED révision en attente
5. gh CLI < 2.17.0 (absence des indicateurs --subject/--body)

Un état REVIEW_REQUIRED demande une confirmation mais ne bloque pas.

Invocation

> squash-merge 1234

ou explicite :

> /squash-merge 1234

La compétence confirme toujours le sujet et le corps générés avant d’appeler gh pr merge.

Génération du journal des modifications

changelog-generation génère CHANGELOG-next.md pour une version en interrogeant gh pour obtenir les PR fusionnées depuis le dernier tag, en les regroupant par préfixe conventional-commits, et en les formatant selon le style de changelog de la maison. Utilisez-le dans le cadre du runbook de version, avant de déclencher release-stable-manual.yml.

Modification des compétences

Les skills sont de simples fichiers Markdown avec un frontmatter YAML. Leur champ description est ce que Claude Code utilise pour décider quand les déclencher : soyez précis et incluez des phrases de déclenchement concrètes ("review 1234", "triage issues", etc.). Utilisez skill-creator pour les modifier ; il impose la structure et aide à exécuter des évaluations pour mesurer la précision du déclenchement.

Lorsque le comportement d’une compétence diverge de ce qui est décrit dans la documentation (par exemple, si le jeu de révision du réviseur est modifié), mettez à jour la compétence et toute documentation qui y fait référence. Le fichier SKILL.md de la compétence est la référence pour l’automatisation ; la documentation de contribution est la référence pour les humains.