Samuele95/prometheus

Que fait prometheus ?

Un framework général de méta-prompting pour élaborer des prompts destinés aux agents LLM. Fonctionne avec n'importe quel CLI agentique (Claude Code, Gemini CLI, Cursor, etc.) et pour une utilisation non-CLI. Couvre les sept formes de prompts : boucles agentiques, tâches ponctuelles, chaînes de workflows, prompts de sous-agents, personas système, évaluateurs LLM-as-judge et équipes d'agents.

Le framework est construit sur l'ingénierie de contexte classique (la "bonne altitude" d'Anthropic, le "plus petit ensemble de jetons viable", "les exemples plutôt que les règles") et sur des principes sémantiques quantiques (les prompts sont des opérateurs, pas une recherche de clé ; l'ordre est structurel ; l'ambiguïté est une fonctionnalité ; la combinaison n'est pas additive).

Quand utiliser cette compétence

Déclencher lorsque l'utilisateur commence un travail de conception de prompt pour un agent LLM. Formulations courantes :

• "Aide-moi à écrire un prompt pour [tâche]"
• "J'ai besoin d'un prompt système pour [objectif]"
• "Configure-moi un prompt [Claude Code / Gemini CLI / etc.] pour [projet]"
• "Conçois un prompt LLM-as-judge pour [évaluation]"
• "Je construis un sous-agent qui fait [X], aide-moi à rédiger ses instructions"
• "Démarre une boucle agentique pour [tâche]"

Ne pas déclencher pour : des questions-réponses simples, des demandes de complétion de code, ou des tâches où l'utilisateur veut la réponse, pas un prompt pour obtenir la réponse plus tard.

Position centrale : les prompts sont des opérateurs

Le recadrage le plus profond sur lequel repose ce framework, issu de la littérature sémantique quantique : un prompt n'"extrait" pas la bonne réponse d'un modèle. Un prompt est un opérateur qui construit une réponse par transformation de l'état sémantique du modèle. Chaque section d'un prompt est une matrice qui amplifie certaines interprétations, en supprime d'autres, mélange des états de base pour produire des lectures nouvelles.

Ce n'est pas une métaphore. Cela change la pratique de conception :

• On ne "trouve pas les bons mots-clés" — on conçoit des transformations.
• L'ordre est structurel — les opérateurs ne commutent pas.
• Combiner des sections produit une interférence, pas une addition.
• Chaque instruction détruit de l'information ; concevoir en conséquence.
• L'ambiguïté dans l'intention de l'utilisateur est une superposition, pas un défaut à éliminer.

La compétence applique ces principes concrètement, pas comme une décoration. Voir references/quantum-principles.md pour le mapping opérationnel et operators/ pour le catalogue des sections en tant qu'opérateurs.

Trois modes de fonctionnement

Le framework fonctionne selon l'un des trois modes, en fonction de ce que l'utilisateur apporte :

Mode from-scratch (par défaut). L'utilisateur décrit une tâche ; le framework produit un prompt. Six phases : inférence de forme → entretien adaptatif → rédaction par conception d'opérateurs → audit → évaluation honnête → livraison.

Mode refactor. L'utilisateur a un prompt existant et souhaite l'auditer, le corriger ou le réécrire. Six phases (1R à 6R) : réception et analyse → entretien de récupération d'intention → sélection du mode (audit / refactor ciblé / réécriture complète) → application du mode → évaluation honnête → livraison. Procédure complète documentée dans references/refactor-mode.md.

Mode manage. L'utilisateur pointe vers un package d'agent géré existant et souhaite le piloter tout au long de son cycle de vie — surveiller ses exécutions, analyser une violation d'objectif, l'adapter, l'arrêter et le redémarrer avec le même état interne. C'est le framework en tant que gestionnaire d'agent, pas seulement un concepteur : une boucle MAPE-K (Monitor / Analyze / Plan / Execute) sur le prompt de l'agent, exprimée via l'algèbre des opérateurs. Procédure complète dans references/manage-mode.md ; disposition du package, cycle de vie et journal dans references/agent-state.md.

Détection de mode. Détection automatique du mode refactor lorsque le message d'ouverture de l'utilisateur inclut un prompt collé suivi d'une demande d'audit, d'amélioration, de correction ou de refactor. Les invocations directes comme "refactoriser ce prompt", "auditer ce prompt", "qu'est-ce qui ne va pas avec ce prompt" déclenchent immédiatement le mode refactor. Détection automatique du mode manage lorsque l'utilisateur pointe vers un chemin de package d'agent existant ou invoque un verbe de cycle de vie contre lui — "gérer cet agent", "exécuter un cycle d'adaptation", "pourquoi mon agent a-t-il régressé", "redémarrer mon agent". En cas d'ambiguïté de détection (un prompt est collé mais la demande n'est pas claire), demander une fois : "Je vois un prompt — voulez-vous que je le refactorise, ou l'utilisiez-vous comme contexte pour une tâche différente ?" Par défaut, passer en mode from-scratch sauf si les signaux de refactor ou de manage sont clairs.

Les trois modes partagent l'infrastructure (le catalogue de formes, le catalogue d'opérateurs, la liste de contrôle d'audit, les spécifications de vérificateur) mais exécutent des procédures différentes. Le mode manage en particulier réutilise les mécanismes from-scratch et refactor comme sous-routines (la liste de contrôle d'audit, les sous-modes de refactor, le vérificateur inter-exécutions) plutôt que d'ajouter de nouveaux mécanismes analytiques. La procédure from-scratch suit ; la procédure refactor est dans references/refactor-mode.md ; la procédure manage est dans references/manage-mode.md.

Procédure from-scratch (six phases)

Phase 1 — Inférence de forme, pas de routage

La description de la tâche de l'utilisateur arrive comme un état sémantique en superposition. Ne posez pas de question de routage. Inférez la forme à partir des signaux déjà présents, dans l'esprit de l'échantillonnage bayésien §2.4.

1. Lisez attentivement la demande de l'utilisateur. Extrayez les signaux : verbes (construire / rédiger / classer / noter / évaluer / extraire / résumer), noms (système / document / pipeline / boucle / agent / persona / juge), marqueurs d'échelle (ponctuel vs continu, multi-tour vs appel unique), et mentions d'outils (Claude Code, Gemini CLI, etc.).

2. Générez une distribution a posteriori interne sur les formes plausibles. Le catalogue de formes est dans templates/shape-catalog.md. Ne vous engagez pas encore — conservez les poids.

3. Choisissez la forme avec la masse a posteriori la plus élevée uniquement si la deuxième forme est clairement en retrait. Si deux formes ou plus sont dans ~30% l'une de l'autre, l'inférence est ambiguë et vous devez la lever via une question de clarification ciblée. Formulez-la comme un choix forcé entre les deux premières formes, pas comme une question de routage ouverte.

4. Le domaine (ingénierie / recherche / rédaction / ops / générique) est un axe secondaire, orthogonal à la forme. Inférez-le de la même manière. Un prompt ponctuel de rédaction et un prompt d'ingénierie agentique appliquent tous deux ce framework, juste avec un contenu de section différent.

5. Détectez les signaux de raisonnement difficile lors du même passage. Les tâches mathématiques / logiques, la planification multi-étapes, l'analyse ou le débogage de code, les problèmes à contraintes multiples, ou toute tâche où l'utilisateur mentionne que le modèle échoue au premier essai sont des signaux que l'échafaudage d'outils cognitifs (selon references/reasoning-patterns.md) devrait être une valeur par défaut structurelle dans la rédaction, pas une extension optionnelle. Deux signaux ou plus + runtime d'appel d'outil → inclure l'échafaudage sur les niveaux legacy et strong, où le résultat empirique cité s'applique. Sur le niveau frontier, l'échafaudage est une option déclenchée par M5, pas une valeur par défaut — voir references/reasoning-patterns.md §gating de niveau.

6. Inférez le niveau de capacité du substrat — un troisième axe, orthogonal à la forme et au domaine, lu à partir de la réponse du runtime : frontier (les modèles les plus récents du runtime avec une grande capacité à suivre les instructions), strong (modèles grand public actuels), legacy (modèles plus anciens ou plus petits). Inconnu → supposer strong. Conditions de niveau : force d'opérateur par défaut dans la Phase 3 (Principe 9 dans references/quantum-principles.md — les opérateurs prescriptifs sur-projettent sur les substrats à haute capacité de suivi d'instructions), seuils de déclenchement de l'échafaudage (point 5 ci-dessus), disponibilité du préremplissage, et conseils sur les paramètres de contrôle du raisonnement dans la Phase 6.

Phase 2 — Entretien adaptatif (conscient des opérateurs)

L'entretien est lui-même une séquence d'opérateurs appliqués à l'intention de l'utilisateur. Selon §5.6, chaque question réduit l'ambiguïté de manière irréversible. Ne réduisez pas trop vite.

Règles de conduite :

• Limitez à 6 questions plates au total, y compris toute question de désambiguïsation de la Phase 1 (3 universelles — le contexte de déploiement est à ignorer quand il est évident — plus 2–3 spécifiques à la forme). Plafond dur. Les passages de co-rédaction (Formes 3, 6, 7) sont exemptés selon les règles de conduite de templates/interview-branches.md.
• Une question par tour. Les tours à questions multiples produisent des réponses moins profondes.
• Ignorez les questions dont les réponses sont déjà dans la demande de l'utilisateur. Re-demander est une répétition qui détruit l'information.
• L'ordre des questions est important (§2.3, §5.1). Posez d'abord la question de cadrage la plus large, puis les contraintes de rétrécissement, et enfin le formatage. La première question définit le sous-espace dans lequel toutes les questions suivantes opèrent.
• Préservez la superposition lorsque le coût de demander est faible et le coût de se tromper est élevé (§4.1). Pour les choix de niveau architectural (forme, public, outil), préservez. Pour les choix tactiques (nom de fichier, capitalisation), prenez une valeur par défaut et passez.

Les banques de questions par forme se trouvent dans templates/interview-branches.md. Deux questions sont universelles pour toutes les formes :

1. Outil / runtime. "Où ce prompt sera-t-il exécuté ? (Claude Code, Gemini CLI, API OpenAI, LLM générique, autre ?)" Influence la dénomination des fichiers mémoire et les fonctionnalités spécifiques à l'outil.
2. Définition de "terminé" / critère de succès. "Comment saurez-vous que le prompt a fonctionné ? Vérifiable, pas basé sur une impression." Fournit la grille d'auto-évaluation dans la Phase 5.

Terminez l'entretien par une réduction récapitulative : énoncez la forme que vous avez inférée, les contraintes clés que vous avez recueillies, et les valeurs par défaut que vous attribuez à tout ce qui n'est pas spécifié. Donnez à l'utilisateur une chance de modifier avant de rédiger. C'est l'étape de mesure délibérée (§1.2) — rendez-la explicite pour que l'utilisateur puisse s'opposer à la réduction.

Phase 3 — Rédaction par conception d'opérateurs

La rédaction est une conception d'opérateur (§5.3), pas un remplissage de section. Pour chaque section que vous incluez :

1. Identifiez les états de base que la section transforme — quelles interprétations doivent être amplifiées, supprimées ou mélangées ?
2. Choisissez la force — les opérateurs forts (persona, contraintes dures) projettent agressivement ; les opérateurs faibles (préférences de style, formatage) commutent avec la plupart des autres. Calibrez la force par défaut en fonction du niveau de substrat (Principe 9) : sur le niveau frontier, préférez des instructions générales brèves plutôt que l'énumération et réservez le langage intense ("CRITIQUE", "DOIT", interdictions répétées) pour les contraintes ayant des modes de défaillance démontrés ; sur les niveaux legacy, une projection plus forte est souvent justifiée. Le verrouillage de capacité pour les rôles à capacité destructrice reste en couches et fort à tous les niveaux — sa justification est le risque, pas la faiblesse du substrat.
3. Placez dans la séquence d'opérateurs selon §5.1 : le cadrage le plus large d'abord, le rétrécissement ensuite, le formatage en dernier.
4. Vérifiez l'interférence avec les sections adjacentes (§5.4) — la combinaison produit-elle un comportement émergent, intentionnel ou non ?

Utilisez templates/shape-catalog.md pour les épines dorsales spécifiques à la forme. Utilisez operators/ pour les descriptions d'opérateurs par section (ce que chaque section amplifie, supprime, mélange ; sa force ; ses propriétés de commutation). Pour les tâches qui ne justifient pas une sélection complète de forme (petites, bien définies, à objectif unique), templates/minimum-viable-prompt.yaml est l'échafaudage de repli — six emplacements (système / instructions / exemples / contraintes / état / requête) et rien de plus.

Pour les tâches à raisonnement intense où la décomposition structurée surpasse la chaîne de pensée monolithique, consultez references/reasoning-patterns.md — il documente le sous-modèle d'outils cognitifs (IBM Zurich, +16.6% sur AIME2024) et quand l'invoquer à l'intérieur de la forme choisie.

Lorsque la sortie du prompt sera consommée par un autre agent LLM plutôt qu'affichée à un humain (le plus courant dans la Forme 4 pour les prompts de sous-agents/outils et la Forme 6 LLM-as-judge), consultez references/agent-consumability.md. La conception de la sortie change lorsque le consommateur est un agent : marqueurs d'échec facilement trouvables par grep, structure d'abord agrégée, sortie standard compacte avec journaux verbeux, échantillonnage déterministe mais différent, et transitions d'état visibles.

Pour la Forme 7 (équipe d'agents), le choix de la topologie est fondamental et doit précéder la rédaction par rôle. Consultez references/agent-team-topologies.md pour les quatre topologies canoniques (orchestrator-workers, parallelization-sectioning, parallelization-voting, evaluator-optimizer) avec leurs profils d'opérateurs, définitions de rôles et modes de défaillance courants. Choisissez la topologie d'abord, puis rédigez le prompt de chaque rôle en utilisant l'épine dorsale de sa forme individuelle, puis auditez la cohérence entre les rôles.

Des règles de rédaction universelles s'appliquent à toutes les formes :

• Bonne altitude. Suffisamment spécifique pour agir, flexible pour que le modèle puisse s'adapter. Le codage en dur fragile et les généralités vagues sont deux modes de défaillance.
• Plus petit ensemble de jetons viable. Supprimez tout ce qui ne répond pas à un mode de défaillance spécifique ou ne permet pas un comportement concret. Chaque jeton coûte de l'attention.
• Les exemples plutôt que les règles. Lorsqu'une règle est fondamentale, écrivez un exemple concret. Les exemples sont des opérateurs fondamentaux qui ancrent les instructions abstraites. Mais les exemples ont leur propre surface d'ambiguïté — tout jugement silencieux à l'intérieur d'un exemple devient une règle que le modèle rétro-ingénierie. Avant de fournir un exemple, demandez : qu'est-ce que cet exemple enseigne silencieusement au-delà de ce que j'ai prévu ? En cas de doute, remplacez-le par un cas plus propre.
• Ordre des sections par force d'opérateur. Les opérateurs les plus forts d'abord.
• Les modes de défaillance en tant que Ne PAS FAIRE. Chacun aborde un angle de risque spécifique connu avec une conséquence concrète. Les avertissements génériques gaspillent des jetons.

Phase 4 — Audit (structurel et quantique)

Exécutez la liste de contrôle d'audit dans references/audit-checklist.md. La liste combine des vérifications classiques d'ingénierie de contexte (bonne altitude, plus petit ensemble de jetons, exemples présents, durabilité du support à long horizon) avec des vérifications sémantiques quantiques :

• Catalogue d'opérateurs complet. Chaque section a un profil clair d'amplification/suppression/mélange. Aucune section n'est une "décoration".
• Ordre optimisé. Les opérateurs les plus forts en premier. Testez en échangeant mentalement les sections adjacentes et en demandant "cela change-t-il le comportement ?" Si oui, vous avez correctement identifié des paires non commutantes.
• Interférence vérifiée. Lorsque deux sections sont susceptibles d'interagir (par exemple, persona + ton + format), confirmez que la combinaison produit le comportement émergent prévu, pas une annulation non souhaitée.
• Préservation de l'information. Le contexte important est chargé le plus tôt possible (il survit à plus de projections). Les choses qui doivent rester ambigües sont signalées comme telles, pas pré-réduites.
• Conscient de la mesure. Si le prompt contrôle une boucle agentique (forme 1), y a-t-il un point de mesure qui lit l'état (un fichier journal, un marqueur) et le fait ? Les boucles sans mesure dérivent.
• Vérification des modes de défaillance. Chaque Ne PAS FAIRE est-il lié à un mode de défaillance observé, ou s'agit-il d'un vœu pieux générique ?
• Conscient du substrat. Le prompt suppose-t-il une capacité de modèle, un comportement d'API ou une disponibilité d'outil que le runtime cible pourrait ne pas fournir ?
• Conscient du cycle de vie. Si le prompt vivra plusieurs tours (boucle, équipe, workflow), y a-t-il un mécanisme pour l'état persistant, la mémoire et la détection de changement de tâche ?

Phase 5 — Évaluation honnête

Après la rédaction et l'audit, évaluez le prompt en tant que concepteur d'opérateurs, pas en tant que relecteur. L'évaluation honnête est un jugement structurel, pas un pouce vers le haut.

Utilisez le critère de succès de l'utilisateur (de la Phase 2) comme rubrique. Évaluez sur quatre axes :

1. Plausibilité de l'induction. La force des opérateurs, la séquence et l'interférence sont-elles compatibles avec le substrat cible ? Compte tenu de ce que nous savons sur la façon dont les modèles de ce niveau transforment les entrées, cette séquence d'opérateurs particulière produira-t-elle l'état de sortie attendu ?
2. Vérifiabilité. Le critère de succès de l'utilisateur peut-il être évalué par le prompt lui-même (vérificateur dans le prompt, appel d'outil de vérification, formatage de sortie qui permet une vérification automatique) ? Si le prompt ne peut pas s'auto-vérifier, notez-le comme un risque de dérive.
3. Parenthèse de coût. Le prompt est-il en dessous du plafond de jetons du runtime avec une marge suffisante pour la sortie ? Si proche de la limite, quelles sections sacrifier ?
4. Résistance au changement de domaine. Le prompt est-il fragile aux petites variations de la tâche de l'utilisateur, ou absorbe-t-il le bruit d'entrée avec élégance ?

L'évaluation ne doit pas être une liste de contrôle que vous cochez. C'est un test de résistance — essayez de casser le prompt. Pour chaque axe, écrivez une phrase sur la façon dont il échouerait, puis décidez si cet échec est acceptable ou si vous devez réviser.

Lorsque l'évaluation échoue, révisez en remontant d'une phase. Un problème d'interférence → Phase 4. Un problème de force d'opérateur → Phase 3. Un désalignement de forme → Phase 1. Ne faites pas de micro-ajustements à la surface lorsque le problème est structurel.

Phase 6 — Livraison et configuration d'exécution

Lorsque le prompt est prêt, livrez-le avec tout l'emballage dont l'utilisateur a besoin pour l'exécuter immédiatement.

• Instanciez le modèle en fonction de la forme et du runtime inférés. Pour Claude Code : prompt système dans CLAUDE.md, fichier de règles, ou message direct. Pour Gemini CLI : fichier de configuration ou invite en ligne. Pour les appels API : construisez l'objet messages avec les rôles corrects.
• Définissez la configuration d'exécution en fonction du niveau de substrat. Sur le niveau frontier, réglez max_tokens pour laisser de la place au raisonnement, et ajoutez des instructions de préremplissage (<thinking> ou équivalent) pour les tâches de raisonnement en plusieurs étapes. Sur les niveaux strong et legacy, incluez l'échafaudage d'outils cognitifs le cas échéant et réglez temperature en dessous de la valeur par défaut pour les tâches de classification/notation.
• Établissez les points de mesure. Si le prompt contrôle une boucle (forme 1, 4, 7), définissez le format de sortie que l'utilisateur doit surveiller : marqueurs de décision, comptes rendus d'étape, fichiers journaux. Dites à l'utilisateur ce qui signifie "marche" et ce qui signifie "dérive".
• Formatez la livraison comme un bloc de code (langage = type de prompt : yaml, xml, texte) que l'utilisateur peut copier-coller immédiatement. Si le prompt est destiné à un outil spécifique avec un format de configuration non standard (comme .cursorrules ou un fichier YAML), livrez-le dans ce format. N'omettez pas le bloc de code — c'est l'artefact livrable.
• Incluez les avertissements. S'il y a des risques connus (hémorragie de jetons sur des entrées longues, etc.), mentionnez-les. S'il s'agit d'un prompt à agent unique, rappelez à l'utilisateur de toujours superviser la première exécution.
• Fermez la boucle : demandez à l'utilisateur de confirmer que la sortie répond au critère de succès après trois exécutions. Si ce n'est pas le cas, le framework peut itérer.