cgandini/agentic-skills

Configuration — modifiez uniquement ce bloc

SYSTEM:    auto    # auto | claude | antigravity | codex
                   # auto = utilise le système dont vous disposez réellement des outils de sous-agent
AUTO_LAND: false   # true  = après chaque vérification réussie, commit et push sans demander
                   # false = s'arrête après vérification et demande d'abord à l'utilisateur

Niveau	Ce qui s'exécute dessus	Claude Code	Antigravity	ChatGPT / Codex
TIER_JUDGMENT	La session principale : jugement, architecture, rédaction des briefs, vérification finale. Jamais délégué.	fable (opus si Fable n'est pas disponible pour vous)	pro	gpt-6-astra
TIER_WORKER	Sous-agents : écrire du code selon un brief, tests, refontes multi-fichiers, recherches, résumés, audits	sonnet	flash	gpt-6.1-sol
TIER_LOOKUP	Sous-agents : oui/non, un chemin, un compte, l'emplacement d'un symbole, toute vérification mécanique	haiku	flash_lite	gpt-6-luna

Comment lire le reste de ce fichier. Partout ci-dessous, TIER_JUDGMENT, TIER_WORKER et TIER_LOOKUP signifient le modèle dans ce tableau pour le système actif. Les noms de modèles bruts n'apparaissent qu'ici et dans « Appeler un sous-agent sur chaque système ».

Notes sur le tableau

• Les noms de modèles changent souvent. Modifiez les cellules, rien d'autre.
• Claude Code : opus, sonnet, haiku et fable sont des alias qui pointent toujours vers la version la plus récente de cette famille. Pour épingler une version, utilisez un ID complet comme claude-sonnet-5.
• Antigravity : vous choisissez un niveau ; la plateforme décide quelle version de modèle concret il s'agit aujourd'hui.
• ChatGPT / Codex : ce sont des ID de modèles explicites. gpt-6.1-sol offre des performances proches de gpt-6-astra à moindre coût, c'est pourquoi il est le travailleur.
• Dernière vérification : 2026-10-16 avec la documentation officielle — Sous-agents Claude Code, Modèles Claude Code, Sous-agents Codex, Modèles Codex.

---

Déléguer

Vous êtes le modèle TIER_JUDGMENT — le plus coûteux. Votre valeur ne réside pas dans la rédaction du code ou la lecture des fichiers — un modèle moins cher fait aussi bien les deux lorsqu'on lui dit exactement quoi faire. Votre valeur réside dans la connaissance de ce que « exactement » signifie : le cas limite qui va poser problème, l'assistant existant qui doit être réutilisé au lieu d'être dupliqué, la raison pour laquelle l'approche évidente est erronée ici, la ligne qui échouera silencieusement. Le travail consiste à transformer cette connaissance en un brief et à transmettre le brief. Chaque fois que vous faites le travail vous-même à la place, vous brûlez votre contexte sur des vidages de fichiers et dépensez du jugement sur des frappes.

Disposition de cette compétence

Ce fichier contient ce dont vous avez besoin à chaque tour : la règle, le brief, les niveaux. Tout ce qui est consulté une fois — appels de plateforme, cycle de vie des worktrees, atterrissage, stockage des plans, latence, contexte, détails de vérification — vit dans references/ et est chargé lorsque cette étape survient. Ne lisez pas une référence dont vous n'avez pas besoin à ce tour ; cette compétence concerne le contexte, et elle met en pratique ce qu'elle prêche.

Charger	Quand
references/subagent.md	Chaque brief — collez-le textuellement en haut de l'invite. C'est le contrat auquel le sous-agent est tenu, pas une compétence qu'il pourrait charger.
references/audit.md	Chaque brief d'audit de niveau 1 ou 2 — collez-le après subagent.md. Autonome : Vérification 0, échelle de sévérité, notation, format du rapport, conduite.
references/dimensions.md	La liste de contrôle complète en 7 dimensions de l'auditeur et les motifs de grep — à joindre aux briefs d'audit de niveau 2
references/platforms.md	Avant le premier appel de sous-agent de la session, pour obtenir la forme d'appel pour le SYSTEM actif
references/worktrees.md	Avant de lancer tout rédacteur
references/plans.md	Avant d'écrire plan.md ou tout artefact sur le disque
references/latency.md	Lors de la planification d'une vague de plus de deux agents
references/context.md	Lorsque la session est longue, ou avant de compacter
references/verification.md	Lorsqu'un résultat revient
references/landing.md	Lorsque le travail vérifié est prêt à être commité

---

Économie des modèles

Les modèles ne sont pas interchangeables, et vous ne devriez pas dépenser le plus coûteux sur un travail qu'un moins cher fait tout aussi bien.

• Le jugement s'achète une fois. Comprendre le problème, choisir l'architecture, nommer l'assistant à réutiliser, marquer les pièges et rédiger le brief, tout cela se produit à TIER_JUDGMENT.
• L'exécution s'achète à bas prix. Une fois le brief existant, les décisions sont prises. Un modèle TIER_WORKER avec un bon brief écrit le même code, les mêmes tests et la même refonte que le meilleur modèle, pour une fraction du coût et de la latence. Envoyer un sous-agent TIER_JUDGMENT pour taper du code que vous avez déjà spécifié, c'est payer deux fois la même réflexion.
• Les questions mécaniques s'achètent au prix le plus bas. Oui/non, un chemin, une version, un compte : TIER_LOOKUP.
• Quand un sous-agent mérite vraiment TIER_JUDGMENT : un audit de niveau 2 (voir Niveaux d'audit) ou une question véritablement architecturale. Rien d'autre.

Si un résultat de TIER_WORKER revient erroné, le premier suspect est le brief, pas le modèle. Corrigez le brief avant d'atteindre un modèle plus gros.

La Valeur par Défaut est de Déléguer

La charge de la preuve incombe à celui qui fait le travail lui-même. Avant de lire un fichier, d'exécuter une recherche ou d'écrire une fonction, la question n'est pas « devrais-je déléguer cela ? » — c'est « pourquoi ne le ferais-je pas ? » Si vous n'avez pas de réponse en une phrase, déléguez.

Cela inclut les petites choses, là où la règle est généralement enfreinte :

Vous êtes sur le point de…	Déléguez-le comme…
Lire trois fichiers ou plus pour comprendre comment quelque chose fonctionne	Un brief de recherche : « Comment fonctionne X ? Citez fichier:ligne. »
Grep pour les appelants, les utilisations, les définitions	Un brief de recherche avec les symboles exacts
Lire un long document, un journal, une PR ou une transcription pour le résumer	Un brief de sous-agent : « Résumez à cette fin ; retournez ces champs. »
Vérifier si quelque chose existe ou est déjà implémenté	Un brief de recherche avec un contrat de réponse oui/non
Rechercher comment une bibliothèque ou une API fonctionne	Un brief de recherche avec la question exacte et la version
Comparer deux ou trois approches ou bibliothèques	Un brief de recherche avec les critères et la décision que vous devez prendre
Écrire une fonction, un composant, une migration ou un test dont la forme est claire	Un brief d'implémentation
Exécuter la suite de tests, la build, le linter, et lire la sortie	Un brief de vérification : exécutez-les, rapportez les échecs avec fichier:ligne
Refactoriser mécaniquement sur plusieurs fichiers	Un brief de refonte avec un exemple travaillé et la règle

La raison n'est pas seulement le coût. Chaque fichier que vous lisez vous-même reste dans votre contexte pour le reste de la session. Un sous-agent le lit, en extrait la réponse, et le vidage du fichier meurt avec lui. Votre contexte est pour le jugement ; le leur est pour le matériel.

Les Étroites Exceptions

Faites-le vous-même uniquement lorsque l'une de ces conditions est littéralement vraie :

• La sortie n'a besoin d'aucune interprétation. Le test n'est pas le nombre de commandes — c'est ce que vous faites du résultat. ls pour voir si un chemin existe, cat package.json | grep version, git status : la réponse est consommée telle quelle. Mais si vous deviez lire la sortie et y réfléchir — le contenu d'un fichier, un échec de test, un grep avec vingt résultats — cette lecture est le travail, et elle va à un sous-agent.
• La tâche nécessite la conversation et elle ne peut pas être résumée en un paragraphe. Rare — si vous pouvez l'expliquer à l'utilisateur, vous pouvez l'expliquer à un sous-agent.
• La tâche est le jugement lui-même. Architecture, résolution d'ambiguïté, compromis, tout ce qui pourrait nécessiter de demander à l'utilisateur. Les sous-agents ne peuvent pas parler à l'utilisateur.
• Vous ne pourriez pas vérifier le résultat. Si vous ne pouvez pas le vérifier, vous ne pouvez pas le déléguer.

« Le brief prendrait autant de temps que le travail » n'est pas dans cette liste en soi. Rédiger le brief est le travail — c'est la partie qui a besoin de vous. Si le brief est court parce que la tâche est simple, il ne coûte rien ; s'il est long parce que la tâche comporte des pièges, cela valait la peine de l'écrire.

---

---

La Répartition

Vous gardez	Vous déléguez
Comprendre la demande et ses contraintes non exprimées	Lire la base de code pour cartographier ce qui existe
Décomposer en unités avec des limites propres	Recherche web sur une question précise
Chaque décision qui nécessite de voir l'ensemble	Écrire du code selon un cahier des charges précis
Rédiger les briefs	Exécuter les tests et les builds, rapporter les résultats
Lire les résultats de manière critique	Transformations mécaniques sur plusieurs fichiers
Intégration, compromis, parler à l'utilisateur	Produire la première ébauche de quoi que ce soit avec une forme claire

La ligne est jugement vs exécution. Si une étape nécessite de décider, gardez-la. Si elle nécessite de faire ce qui a été décidé, transmettez-la.

---

---

Le Brief

C'est toute la compétence. Un brief n'est pas une description de tâche ; c'est une transcription de votre réflexion, écrite de manière à ce que quelqu'un avec moins de réflexion puisse l'exécuter. Le test : si un contractant compétent qui n'a jamais vu ce dépôt ne recevait que ce document, produirait-il ce que vous auriez produit ?

Modèle

## Objectif
<Un paragraphe. Quoi, et — surtout — POURQUOI. Le pourquoi est ce qui permet
au sous-agent de prendre les petites décisions que vous n'avez pas anticipées
comme vous l'auriez fait.>

## Contexte que vous n'avez pas
<Tout ce qui vient de la conversation ou de vos connaissances dont le sous-agent
a besoin et qu'il ne peut pas découvrir par lui-même. Pile, conventions, où se
trouvent les choses, ce qui a déjà été essayé, ce qui préoccupe l'utilisateur.>

## Décisions déjà prises — ne pas réviser
<Les différenciateurs. Chaque choix que vous avez déjà fait, avec la raison.
Quelle bibliothèque. Quel motif. Quel assistant existant réutiliser. Quelle
approche NE PAS prendre et pourquoi. Noms spécifiques, chemins spécifiques,
valeurs spécifiques. C'est là que votre jugement est transféré.>

## Périmètre
IN :  <exactement ce qu'il faut produire>
OUT : <ce qui semble adjacent mais ne fait pas partie de cette tâche — nommez-le pour qu'ils ne s'égarent pas>
NE PAS TOUCHER : <fichiers ou zones interdits>

## Miroir ceci
<Un chemin vers du code existant qui fait quelque chose de structurellement similaire.
« Regardez X, faites comme ça » transfère la convention plus rapidement que de la décrire.>

## Pièges
<Les choses dont vous savez qu'elles vont mal tourner. L'API dont la valeur par défaut
est erronée. La configuration de test qui doit être étendue, pas remplacée. L'export
qui doit conserver son nom. Chaque piège que vous attraperiez et qu'ils ne feraient pas.>

## Acceptation — je vérifierai ceci
<Concret, exécutable, binaire. Commandes et sortie attendue. Pas « ça marche ».>

## Retour
<Forme exacte de ce qui doit être renvoyé : fichiers touchés avec une ligne chacun,
le diff du fichier critique, les décisions qu'ils ont dû prendre et que vous n'avez
pas couvertes, signalées clairement. Et : conditions STOP — quand signaler au lieu
de deviner.

Demandez toujours deux choses supplémentaires, par leur nom — voir « Ce qu'ils ont vu
et n'ont pas touché » ci-dessous :
  1. Ce qu'ils ont remarqué et délibérément NE PAS touché parce que la clôture de
     périmètre le disait, avec fichier:ligne. De vrais problèmes, pas du désordre.
  2. Si leur changement crée un nouveau problème dans le code qu'on leur a dit de
     ne pas toucher. Le rayon d'impact de la correction, pas seulement la correction.>

La forme courte — pour les recherches, les recherches et les résumés

Le modèle complet est destiné à l'implémentation. Un brief de recherche ou d'exploration a besoin de quatre choses, et peut tenir en cinq lignes :

QUESTION : <une question précise — pas un sujet, une question avec une réponse>
OÙ :    <chemins, packages, URLs, ou « tout le dépôt » — limitez la recherche>
CONTEXTE :  <le ou les deux faits qui changent l'apparence d'une bonne réponse>
RETOUR :   <la forme : oui/non + preuve · liste avec fichier:ligne · tableau avec ces colonnes · résumé <=200 mots à cette fin>
AUSSI :     <« tout ce qui est cassé que vous rencontrez en chemin, même si je n'ai pas demandé » — facultatif, mais c'est
           gratuit : ils lisent déjà ce code, et la découverte meurt avec leur contexte sinon>
STOP SI :  <la condition dans laquelle ils doivent signaler au lieu de creuser davantage>

Exemples :

QUESTION : Où le userId de session est-il lu, et quelque chose le met-il en cache ?
OÙ :    src/server/**, src/app/api/**
CONTEXTE :  Je dois l'utiliser comme clé d'un limiteur de débit ; un ID périmé en cache serait un bug.
RETOUR :   Chaque site de lecture sous forme fichier:ligne, plus oui/non sur la mise en cache avec la preuve.
STOP SI :  Il y a plus d'une implémentation de session — dites-le moi, ne choisissez pas.

QUESTION : Que conclut ce post-mortem d'incident, et qu'a-t-il laissé en suspens ?
OÙ :    docs/incidents/2026-08-12.md
CONTEXTE :  Je suis sur le point d'ajouter une limitation de débit et je veux savoir si c'était la correction recommandée ou autre chose.
RETOUR :   <=150 mots : cause racine, correction recommandée, questions ouvertes. Citez la recommandation textuellement.
STOP SI :  Le document en référence un autre pour la recommandation — donnez-moi le chemin, ne résumez pas un résumé.

La ligne RETOUR est celle que les gens sautent, et c'est celle qui rend le résultat utilisable sans un deuxième aller-retour. Dites la forme.

La liste de contrôle des différenciateurs

Avant d'envoyer, parcourez cette liste. Chaque élément est une chose qu'un modèle fort fait par réflexe et qu'un modèle plus faible ne fait que lorsqu'on le lui dit :

• Réutilisation plutôt que création — nommé chaque assistant, client, type ou util existant qui doit être réutilisé au lieu d'être réinventé
• Convention — pointé vers un fichier à refléter, pour que le nommage, la structure et la gestion des erreurs correspondent sans un cours
• La mauvaise voie évidente — nommé l'approche qu'une personne raisonnable adopterait et pourquoi elle est erronée ici
• Cas limites — listé ceux qui comptent : vide, null, concurrent, hors ligne, la 31ème requête
• Politique d'échec — dit ce qui se passe lorsque la dépendance est en panne : échouer ouvert, échouer fermé, réessayer, dégrader
• Valeurs spécifiques — vrais noms, vrais chemins, vrais nombres. Ratelimit.slidingWindow(30, "1 m"), pas « une limite raisonnable »
• Invariants — ce qui ne doit pas changer : noms exportés, signatures publiques, chemins de stockage, tests existants
• L'astuce — la bizarrerie de la bibliothèque, la configuration qui n'est pas détectée depuis l'environnement, l'étape de build que le mode dev saute
• Clôture de périmètre — nommé les choses adjacentes qui ne font PAS partie de cette tâche
• **

…

[tronqué pour la traduction]