toyin-software-factory/audit

Style de sortie (mots simples, pas de tirets, pas de césures)

Écrivez tout ce que cette compétence produit, fichiers et messages, dans un langage simple et clair. Parlez au lecteur en utilisant vous, chaleureux et direct comme un collègue, et présentez chaque étape comme une recommandation qu'il peut exécuter ou ignorer, jamais comme un ordre. Conservez les termes techniques qui ont un sens réel ; expliquez chacun en termes simples. N'utilisez jamais de tiret ou de césure comme ponctuation : pas de tiret cadratin, pas de tiret demi-cadratin, et pas de composés avec trait d'union. Écrivez read only, pas read-only. Dites-le en mots simples, ou reformulez la phrase. Le code, les chemins de fichiers, les indicateurs de commandes et les valeurs sur lesquelles d'autres compétences s'alignent conservent leurs traits d'union. Utilisez des phrases courtes, des virgules ou des parenthèses. La clarté prime sur l'ingéniosité.

Ce que fait cette compétence

L'amorceur de contexte : écrit les fichiers AGENTS.md que toutes les compétences ultérieures et les outils IA lisent.

• Greenfield (pas encore de code) : demandez les standards de codage, amorcez le AGENTS.md racine à partir des réponses plus l'approche de construction (nom et principe en une ligne) de l'en-tête de périmètre si /scope en a défini un. S'exécute après que le projet a été structuré avec sa pile choisie (/scope → /architect décide la pile → structure → /audit) ; plus tôt est prématuré.
• Brownfield, non documenté (code, pas de AGENTS.md) : analysez l'ensemble du projet, écrivez le AGENTS.md racine et les fichiers <zone>/AGENTS.md imbriqués, en jugeant ce qui est global (racine) vs spécifique à une zone (imbriqué).
• Brownfield, partiellement documenté : vérifiez la documentation racine et imbriquée existante par rapport à l'ensemble de la base de code ; ajoutez uniquement ce qui manque (nouveaux faits globaux, documents imbriqués pour les zones non documentées) ; ne détruisez jamais le contenu existant.

Ne crée pas de spécifications (/architect en est propriétaire), ne maintient pas les fichiers après les modifications (/sync en est propriétaire), et n'écrit pas le périmètre des fonctionnalités (/scope est propriétaire de docs/scope/).

Convention des fichiers de contexte (AGENTS.md est canonique)

Le contexte durable réside dans le AGENTS.md agnostique (racine et imbriqué) ; chaque agent (Codex, Cursor, Claude Code, et autres) le lit. CLAUDE.md est seulement un pointeur d'une ligne dont le corps entier importe le AGENTS.md frère via l'import @ de Claude Code (corps exact du pointeur dans agent-prompt.md) ; le contenu n'est jamais dupliqué entre les deux.

• Écrivez la connaissance dans AGENTS.md. Créez-le lorsqu'il manque. Ne remplacez jamais un AGENTS.md existant (il peut être rédigé par l'utilisateur ou un outil) ; comblez les lacunes avec parcimonie, avec permission.
• Migrez le contenu hérité : un CLAUDE.md avec du contenu mais pas de AGENTS.md → demandez la permission, déplacez son contenu dans un nouveau AGENTS.md, remplacez CLAUDE.md par le pointeur. Ne jetez jamais silencieusement du contenu existant.
• La racine reste courte et globale ; les AGENTS.md imbriqués uniquement pour les zones significatives avec de véritables conventions (mêmes règles racine/imbriqué que précédemment appliquées à CLAUDE.md).

Périmètre

Un argument de chemin de zone (par exemple auth, src/payments) déclenche la Phase 3. Sans argument, les signaux de Pré-vol ci-dessous dirigent vers la Phase 0 (ambigu : demander nouveau vs existant), Phase 1 (greenfield : demander les standards, amorcer la racine), Phase 2 (établi, pas de AGENTS.md racine : analyse de tout le dépôt), ou Phase 4 (AGENTS.md racine existe : combler les lacunes). Un CLAUDE.md hérité avec du contenu mais sans AGENTS.md est migré, puis traité comme Phase 4.

Actions vs demandes

La Phase 1 pose des questions sur les standards de codage via QCM avant de créer le AGENTS.md racine. La Phase 2 agit immédiatement, sans questions ; elle écrit la racine et les documents imbriqués qu'elle juge justifiés. Les Phases 3 et 4 agissent pour explorer mais demandent la permission avant de modifier un AGENTS.md racine existant ou de migrer un CLAUDE.md hérité ; la Phase 4 signale d'abord la création de documents imbriqués pour les zones non documentées, puis applique sur confirmation.

Propriété des artefacts

Les fichiers AGENTS.md contiennent le contenu : créez la racine si elle manque (Phase 1, 2) et <zone>/AGENTS.md si elle manque et est justifiée, par jugement (Phase 2, 3, 4) ; lorsqu'il en existe un, comblez les lacunes ou proposez des ajouts avec permission ; ne remplacez jamais. Les fichiers CLAUDE.md sont uniquement des pointeurs (racine et zone), créés s'ils manquent ; un fichier hérité avec du contenu est migré dans AGENTS.md avec permission. Lors de la création d'un AGENTS.md imbriqué, ajoutez exactement une ligne de pointeur vers le AGENTS.md racine sous ## Fichiers de contexte : - [<zone>/AGENTS.md](<zone>/AGENTS.md) (<description en une ligne>). Jamais un par sous-dossier, uniquement là où des conventions distinctes existent.

Portabilité (tout OS, tout agent)

• Commandes : git est le seul CLI requis, identique sur tous les OS. Les autres extraits shell (comptes de fichiers, find, [ -f ]) sont des références POSIX, pas des scripts littéraux ; utilisez les outils de fichiers multi-plateformes de votre agent (recherche/glob, lecture, écriture) pour lister, compter et vérifier l'existence.
• Les fichiers fournis se trouvent dans le dossier de cette compétence : agent-prompt.md, les fichiers de mode de phase (modes/*.md), et les préréglages de modèles (patterns/*.md). Résolvez le dossier en un chemin absolu. Lisez le fichier de mode correspondant lors du routage, puis agent-prompt.md plus le préréglage SÉLECTIONNÉ au moment de l'écriture. Ses espaces réservés en MAJUSCULES (PHASE, AREA, ADDITIONAL_STANDARDS, MONOREPO_OR_NO, INSTALLED_SKILLS, DECLINED_TOOLS, et ainsi de suite) sont les entrées que vous avez recueillies lors du pré-vol et des tours de questions ; appliquez chacun au fur et à mesure de votre lecture.
• Pas de support de questions interactives ? Posez toute question à choix multiples comme texte brut avec les mêmes options.

Exécution

Le thread principal fait l'écriture dans chaque phase ; il ne confie jamais l'écriture de AGENTS.md à un sous-agent. Le seul sous-agent est un éclaireur en lecture seule (modèle le moins cher, Claude Code : haiku, jamais le modèle de session), invoqué uniquement pour une analyse volumineuse ; il retourne une carte compacte à partir de laquelle le thread principal écrit. Une petite structure ou une zone unique n'a pas besoin d'éclaireur ; lisez-la directement. Juste avant d'écrire, lisez agent-prompt.md (persona, instructions par phase, modèles), plus, en Phase 1, le préréglage de modèle sélectionné ; puis écrivez en le suivant. Lisez agent-prompt.md uniquement au moment de l'écriture, pas pendant le pré-vol.

Pré-vol (le thread principal fait ceci avant toute autre chose)

Recueillez plusieurs signaux (un simple comptage de fichiers est trompeur : une structure le gonfle, un langage inconnu le réduit à zéro) :

1. Fichiers de contexte : racine AGENTS.md présente → ROOT_EXISTS ; un CLAUDE.md avec du contenu uniquement → ROOT_LEGACY ; aucun → ROOT_MISSING.
2. Comptage de sources dans les écosystèmes courants (extensions comme .ts/.tsx/.js/.jsx/.py/.go/.rs/.java/.rb/.swift/.kt/.php/.cs/.dart/.ex/.exs/.scala/.c/.cpp/.h/.lua/.clj), en excluant les répertoires fournis/générés (node_modules, .git, dist, build) et les fichiers de configuration (*.config.*).
3. Signaux établis : git log --oneline pour la profondeur de l'historique des commits ; un manifeste réel (package.json, pyproject.toml, go.mod, Cargo.toml, composer.json, *.csproj, pubspec.yaml, mix.exs, Gemfile).
4. Signal monorepo : marqueurs d'espace de travail (pnpm-workspace.yaml, turbo.json, un champ "workspaces" dans package.json) ou tout apps/*/package.json / packages/*/package.json près de la racine.
5. Signal de configuration du workflow (WORKFLOW_SETUP) : la racine AGENTS.md est MANQUANTE alors que le workflow a déjà décidé la pile, c'est-à-dire qu'une spécification d'architecture docs/specs/ existe (une section ## Pile proposée), et/ou que docs/scope/ a une fonctionnalité "Pile et architecture" (ou structure similaire fondamentale). C'est l'ordre greenfield prévu (/scope → /architect décide la pile → /develop la structure → /audit) : fraîchement structuré, a encore besoin de capturer les standards de codage. Lorsqu'il se déclenche, le manifeste et les sources de la structure qui existent maintenant sont la structure, pas une base de code existante.

Choisissez la phase. L'ordre des vérifications a de l'importance : le signal de configuration du workflow l'emporte sur le simple comptage de code, car une structure fraîche a un manifeste et des fichiers sources mais est encore greenfield.

Condition	Phase
Chemin de zone donné comme argument	Phase 3
ROOT_EXISTS (ou ROOT_LEGACY après migration)	Phase 4
ROOT_MISSING et WORKFLOW_SETUP (spécification de pile et/ou fonctionnalité de périmètre de pile)	Phase 1, même si un manifeste et des sources de structure existent maintenant. Demandez les standards de codage ; amorcez la racine à partir de la pile de la spécification. Ne traitez jamais un projet workflow juste structuré comme brownfield.
ROOT_MISSING, aucun WORKFLOW_SETUP, aucun fichier source ET aucun manifeste	Phase 1
ROOT_MISSING, aucun WORKFLOW_SETUP, a du code (source ≥ 10 ou un manifeste), ≥ 2 commits et clairement du code de fonctionnalité réel (pas seulement une structure)	Phase 2, n'importe quel langage
ROOT_MISSING, aucun WORKFLOW_SETUP, a du code mais qui ressemble à une structure non modifiée, ou ≤ 1 commit, ou vous ne pouvez pas distinguer greenfield de brownfield	Phase 0, demandez

Pourquoi cet ordre : une structure fraîche a un manifeste et des fichiers de démarrage mais est encore greenfield, donc un simple comptage de code le lirait à tort comme brownfield et sauterait les questions sur les standards ; le signal de configuration du workflow attrape cela et redirige vers greenfield. Un véritable brownfield (Phase 2) signifie du code de fonctionnalité réel, un historique réel, et aucun workflow en cours. Tout ce qui est ambigu tombe en Phase 0 ; ne considérez jamais par défaut un projet peut-être greenfield comme brownfield.

Monorepo (MONOREPO=oui) : racine plus un stub léger par espace de travail, approfondir à la demande. Chaque espace de travail (apps/*, packages/*) est une zone de première classe ; son document principal réside à la racine de l'espace de travail (packages/api/AGENTS.md), jamais enterré plus profondément. Une analyse de tout le dépôt ne scanne pas en profondeur chaque espace de travail ; écrivez le AGENTS.md racine du dépôt (outillage à l'échelle du monorepo, conventions partagées) plus un stub léger par espace de travail à partir de son manifeste, sans analyse de code, avec des pointeurs racine. L'analyse complète des conventions/pièges/fichiers clés se produit lorsque l'ingénieur exécute /audit packages/api (Phase 3) ou construit d'abord là-bas. Un endroit à l'intérieur d'un espace de travail qui justifie son propre document (packages/ui/src/mdx/) en reçoit un en plus du document racine de l'espace de travail, lié à partir de celui-ci. Un document déjà enterré dans un espace de travail sans document racine d'espace de travail : demandez : "packages/ui a un fichier de contexte dans src/mdx/ mais aucun à sa racine. Le déplacer vers packages/ui/AGENTS.md, ou le garder comme document imbriqué sous un nouveau packages/ui/AGENTS.md ?" En cas de déplacement : relocalisez-le à la racine de l'espace de travail. En cas de conservation imbriquée : créez le AGENTS.md racine de l'espace de travail ET conservez le document profond, lié à partir de la racine. Migrez le contenu hérité de CLAUDE.md selon la convention ci-dessus. Appliquez MONOREPO=oui plus la liste des espaces de travail lors de l'écriture.

Migration héritée (toute phase) : sur ROOT_LEGACY, avant de procéder, demandez la permission : "J'ai trouvé un CLAUDE.md avec du contexte de projet mais pas de AGENTS.md. Je vais déplacer son contenu dans un nouveau AGENTS.md (afin que tous les outils le lisent) et remplacer CLAUDE.md par un pointeur. Continuer ?" En cas d'acceptation : copiez le contenu textuellement dans AGENTS.md, puis remplacez CLAUDE.md par le pointeur ; AGENTS.md existe maintenant, donc continuez en Phase 4 (comblement des lacunes). En cas de refus : laissez les deux intacts et continuez sans migrer. Idem pour tout <zone>/CLAUDE.md imbriqué.

Router vers la phase sélectionnée

La Phase 0 (ambiguë) est traitée en ligne ci-dessous. Pour les Phases 1 à 4, lisez uniquement le fichier de mode correspondant, puis suivez-le :

• Phase 1 (configuration greenfield) → modes/greenfield.md
• Phase 2 (analyse de tout le dépôt) → modes/whole-repo.md
• Phase 3 (analyse de zone) → modes/area.md
• Phase 4 (comblement des lacunes) → modes/gapfill.md

Ne lisez pas les autres fichiers de mode. Les modes greenfield et tout le dépôt lisent en plus modes/tool-skills.md pour la revue des Compétences d'Agent / MCP (ignorez-la pour les analyses de zone et de comblement).

Phase 0 : Classifier (uniquement lorsque le pré-vol est ambigu)

Ne devinez pas. Demandez une fois via le sélecteur d'options interactif de votre agent (AskUserQuestion sur Claude Code), ou texte brut avec les mêmes options. Marquez une option (recommandée) selon le signal le plus fort (un arbre de type structure avec un manifeste mais peu d'historique penche pour Nouveau ; du code de fonctionnalité réel et un historique profond penche pour Existant), et le sélecteur ajoute un emplacement personnalisé libre en dernier :

• question : "Je n'arrive pas à déterminer s'il s'agit d'un nouveau projet ou d'une base de code existante (<expliquez pourquoi : par exemple 'un manifeste existe mais je ne vois aucune source dans un langage que je reconnais', ou 'les fichiers ressemblent à une structure non modifiée'>). De quoi s'agit-il ?"
• en-tête : "État du projet"
• options : 1. Nouveau projet, "Je demanderai vos standards de codage et amorcerai le contexte." → Phase 1 (lisez le manifeste/la structure pour la pile ; demandez toujours les standards). 2. Base de code existante, "Je vais analyser ce qui est présent et le documenter." → Phase 2.

Après toutes les phases

Si aucun AGENTS.md n'a été écrit alors qu'il aurait dû l'être (le fichier est manquant/vide), signalez l'échec et recommencez ; ne rapportez pas un succès qu'il n'a pas produit. Sinon, rapportez le compte rendu : ce qui a été découvert (2 à 4 puces), ce qui a été écrit (chemins de fichiers), ce qui a été proposé ou ignoré (si des fichiers existants ont été trouvés).

Préréglages de modèles

Voir patterns/ pour les quatre préréglages de style de codage utilisés en Phase 1 (mode greenfield).

Guide d'écriture

Voir agent-prompt.md (le thread principal le lit au moment de l'écriture ; ses instructions par phase et ses modèles AGENTS.md).