Brians-brain/claude-skills

Demander à Matt

Répondre à l'utilisateur en chinois traditionnel.

Vous ne vous souvenez pas de chaque compétence, alors demandez.

Avant d'expliquer ce que fait une compétence ou de suggérer de sauter une étape, lisez d'abord le SKILL.md de cette compétence : le résumé ci-dessous sert uniquement à vous orienter.

Un processus est un chemin qui traverse ces compétences. La plupart des chemins suivent un flux principal, avec deux voies d'accès qui s'y rejoignent. Les autres sont utilisées indépendamment ou comme couches lexicales sous-jacentes.

Flux principal : Idée → Mise en ligne

La route que la plupart des travaux empruntent. Vous avez une idée et vous voulez la concrétiser.

1. /grill-with-docs – Affinez votre idée par l'entretien. Commencez ici dès que vous travaillez dans un répertoire de travail : il est avec état et conserve ce qui est appris dans GLOSSARY.md et les ADR. (Pas de répertoire de travail ? Utilisez /grill-me, voir « Utilisation indépendante ». Les deux exécutent le même mécanisme de base /grilling ; grill-with-docs laisse une trace écrite, donc c'est le meilleur tant qu'il y a un dépôt.)

2. Branchement : Chaque problème peut-il être résolu dans la conversation ? Si un problème nécessite une réponse exécutable (état, logique métier, UI que vous devez voir), faites un détour par le prototype, en utilisant /handoff dans les deux sens (le prototype va dans son propre répertoire, c'est exactement le but de /handoff ; voir « Frontières de phase ») :

   • Remettez le travail avec /handoff, puis ouvrez une nouvelle session sur ce fichier,
   • Utilisez /prototype pour répondre à la question avec du code jetable,
   • Récupérez ce qui a été appris avec /handoff, en le référençant depuis le fil de discussion de l'idée originale.

3. Branchement : Est-ce une construction qui nécessite plusieurs sessions ?

   • Oui → /to-spec (transformez le fil de discussion en spécification), puis /to-tickets pour le décomposer en tickets tracer-bullet, chacun marqué de son bloquant. Ensuite, traitez les tickets de l'une des deux manières suivantes :
     • Une exécution de /implement par ticket, avec /clear du contexte entre chaque ticket. Sur un tracker local, c'est un fichier par ticket sous .scratch/<feature>/issues/, traités manuellement par ordre de priorité des bloqueurs ; sur un vrai tracker, les blocs deviennent des liens natifs, donc tout ticket dont les bloqueurs sont terminés peut être pris en charge. Chaque ticket est autonome, donc le contexte du précédent peut être jeté.
     • Utilisez /implement-spec pour exécuter l'intégralité de la spécification en une seule fois. Il lit les tickets comme un graphe de tâches, exécute des sous-agents d'implémentation en parallèle sur la frontière prête, et rassemble tout sur une seule branche d'intégration. À utiliser lorsque vous préférez orchestrer l'ensemble de la construction plutôt que de pousser ticket par ticket vous-même.
   • Non → utilisez /implement ici, dans la même fenêtre de contexte.

   Dans les deux cas, le code est construit via /tdd (une tranche rouge-vert à la fois) et se termine par /code-review-zh, une revue biaxiale du diff (Standards + Spécification). /implement exécute ces deux étapes pour chaque ticket ; /implement-spec fait utiliser /tdd par chaque implémenteur et exécute /code-review-zh sur la branche d'intégration à la fin. Utilisez /tdd seul lorsque vous voulez simplement réaliser un comportement spécifique avec le test en premier, sans spécification complète ; utilisez /code-review-zh seul à tout moment pour revoir une branche ou une PR par rapport à un point fixe.

   Lorsque le travail doit être soumis sous forme de pull request, /pr détermine la forme du contenu de la PR : visualisation minimale des changements, preuves avant/après démontrant son efficacité, et jugement de porte à sens unique/porte à double sens. Il est appelé par le modèle, donc l'agent l'utilise à chaque fois qu'il écrit une PR.

4. /retro ferme la boucle. Après une construction, surtout si elle a mal tourné, il examine l'ensemble de la session et suggère des améliorations de l'environnement de travail de l'agent, pas du code : indicateurs de navigation, vérifications automatiques, normes rédactionnelles exécutées par /code-review-zh, fichiers de guidage, outils. Les erreurs mécaniques deviennent des vérifications déterministes ; les jugements deviennent des normes rédactionnelles. La prochaine construction démarre dans un meilleur environnement.

Hygiène du contexte

Gardez les étapes 1 à 3 dans la même fenêtre de contexte ininterrompue (ne compactez ni n'effacez avant /to-tickets), afin que l'entretien, la spécification et les tickets soient tous construits sur la même pensée. Ensuite, chaque /implement repart de zéro, en travaillant à partir du ticket. Exécutez /retro dans la session à réviser, avant d'effacer ; si déjà effacée, pointez-la vers le journal de cette session.

La contrainte est la zone intelligente (smart zone) : la fenêtre dans laquelle le modèle raisonne encore avec acuité (environ 150 000 tokens sur les modèles les plus avancés). Si une session approche de cette limite avant /to-tickets, ne forcez pas dans un état dégradé : /compact à la frontière de phase la plus proche, puis continuez (voir « Frontières de phase »).

Voies d'accès

Contextes de départ qui génèrent du travail puis rejoignent le flux principal.

• Les bugs et les demandes s'accumulent → /triage. Il fait circuler les issues entre les rôles de triage, produisant des issues prêtes pour un agent, reprises ensuite par /implement.

  Le triage est réservé aux issues que vous n'avez pas créées : signalements de bugs, demandes de fonctionnalités entrantes, tout ce qui arrive non traité. Les tickets produits par /to-tickets sont déjà prêts pour un agent, donc ne les triez pas.

• Quelque chose est cassé → /diagnosing-bugs. Pour les cas coriaces : bugs qui ne sautent pas aux yeux, instabilités intermittentes, régressions qui s'infiltrent entre deux états connus comme corrects. Il refuse de proposer une théorie avant d'avoir une boucle de rétroaction serrée (une commande qui échoue déjà à cause de ce bug), puis corrige avec un test de régression. Après la correction, exécutez /retro dans la même session pour demander ce qui pourrait prévenir ce bug ; si la vraie découverte est qu'il n'y a pas de bonne couture (seam) pour le verrouiller, c'est un travail pour /improve-codebase-architecture.

• Un projet vaste et brumeux : nouveau projet ou construction d'une fonctionnalité géante qu'une session ne peut contenir → /wayfinder, le processus le plus gourmand en réflexion ici. Lorsque le chemin d'ici à la destination n'est pas encore visible, il dessine une carte partagée de tickets de décision sur le tracker d'issues, en les résolvant un par un, produisant des décisions plutôt que des livrables, jusqu'à ce que le brouillard se dissipe et que le chemin devienne clair. /grill-with-docs affine les idées que vous pouvez maîtriser en une session ; wayfinder est pour les idées que vous ne pouvez pas maîtriser, et il est plus lent et plus dense, donc réservez-le pour ce cas et ne l'utilisez jamais pour des fonctionnalités au périmètre clair.

  Une fois la carte claire, il passe le relais, il ne construit pas : il rejoint le flux principal via /to-spec, qui condense les décisions liées de la carte en un plan constructible, puis procède comme d'habitude avec /to-tickets et /implement. Brancher directement la carte sur /implement saute cette condensation et perd les détails des liens, donc ne le faites que si le projet s'avère finalement très petit.

Santé du code

Pas de développement de fonctionnalités, juste de la maintenance.

• /improve-codebase-architecture – Exécutez-le quand vous avez le temps pour garder le code dans un état propice au travail d'un agent. Il identifie des opportunités d'approfondissement ; en choisir une génère une idée que vous pouvez apporter au /grill-with-docs du flux principal. C'est une exploration pour trouver des candidats ; /codebase-design (voir ci-dessous) est l'atelier pour concevoir le candidat choisi.

Lexique sous-jacent

Deux références appelées par le modèle, fonctionnant sous les autres compétences, chacune étant la source unique de vérité pour son lexique. Utilisez-les directement lorsque le problème concerne la terminologie plutôt que le processus ; ou laissez les compétences ci-dessus les invoquer.

• /domain-modeling : affine le langage domaine du projet : conteste un terme ambigu, résout un mot surutilisé (par exemple « numéro de pièce » qui désigne trois choses différentes), enregistre une décision difficile à annuler dans un ADR. C'est la discipline active utilisée par /grill-with-docs pour garder GLOSSARY.md propre.
• /codebase-design est le lexique du module profond (modules, interfaces, profondeur, coutures, adaptateurs, leviers, localité), utilisé pour concevoir la forme des modules : beaucoup de comportement derrière de petites interfaces sur des coutures propres. /tdd et /improve-codebase-architecture l'utilisent tous deux.

Frontières de phase

Une phase est une partie du travail dans une session : entretien, implémentation, QA. À la frontière entre deux phases, vous avez cinq options, et choisir entre elles est la décision la plus floue de toute la carte :

• Continuer : restez sur place. Ne coûte rien, ne perd rien.
• /clear : vide la fenêtre, lorsque rien de ce qui s'y trouve n'est important pour la suite.
• /handoff : écrit un fichier Markdown portable. Usage très spécifique : uniquement pour changer de harnais, changer de répertoire, passer à un collègue, ou détacher une tâche secondaire en milieu de phase. Il échange la continuité contre la portabilité.
• Sous-agent : envoie une tâche au périmètre clair dans sa propre fenêtre et rapporte un rapport.
• /compact : compresse le contexte actuel et l'utilise pour démarrer une nouvelle session. C'est l'option par défaut, tout en bas de l'arbre, pas la première à saisir.

L'arbre de décision ordonné se trouve dans PHASE-BOUNDARIES.md : cinq questions, les raisons derrière chaque branche, et pourquoi le coût de l'information de première main fait de Continuer la première option à exclure. Prenez la décision sur la frontière ; en milieu de phase, continuez ou confiez le reste du travail à un sous-agent.

Utilisation indépendante

Pas du tout sur le flux principal.

• /grill-me : le même entretien rigoureux que /grill-with-docs, mais sans état : il ne sauvegarde rien localement, ne crée pas GLOSSARY.md. À utiliser lorsque vous ne travaillez pas dans un répertoire de travail (affiner un plan, un design, un article, tout ce qui n'a pas de dépôt en dessous). Si vous êtes dans un répertoire de travail, utilisez /grill-with-docs à la place : il fait le même entretien et laisse une trace écrite, donc il est strictement meilleur.
• /grilling est le mécanisme d'entretien lui-même : tours, frontière, recherche de faits qui est le travail de l'agent, prise de décision qui est la vôtre. /grill-me et /grill-with-docs sont deux points d'entrée nommés, et /triage, /wayfinder et /improve-codebase-architecture l'exécutent en interne. Utilisez-le directement uniquement si vous voulez l'entretien brut, sans aucun emballage.
• /prototype est un petit programme jetable répondant à une question de conception : ce modèle d'état est-il sensé, ou à quoi devrait ressembler cette UI. « Jetable » est une contrainte sur la façon d'écrire le code, pas une promesse de le détruire : la réponse est intégrée dans le code officiel, et le prototype lui-même est conservé comme source primaire sur une branche prototype/<name> en dehors de main, et référencé depuis le ticket d'implémentation. C'est le détour de l'étape 2 du flux principal, mais il peut être utilisé à tout moment lorsqu'une question de conception est difficile à résoudre sur le papier.
• /research : confie le travail de lecture à un agent d'arrière-plan : il enquête sur une question à partir de sources primaires, puis laisse un fichier Markdown avec citations dans le dépôt. Pendant qu'il lit, vous continuez à travailler. Le fichier produit est destiné à être apporté au /grill-with-docs du flux principal, car la recherche alimente la pensée, elle ne la remplace pas.
• /to-questionnaire s'utilise lorsque ce qui vous bloque n'est ni dans votre tête ni dans le code, mais dans la tête de quelqu'un d'autre. Il vous aide à rédiger un questionnaire à lui faire remplir. C'est l'inverse de /grill-me : il ne vous interroge pas sur le sujet lui-même, mais sur l'envoi (à qui envoyer, ce qui doit être récupéré), et cible les questions sur les lacunes. Le retour est un matériau pour /grill-with-docs ou /to-spec.
• /wizard est pour les étapes que seul un humain peut faire : mettre en place une infrastructure, configurer des secrets CI, naviguer dans un backend tiers inconnu, exécuter une migration ou un basculement ponctuel. Il génère un script bash interactif qui ouvre chaque URL, récupère chaque valeur, et les écrit dans .env et les secrets GitHub, rendant la procédure réutilisable sans avoir à la réexpliquer à l'agent à chaque fois. Il est appelé par le modèle, donc l'agent l'utilise dès qu'il rencontre un mur que seul vous pouvez franchir. Si l'agent peut le faire lui-même, il doit le faire ; c'est pour les cas où un humain est vraiment nécessaire dans la boucle.
• /wait-what est le correctif pour un message qui n'est pas passé. Utilisable en cours de conversation, dans n'importe quelle autre compétence ; l'agent comble le contexte manquant et reformule ce qu'il vient de dire en langage simple, avec le vocabulaire de GLOSSARY.md. C'est un correctif a posteriori ; /grill-with-docs est le remède préventif, car un langage commun convenu tôt empêche la terminologie de surgir en premier lieu.
• /teach : utilise le répertoire actuel comme espace de travail avec état pour apprendre un concept sur plusieurs sessions.
• /writing-for-agents est une référence pour rédiger des documents destinés à être lus par un agent : compétences, AGENTS.md/CLAUDE.md, documents pointés.
• /handoff : compresse la conversation actuelle en un fichier de passation pour une nouvelle session, un nouveau répertoire ou un collègue (voir « Frontières de phase »).
• /git-guardrails-claude-code : installe un hook Claude Code qui bloque les commandes git dangereuses (push, reset --hard, etc.) avant leur exécution. Configurable une fois par machine ou par projet.

Prérequis

/setup-matt-pocock-skills : à exécuter avant la première utilisation d'un processus de type génie logiciel ; il configure le tracker d'issues, les étiquettes de triage et la disposition des fichiers supposés par les autres compétences. Prend également en charge un tracker d'issues personnalisé.