Bible de Conception de Flux de Travail — un générateur de constitution pour des projets autonomes pilotés par des agents

Ce qu'est cette compétence. Un méta-prompt système réutilisable. Lorsque l'utilisateur souhaite créer un nouveau projet autonome (chaîne de contenu/vidéo, livre électronique/édition, outil SEO/wiki, produit web, jeu occasionnel, …), cette compétence mène un entretien structuré court, puis remplit un système standard « constitution + documentation » : un fichier racine CLAUDE.md allégé (la constitution du projet) + un fichier documentation/configuration.json + un dossier documentation/ contenant des documents de référence uniques + des squelettes vides .claude/agents/, .claude/skills/, reflections/, reports/.

Ce que cette compétence ne fait pas. Elle n'exécute aucun code métier, n'écrit aucune logique applicative, et ne déploie rien. Elle se contente de réaliser l'entretien → générer le squelette de documentation + les registres. La véritable CLI (factory.py / press.py / etc.), les prompts système des sous-agents réels, et chaque compétence fonctionnelle sont développés plus tard par le PDG du projet et l'agent mainteneur.

Deux façons de l'utiliser. (1) Lire le document — copiez ce fichier dans n'importe quel LLM capable et suivez-le manuellement. (2) Installer la compétence — placez ce dossier dans le répertoire des compétences de votre environnement d'exécution d'agent (par exemple, un emplacement global skills/) afin qu'il se déclenche automatiquement lorsque vous démarrez un nouveau projet.

Les modèles se trouvent à côté de ce fichier, de sorte que la constitution reste allégée :

templates/CLAUDE.md.template — le squelette de constitution à remplir.

templates/configuration.json.template — la source unique de vérité de la marque.

Tout au long de ce document : « PDG » = l'agent principal/orchestrateur ; « l'utilisateur » = le propriétaire humain/président qui définit la direction et approuve. Les noms de fichiers comme CLAUDE.md sont des conventions — remplacez-les par ce que votre environnement d'exécution lit comme instructions de premier niveau pour l'agent (par exemple, AGENTS.md).

A. Les huit philosophies de conception non négociables

Ces huit philosophies sont l'âme de la Bible. Chaque constitution générée doit incarner les huit — elles ne sont pas optionnelles, elles sont le fondement.

Philosophie 1 · L'agent principal est un PDG, pas un exécutant

Le travail de l'agent principal est d'orchestrer, superviser, réviser, contrôler le processus, et dialoguer avec l'utilisateur — pas d'effectuer lui-même le travail manuel. Consacrez son contexte et son raisonnement au jugement et à la coordination. Chaque étape fixe et répétitive est déléguée par défaut à un sous-agent.

Philosophie 2 · Tout est un sous-agent ; la concurrence est le pouvoir latent par défaut

Chaque étape de travail fixe est attribuée à un sous-agent au rôle clair. Comme le travail est façonné pour les sous-agents, il est naturellement parallélisable :

Les étapes indépendantes → sont déployées en parallèle (par exemple, compilation / couverture / rédaction en parallèle).
De nombreuses tâches homogènes d'un même type → exécution concurrente par lots (par exemple, 60 scènes, 50 en vol).

Exprimez la concurrence aux points de déploiement du pipeline (une section dédiée « parallélisme »), pas comme une comptabilité sur chaque agent. Mise en garde contre la prolifération excessive : si un moteur/codebase partagé sous-tend de nombreux artefacts, préférez un agent mainteneur partagé à un mainteneur par artefact — ne divisez un rôle que lorsqu'un artefact a des dépendances véritablement distinctes.

Philosophie 3 · Architecture à quatre couches (PDG → Sous-agent SP → Compétence → MCP/CLI)

Les capacités sont hiérarchisées ; chaque couche pointe vers le bas, et les détails ne remontent jamais :

① PDG (CLAUDE.md)            — assigne le travail, définit les principes, ne touche pas aux détails
   ↓ répartit un sous-agent avec un brief de tâche autonome
② Sous-agent (son prompt système)
   — définition du rôle + « quelles compétences ce rôle doit principalement utiliser » (pointeurs)
   ↓ invoque une compétence
③ Compétence (sa SKILL.md)
   — comment une capacité est utilisée ; déclare quels serveurs MCP et quelles commandes CLI la composent
   ↓ exécute
④ Serveurs MCP + outils en ligne de commande (exécutés, jamais chargés dans le contexte)

Discipline clé : un sous-agent peut voir un grand nombre de compétences globales et locales, mais voir ≠ devrait utiliser. Son prompt système doit explicitement restreindre (« votre travail utilise principalement la compétence X / Y ») afin qu'il ne saisisse pas des outils au hasard.

Philosophie 4 · Source unique de vérité + pointeurs ; la constitution ne gonfle jamais

CLAUDE.md ne conserve que les éléments les plus critiques et les plus clairs : définitions des rôles, principes d'exploitation/gestion/orchestration, la colonne vertébrale du pipeline (étape par étape), et la cartographie des fichiers. Toutes les connaissances communes / sources uniques de vérité concrètes descendent dans des documents autonomes sous documentation/ ; la constitution ne contient qu'un pointeur + une ligne de contexte. De même, repoussez les détails des rôles dans le prompt système de chaque sous-agent — le PDG n'a pas besoin de savoir comment un rôle fonctionne, seulement qu'il existe ; il lit ce prompt lorsqu'il a besoin du détail.

Pourquoi : CLAUDE.md est présent dans le contexte à chaque interaction. Les détails écrits à l'intérieur sont une surcharge, brûlant des jetons, à chaque tour.

Philosophie 5 · Couches de capacités à deux niveaux : global (réutilisation) vs local (construction)

Chaque constitution divise les capacités en deux et indique aux sous-agents la limite :

Global (réutilisation, pas construit ici) : compétences / MCP / sous-agents partagés entre tous vos projets (une capacité de messagerie, un générateur d'images, un assistant de recherche, divers agents opérateurs). Appelez-les directement, coût de construction nul.
Local (construit/fourché pour ce projet) : la CLI spécifique au projet, les compétences du projet, les sous-agents du projet.
⚠️ Piège de portée : une compétence limitée au répertoire d'un autre projet ne se chargera pas automatiquement ici ; forkéz une copie réduite ou appelez l'équivalent global. Indiquez cela dans la constitution générée.

Philosophie 6 · La réflexion et l'auto-itération sont toujours la dernière étape — et il y a deux boucles

La colonne vertébrale de chaque pipeline se termine par Réflexion et Auto-itération : examinez les défauts + l'efficacité de ce cycle → attribuez les causes profondes → demandez à l'agent mainteneur d'améliorer le processus → consolidez. L'objectif est de transformer régulièrement ce qui est « encore décidé à la volée » en « maintenant figé dans une fonction déterministe. » Aucune revue d'auto-itération = la boucle ne s'est pas fermée. Deux boucles distinctes existent ; la constitution doit les garder séparées :

Boucle A — réflexion par cycle (fin de chaque exécution du pipeline) → écrire dans reflections/ (permanent ; jamais dans un répertoire de build qui est nettoyé).
Boucle B — revue asynchrone inter-sessions : une tâche planifiée écrit un rapport de données/analyses dans reports/ ; le rituel de démarrage de la session suivante scanne reports/, adopte/rejette, puis archive. De plus, une note HANDOFF transporte les affaires inachevées entre les sessions.

Philosophie 7 · La constitution en tant que code : une auto-vérification déterministe garantit que les affirmations == la réalité

Une constitution dérive : elle prétend avoir « 9 sous-agents, 7 compétences » alors que le système de fichiers dit le contraire. Ainsi, chaque projet embarque une commande déterministe doctor / de vérification de cohérence qui vérifie ce que la documentation prétend par rapport à ce qui existe réellement (agents, compétences, sous-commandes CLI, nombres d'actifs, la base de données lifeline) et termine avec un code non nul en cas de dérive. C'est le filet de sécurité automatique pour la règle de « cohérence de propagation » : tout changement de feuille (CLI/compétence/SP/modèle) doit, avant d'être terminé, reconfirmer les contrats des couches supérieures — et doctor l'applique mécaniquement.

Philosophie 8 · Forme standard (constitution racine + documentation/)

Le dossier du projet a une forme fixe dès sa création :

<projet>/
├── CLAUDE.md              ← constitution : principes / colonne vertébrale / pointeurs / carte (résident dans le contexte)
├── documentation/         ← chaque source unique de vérité / connaissance commune / configuration (chargé à la demande)
│   ├── configuration.json      configuration structurée de la marque (source unique de vérité)
│   ├── INITIALIZATION.md       configuration de déploiement unique
│   ├── reflection_playbook.md  la procédure pas à pas pour l'étape de réflexion
│   ├── <playbook>.md           playbooks thématiques (contrôle qualité / SOP du sujet / conformité / …)
│   └── …
├── .claude/agents/        ← prompts système des sous-agents (définitions des rôles)
├── .claude/skills/        ← chaque SKILL.md (définitions des capacités)
├── <core>.py / <core>/    ← code CLI déterministe (exécuté, jamais dans le contexte)
├── reflections/           ← rapports de réflexion par cycle (permanent)
├── reports/               ← rapports de données/analyses asynchrones (consumés au démarrage de la session)
├── HANDOFF.md             ← transfert inter-session du travail inachevé
├── CHANGELOG.md
└── <lifeline>.db          ← le magasin de mémoire lifeline (ignoré par git)

B. Ce qu'une exécution de cette compétence livre

Livrable	Chemin	Contenu
Constitution du projet	`<projet>/CLAUDE.md`	Remplie à partir de `templates/CLAUDE.md.template` (allégée, basée sur des pointeurs).
Configuration de la marque	`<projet>/documentation/configuration.json`	Remplie à partir de `templates/configuration.json.template`.
Document d'initialisation	`<projet>/documentation/INITIALIZATION.md`	Liste de contrôle des identifiants + étapes de déploiement unique (squelette).
Documents thématiques de référence	`<projet>/documentation/<sujet>.md`	Les règles identifiées lors de l'entretien qui n'appartiennent pas à la constitution (un fichier chacune).
Squelettes vides	`.claude/agents/`, `.claude/skills/`, `reflections/`, `reports/`, `HANDOFF.md`	Créez les répertoires + un fichier `.gitkeep` ou README factice pour chacun.

Non généré : code métier, contenu réel des prompts système des sous-agents, implémentations réelles des compétences — ceux-ci sont développés après l'existence du projet. Cette compétence produit uniquement les registres + squelette + espaces réservés, en enregistrant à l'avance quels rôles et capacités devraient exister dans CLAUDE.md.

C. Protocole d'interaction (l'entretien d'admission)

Effectuez l'entretien avant de générer. Interrogez par cycles ; proposez des options à choix multiples chaque fois que possible pour minimiser la saisie de l'utilisateur. Après chaque cycle, répétez la réponse pour confirmer, puis passez à la suite. Objectif : remplir chaque {{espace_réservé}} dans les modèles.

Règles d'efficacité pour l'intervieweur :

Le modèle PDG, les cinq/six règles principales et l'architecture à quatre couches sont des constantes pour tous les projets — ne posez pas de questions à leur sujet ; ils viennent préremplis du modèle.

Pour les capacités globales, inspectez d'abord automatiquement l'environnement hôte (examinez les compétences disponibles / les types de sous-agents / les serveurs MCP que votre environnement d'exécution expose) et proposez une liste de réutilisation que l'utilisateur pourra confirmer ou réduire — ne demandez pas à l'utilisateur de les rappeler de mémoire.

Regroupez les questions connexes (jusqu'à ~4 à la fois). Visez à terminer en 3 à 4 cycles, pas 7.

Cycle 0 · Archétype du projet (sélectionne la branche du modèle de pipeline)

Demandez quel archétype est le projet ; chacun précharge un brouillon de colonne vertébrale différent :

Archétype	Colonne vertébrale typique (brouillon préchargé, puis ajustez avec l'utilisateur)
Contenu — vidéo/chaîne	sujet → script → rendu → publication → engagement/commentaires → réflexion
Contenu — livre électronique/édition	thèse → écriture → compilation → distribution multi-canal → marketing → optimisation → réflexion
Actif de trafic SEO (outil-site/wiki)	sujet → construction → livraison → monétisation → SEO/surveillance → réflexion
Produit/site web	exigences → conception → construction → test → déploiement → surveillance → réflexion
Jeu occasionnel	concept → production d'actifs (concurrence par lots intensive) → construction → test → publication → ajustement des données → réflexion
Autre (personnalisé)	co-concevez la procédure pas à pas à partir de zéro

Cycle 1 · Mission, étoile polaire et lignes rouges

Mission en une phrase (devient l'étoile polaire du PDG).
3 à 5 contraintes non négociables par ordre de priorité (la plus ancienne surpasse toujours la plus récente). Guidez l'utilisateur pour réfléchir à la chaîne (par exemple, « sécurité du compte > qualité du contenu > quantité > vitesse > revenu par unité »).
La loi de fer / ligne rouge de conformité n°1, le cas échéant (« la violer et tout est perdu » — par exemple, anti-spam de la plateforme, anti-déchet IA du marché, conditions d'utilisation).
« À ne pas faire » (deux niveaux) : ce qui est Interdit (actions de ligne rouge qui peuvent annuler l'ensemble du projet) vs Déconseillé (à éviter sauf si justifié). Ceux-ci remplissent la section « À ne pas faire » du modèle, parallèlement aux Règles.

Cycle 2 · Marque (→ configuration.json)

Marque / nom de code ? Entité d'attribution (vrai nom ? pseudonyme ? entreprise) ? Par langue ?
Slogan / accroche ?
Actifs de logo (existants) ?
Langage de conception : couleurs primaires, polices, mots-clés de ton, style visuel, tabous.
Ancre de confiance / E-E-A-T (identité du site / de l'auteur) ?
Entité de paiement / de compte (si monétisé) ?

Cycle 3 · Colonne vertébrale du pipeline (étape par étape)

En partant du brouillon de l'archétype, fixez chaque étape : ce qu'elle fait → sa sortie → le rôle principal.
Marquez les étapes qui peuvent s'exécuter en parallèle (les points de déploiement).
Confirmez que la dernière étape = réflexion et auto-itération.

Cycle 4 · Rôles (répartition des sous-agents) + capacités globales/locales

Un sous-agent par étape fixe : nom + rôle en une ligne + étape concernée.
Il doit toujours y avoir un dev-mainteneur (possède tous les changements de code/SP/compétence).
Appliquez la règle anti-prolifération : préférez un seul mainteneur partagé à moins qu'un artefact n'ait des dépendances distinctes.
Confirmez la liste de réutilisation globale inspectée automatiquement ; listez les compétences locales à construire/forker — et pour chaque compétence locale, quels serveurs MCP + quelles commandes CLI la composent (Philosophie 3, couche ③).
Pour chaque sous-agent, nommez les compétences qu'il doit principalement utiliser (le pointeur dans son prompt système).

Cycle 5 · Mémoire lifeline + documents de référence + phase/identifiants

De quel magasin de mémoire à long terme le projet a-t-il besoin (base de données de portefeuille d'actifs / stockage vectoriel de déduplication / registre de progression…) ? Quels champs ?
Quelles règles sont des « sources uniques de vérité » et devraient chacune devenir un documentation/<sujet>.md ? (conformité, SOP du sujet, contrôle qualité, tarification, discipline de montée en puissance…) Enregistrez chacune.
Phase actuelle ? Cadence de montée en puissance / discipline de risque ?
Quels identifiants privés / comptes externes l'utilisateur doit-il fournir (→ INITIALIZATION.md) ?
La limite pour « seulement deux raisons de s'arrêter et de demander à l'utilisateur » (identifiant manquant / jugement commercial subjectif).

Lorsque l'entretien est terminé, répétez chaque champ clé rempli et confirmez avant d'écrire des fichiers.

D. Règles de génération

Copiez templates/CLAUDE.md.template, remplacez chaque {{…}}, supprimez les sections optionnelles qui ne s'appliquent pas (par exemple, pas de monétisation → retirez la section de tarification).
Copiez templates/configuration.json.template, remplissez la configuration de la marque.
Créez documentation/INITIALIZATION.md : liste de contrôle des identifiants, étapes de déploiement ; marquez les champs {{…}} restants pour que l'utilisateur les remplisse lorsqu'il déploie.
Pour chaque règle de référence identifiée lors du Cycle 5, créez documentation/<sujet>.md avec un titre et une section « Référence » vide (l'utilisateur la remplit plus tard).
Créez les répertoires squelettes (.claude/agents/, etc.) avec un .gitkeep vide à l'intérieur de chacun.
NE générez PAS le code CLI, les prompts système des sous-agents, ni les implémentations des compétences.

E. Intégration du système de fichiers (check-list de la compétence)

workflow-design-bible/

├── SKILL.md               ← ce fichier
├── templates/
│   ├── CLAUDE.md.template
│   └── configuration.json.template
├── .gitignore
└── README.md

preangelleo/workflow-design-bible

Qu'est-ce que workflow-design-bible ?

Demander à votre IA préférée

Documentation