Razsk/VideoStudio

Demandez à Matt

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

Avant de dire ce que fait une compétence ou de recommander de sauter une étape, lisez le SKILL.md de cette compétence : les résumés ici ne sont qu'à titre indicatif.

Un flux est un cheminement à travers les compétences. La plupart des chemins suivent un flux principal, et deux bretelles d'accès le rejoignent. Tout le reste est autonome, ou une couche de vocabulaire qui s'exécute en dessous.

Le flux principal : idée → livraison

Le chemin qu'emprunte la plupart du travail. Vous avez une idée et vous voulez la réaliser.

1. /grill-with-docs affine l'idée par un entretien. Commencez ici chaque fois que vous travaillez dans un répertoire de travail : il est avec état, retenant ce qu'il apprend dans GLOSSARY.md et les ADR. (Pas de répertoire de travail ? Utilisez /grill-me à la place, couvert dans la section Autonome. Les deux exécutent la même primitive /grilling ; grill-with-docs est celui qui laisse une trace écrite, ce qui en fait le meilleur des deux chaque fois qu'un dépôt est là pour y laisser cette trace.)

2. Branchement : pouvez-vous résoudre chaque question par la conversation ? Si une question nécessite une réponse exécutable (état, logique métier, une UI que vous devez voir), faites un détour par un prototype, ponté par /handoff dans les deux directions (un prototype vit dans son propre répertoire, ce qui est exactement à quoi sert /handoff ; voir Limites de phase) :

   • /handoff sortant, puis ouvrez une nouvelle session sur ce fichier,
   • /prototype pour répondre à la question avec du code jetable,
   • /handoff retour de ce que vous avez appris, et référencez-le depuis le fil d'idée original.

3. Branchement : s'agit-il d'une construction multi-session ?

   • Oui → /to-spec (transformez le fil en spécification), puis /to-tickets pour le diviser en tickets traceurs, chacun déclarant ses dépendances bloquantes. Travaillez ensuite les tickets de l'une des deux manières suivantes :
     • /implement par ticket, en nettoyant (/clear) le contexte entre chaque. Sur un tracker local, il s'agit d'un fichier par ticket sous .scratch/<feature>/issues/, travaillé en priorité par dépendances bloquantes manuellement ; sur un tracker réel, les dépendances deviennent des liens natifs de blocage, donc n'importe quel ticket dont les dépendances sont terminées peut être pris. Chaque ticket est autonome, donc le contexte du dernier est jetable.
     • /implement-spec pour toute la spécification en une seule exécution. Il lit les tickets comme un graphe de tâches, exécute des sous-agents implémenteurs sur la frontière prête en parallèle, et consolide le tout sur une branche d'intégration. Utilisez-le quand vous préférez orchestrer la construction plutôt que de conduire chaque ticket vous-même.
   • Non → /implement ici même, dans la même fenêtre de contexte.

   Dans les deux cas, le code est construit en pilotant /tdd (une tranche rouge-vert à la fois) et se termine par /code-review, une revue sur deux axes (Standards + Spécification) du diff. /implement exécute les deux par ticket ; les implémenteurs de /implement-spec pilotent chacun /tdd, et il exécute une /code-review sur la branche d'intégration. Utilisez /tdd seul quand vous voulez simplement construire un comportement concret d'abord par les tests sans spécification complète, et /code-review seul chaque fois que vous voulez revoir une branche ou une PR par rapport à un point de référence.

   Quand le travail est soumis sous forme de pull request, /pr façonne le corps : le plus petit visuel montrant le changement, les preuves avant/après que ça fonctionne, et un appel à décision unidirectionnelle ou bidirectionnelle. C'est invoqué par le modèle, donc l'agent l'utilise chaque fois qu'il écrit une PR.

4. /retro boucle la boucle. Après une construction, et surtout une qui a mal tourné, elle examine la session et suggère des changements à l'environnement de l'agent, pas au code : pointeurs de navigation, vérifications automatisées, les standards de codage que /code-review applique, fichiers de pilotage, outils. Les erreurs mécaniques deviennent des vérifications déterministes ; les décisions subjectives deviennent des standards de codage. La construction suivante part alors d'un meilleur environnement.

Hygiène du contexte

Gardez les étapes 1 à 3 dans une seule fenêtre de contexte ininterrompue (ne compactez pas et ne nettoyez pas avant /to-tickets) pour que le gril, la spécification et les tickets reposent tous sur la même réflexion. Chaque /implement commence ensuite à nouveau, à partir du ticket. Exécutez /retro dans la session qu'elle examine, avant de nettoyer ; après nettoyage, pointez-la vers le journal de cette session à la place.

La limite est la zone intelligente : la fenêtre (~150k tokens sur les modèles de pointe) dans laquelle le modèle raisonne encore avec acuité. Si une session s'en approche avant /to-tickets, ne forcez pas sur du dégradé ; utilisez /compact à la limite de phase la plus proche et continuez (voir Limites de phase).

Bretelles d'accès

Une situation de départ qui génère du travail, puis rejoint le flux principal.

• Les bugs et les demandes s'accumulent → /triage. Elle déplace les tickets à travers les rôles de triage et produit des tickets prêts pour l'agent, que /implement récupère plus tard.

  Le triage est uniquement pour les tickets que vous n'avez pas créés : rapports de bugs, demandes de fonctionnalités entrantes, tout ce qui arrive brut. Les tickets produits par /to-tickets sont déjà prêts pour l'agent, donc ne les triez pas.

• Quelque chose est cassé → /diagnosing-bugs. Pour les bugs coriaces : le bug qui résiste à un premier coup d'œil, l'intermittent, la régression qui s'est glissée entre deux états connus corrects. Il refuse de théoriser tant qu'il n'a pas une boucle de rétroaction serrée (une seule commande qui devient déjà rouge sur ce bug), puis corrige avec un test de régression. Une fois le correctif en place, exécutez /retro dans la même session pour demander ce qui aurait empêché le bug ; là où la véritable découverte est qu'il n'y a pas de bonne jointure pour le verrouiller, c'est un travail pour /improve-codebase-architecture.

• Un effort énorme et flou : un projet greenfield ou une construction de fonctionnalité massive, trop grande pour une seule session → /wayfinder, le flux le plus exigeant cognitivement ici. Lorsque le chemin d'ici à la destination n'est pas encore visible, il établit une carte partagée de tickets de décision sur le tracker de tickets et les résout un par un, produisant des décisions, pas des livrables, jusqu'à ce que le brouillard soit repoussé et que la voie soit claire. Là où /grill-with-docs affine une idée que vous pouvez contenir dans une session, wayfinder est pour l'idée que vous ne pouvez pas, et il est plus lent et plus dense, donc réservez-le exactement pour cela, jamais pour une fonctionnalité bien cadrée.

  Lorsque la carte s'éclaircit, elle transmet, elle ne construit pas : rejoignez le flux principal à /to-spec, qui condense les décisions liées de la carte en un plan réalisable, puis /to-tickets et /implement comme d'habitude. Boucler la carte directement dans /implement saute cette condensation et jette les détails liés, donc allez directement à /implement uniquement lorsque l'effort s'est avéré vraiment petit.

Santé du code

Ce n'est pas du travail de fonctionnalité, juste de l'entretien.

• /improve-codebase-architecture s'exécute chaque fois que vous avez un moment libre pour garder la base de code adaptée aux agents. Elle révèle des opportunités d'approfondissement ; en choisir une génère une idée que vous pouvez amener dans le flux principal à /grill-with-docs. C'est l'étude qui trouve les candidats ; /codebase-design (ci-dessous) est l'établi sur lequel vous concevez celui choisi.

Vocabulaire sous-jacent

Deux références invoquées par le modèle qui s'exécutent sous les autres compétences, chacune étant la source unique de vérité pour son vocabulaire. Utilisez-les directement quand les mots, pas le processus, sont le problème ; ou laissez les compétences ci-dessus les solliciter.

• /domain-modeling : affine le langage du domaine du projet : contester un terme flou, résoudre un mot surchargé (« compte » faisant trois jobs), enregistrer une décision difficile à inverser comme ADR. C'est la discipline active que /grill-with-docs pilote pour que GLOSSARY.md reste un glossaire propre.
• /codebase-design est le vocabulaire du module profond (module, interface, profondeur, jointure, adaptateur, levier, localité) pour concevoir la forme d'un module : beaucoup de comportement derrière une petite interface à une jointure propre. /tdd et /improve-codebase-architecture parlent tous deux ce langage.

Limites de phase

Une phase est un morceau de travail à l'intérieur d'une session : le grill, l'implémentation, la QA. À la limite entre deux d'entre elles, vous avez cinq options, et choisir entre elles est la décision la plus floue de toute cette carte :

• Continuer : restez sur place. Ne coûte rien, ne perd rien.
• /clear : videz la fenêtre, quand rien ici n'a d'importance pour la suite.
• /handoff écrit un fichier markdown portable. Étroit : uniquement pour un nouveau harnais, un nouveau répertoire, un collègue, ou pour bifurquer une tâche secondaire en milieu de phase. Ce qu'il achète, c'est la portabilité.
• Sous-agent : envoyez une tâche très circonscrite dans sa propre fenêtre et recevez un rapport.
• /compact compresse ce contexte et amorce une nouvelle session avec. Le par défaut, en bas de l'arbre plutôt que le premier atteint.

Lisez PHASE-BOUNDARIES.md pour l'arbre ordonné : les cinq questions, le raisonnement derrière chaque branche, et pourquoi le coût de la source primaire fait de Continuer celui à écarter en premier. Prenez la décision à une limite ; en milieu de phase, continuez ou divisez le reste en sous-agents.

Autonome

Hors du flux principal.

• /grill-me : le même entretien incessant que /grill-with-docs, mais sans état : il ne sauvegarde rien localement et ne construit pas de GLOSSARY.md. Utilisez-le quand vous ne travaillez pas dans un répertoire de travail (affiner un plan, un design, un écrit, tout ce qui n'a pas de dépôt en dessous). Si vous êtes dans un répertoire de travail, utilisez plutôt /grill-with-docs : il exécute le même entretien et laisse une trace écrite, donc il est strictement meilleur.
• /grilling est la primitive d'entretien elle-même : tours, la frontière, les faits sont le travail de l'agent et les décisions sont les vôtres. /grill-me et /grill-with-docs sont les deux façons nommées d'entrer, et /triage, /wayfinder et /improve-codebase-architecture l'exécutent toutes en interne. Utilisez-la directement uniquement quand vous voulez l'entretien sans aucune couche autour.
• /prototype est un petit programme jetable qui répond à une question de conception : ce modèle d'état semble-t-il correct, ou à quoi devrait ressembler cette UI. Jetable est une contrainte sur la façon dont le code est écrit, pas une promesse de le détruire : la réponse est intégrée dans le code réel, et le prototype lui-même est conservé comme source primaire sur une branche prototype/<name> issue de main, pointée depuis le ticket d'implémentation. C'est le détour à l'étape 2 du flux principal, mais utilisez-le chaque fois qu'une question de conception est difficile à trancher sur papier.
• /research : déléguez 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 cité dans le dépôt. Continuez à travailler pendant qu'il lit. Le fichier qu'il produit est quelque chose à amener dans le flux principal à /grill-with-docs, car la recherche alimente la réflexion sans la remplacer.
• /to-questionnaire intervient quand ce qui vous bloque n'est ni dans votre tête ni dans la base de code mais dans celle de quelqu'un d'autre, et il leur écrit un questionnaire à remplir. C'est l'inverse de /grill-me : au lieu de vous interviewer sur le sujet, il vous interviewe sur l'envoi (à qui ça va, de quoi vous avez besoin en retour) et oriente les questions vers le vide. Ce qui revient est du matériel pour /grill-with-docs ou /to-spec.
• /wizard est pour les étapes que seul un humain peut effectuer : provisionner l'infrastructure, configurer des identifiants ou des secrets CI, naviguer dans un tableau de bord tiers inconnu, exécuter une migration ponctuelle ou un basculement. Il génère un script bash interactif qui ouvre chaque URL, capture chaque valeur, et l'écrit dans .env et les secrets GitHub, de sorte que la procédure cesse d'être quelque chose que vous réexpliquez à un agent à chaque fois. Invoqué par le modèle, donc l'agent l'utilise dès qu'il rencontre un mur que vous seul pouvez franchir. Si l'agent pouvait le faire lui-même, il devrait ; c'est pour les cas où un humain est véritablement dans la boucle.
• /wait-what est le correctif pour un message qui n'a pas atterri. Utilisez-le en milieu de conversation, à l'intérieur de n'importe quelle autre compétence, et l'agent reformule ce qu'il vient de dire avec le contexte qui vous manquait, en anglais simple, en utilisant le vocabulaire du GLOSSARY.md. Il fonctionne après coup ; /grill-with-docs est le remède préventif, car un langage partagé convenu tôt est ce qui empêche le jargon d'arriver du tout.
• /teach : apprenez un concept sur plusieurs sessions, en utilisant le répertoire courant comme espace de travail avec état.
• /writing-for-agents est la référence pour écrire des documents que les agents consomment : compétences, AGENTS.md, docs pointés.

Précondition

/setup-matt-pocock-skills : exécutez avant votre premier flux d'ingénierie pour configurer le tracker de tickets, les étiquettes de triage et la disposition des documents que les autres compétences supposent. Les trackers de tickets personnalisés fonctionnent aussi.