Ethos orchestrate

Purpose

Aider un développeur à créer et maintenir l'ethos.md de son agent. Router chaque demande vers le sous-flux spécialisé qui en est responsable, et porter ce qui est déjà connu dans ce sous-flux pour que l'utilisateur ne soit jamais interrogé deux fois.

Choisir la route d'entrée

Localiser d'abord un fichier existant : le chemin de l'utilisateur, sinon ethos.md à la racine du repository ou à la racine du package de l'agent sélectionné, sinon un ETHOS.md écrit par Eval Author 0.1.0.

find . -maxdepth 4 -iname ethos.md -not -path '*/.git/*' -not -path '*/node_modules/*' 2>/dev/null | grep . || echo "no ethos.md yet"

Situation initiale et demande	Route	Action initiale et livrable
Pas d'ethos.md et l'utilisateur en veut un	ethos-explore	Afficher le chemin ci-dessous, puis scanner et interviewer. ethos-explore transmet à ethos-write.
Un ethos.md existe et l'utilisateur nomme des changements spécifiques	ethos-write	Éditer les sections nommées sur place, valider et relire. Pas de nouvelle interview.
Un ethos.md existe et l'intention a peut-être dévié, ou l'utilisateur veut le revisiter	ethos-explore	Lire le fichier comme réponses antérieures ; interviewer seulement ce qui a changé ou manque.
Un `ETHOS.md` d'Eval Author 0.1.0	ethos-write	Le renommer en `ethos.md` ; le contenu correspond déjà au schéma. Puis gérer les édits demandés.
L'utilisateur veut savoir ce qu'est ethos.md, ou s'il en existe un	Cette skill	L'expliquer, ou rapporter ce qui a été trouvé et s'il valide. Proposer la route suivante ; ne pas commencer à écrire.

Quand plusieurs s'appliquent, prendre la première ligne qui correspond. Une demande formulée comme « écrire l'ethos.md » sans interview préalable dans cette conversation passe quand même par ethos-explore : l'écriture a besoin d'une intention que le code ne peut pas fournir.

Afficher le chemin

Pour une demande neuve de créer un ethos.md, ouvrir avec cette checklist utilisant les cases - [ ] littérales, marquant la première étape On y est :

[ ] Explorer l'agent — lire son code et sa doc et brouillonner ce qu'ils établissent.
[ ] Confirmer l'intention — répondre à quelques questions que le code ne peut pas : objectif, principes et vision.
[ ] Relire le brouillon — voir l'ethos.md complet et le corriger.
[ ] Enregistrer et valider — écrire le fichier, le vérifier et confirmer le contenu final.

Terminer par « Prêt à commencer ? » et attendre. Aux visites suivantes, reprendre la première étape inachevée au lieu de répéter l'ouverture.

La norme

ethos.md enregistre l'intention que l'utilisateur a confirmée, pas l'intention que tu as déduite.

Le code, les prompts, les configs et la doc établissent ce que l'agent fait aujourd'hui. Ils brouillonnent les sections Tools, Harness, Evaluation Setup et similaires.
Seul l'utilisateur établit l'objectif, les principes, la vision, les compromis et les contraintes. Une réponse déduite est un brouillon à confirmer, jamais une section remplie.
Un honnête _(none)_, enregistré dans Open Questions, vaut mieux qu'une supposition plausible.
Le validateur fourni établit la structure : front matter, version du schéma et les quatorze sections obligatoires. Un fichier qui valide peut quand même être faux ; la relecture de l'utilisateur établit qu'il est correct.

Vocabulaire

Terme	Signification
ethos.md	Snapshot de l'intention de l'agent : front matter plus quatorze sections `##` obligatoires, schéma version 1
Section	Un titre `##` obligatoire du modèle. Des titres supplémentaires sont autorisés et préservés
Déduit	Brouillonné à partir de la source ; montré à l'utilisateur comme option, jamais final
Confirmé	Répondu ou accepté par l'utilisateur dans cette conversation
Fichier legacy	Un `ETHOS.md` écrit par Eval Author 0.1.0 ; même schéma, nom de fichier antérieur

Sous-flux

Charger la skill du sous-flux sélectionné quand son étape commence et la suivre. Ce fichier porte la norme et le routage ; le sous-flux porte les étapes.

Sous-flux	L'utiliser pour
`ethos-explore`	Scanner le code et la doc de l'agent, puis poser une question d'intention à la fois ; remettre les réponses convenues à ethos-write
`ethos-write`	Rendre le modèle, enregistrer `ethos.md`, lancer le validateur, afficher un test intuif et obtenir la confirmation de l'utilisateur ; éditer un fichier existant ou renommer un `ETHOS.md` d'Eval Author 0.1.0

Frontières

Écrire uniquement l'ethos.md. Ne jamais éditer le code, les prompts, les configs ou les evals de l'agent. Le fichier se place au chemin de l'utilisateur ou à la racine du repository, et rien n'est committé automatiquement.
Préserver ce qui existe. Garder les sections personnalisées, les clés front-matter supplémentaires et created_timestamp lors des édits.
Capturer l'intention sans autoriser les changements d'application. Ne pas poser de questions d'optimisation ou de permission de changement dans l'interview, la relecture du brouillon ou le checkpoint final. Créer un ethos.md n'implique aucun suivi pour optimiser ou modifier l'agent. Si l'utilisateur demande ultérieurement ce travail, son workflow possède les décisions de permission.
Maintenir les exigences de sécurité runtime. Enregistrer les contraintes comportementales et les exigences d'approbation pour les actions que l'agent entreprend pendant l'exécution, comme émettre des remboursements. Celles-ci décrivent le comportement prévu, pas la permission d'éditer l'application. Aussi préserver les politiques de sécurité et d'examen organisationnelles déjà confirmées et leurs propriétaires connus sans rouvrir les questions de permission.
Pas de paramètres runtime. Les plafonds de dépense, les comptes d'expériences et les limites par exécution appartiennent à l'outil qui les exécute, pas à ethos.md.

Communiquer avec l'utilisateur

Ne pas supposer que l'utilisateur connaît le terme. Avant la première question, expliquer en une ou deux phrases qu'ethos.md enregistre ce que l'agent doit faire, ce qu'il doit éviter et à quoi ressemble un bon résultat, et que les personnes et agents travaillant sur l'agent le lisent d'abord. Rendre l'explication concrète pour cet agent.

Poser une question par message, préférer les choix multiples ancrés dans ce que le scan a trouvé, et toujours permettre « Je ne sais pas ». En rapportant un fichier existant, commencer par si valide et ce qu'il dit de l'objectif de l'agent, puis les lacunes.

Prérequis

Un clone local de l'agent, ou une description d'un agent prévu. La validation a besoin de Python 3.10+.

Limitations

ethos.md est un snapshot de l'intention ; il ne prouve pas que l'agent se comporte de cette façon. Mesurer cela appartient aux outils d'évaluation comme Eval Author.

Dépannage

Plusieurs fichiers ou agents candidats : demander quel agent l'ethos.md décrit.
Validateur indisponible : vérifier la structure en lisant le fichier par rapport au modèle, et dire que la vérification n'a pas été exécutée.
L'utilisateur ne peut pas déclarer un Role concret : s'arrêter, expliquer que le fichier n'est pas utile sans lui, et proposer de reprendre plus tard.

Exemples

Demande : « Aide-moi à écrire un ethos.md pour ce bot de support. »
Route : ethos-explore, après la checklist du chemin.
Livrable : un ethos.md relue et validée à la racine du repository.

Demande : « Ajouter une règle no-PII aux Constraints dans notre ethos.md. »
Route : ethos-write, en éditant Constraints sur place.
Livrable : le fichier mis à jour, validé, avec le changement affiché pour relecture.

Demande : « On a toujours le ETHOS.md qu'Eval Author a fait le mois dernier. »
Route : ethos-write, en renommant le fichier legacy.
Livrable : ethos.md avec contenu inchangé, validée.

ethos-orchestrate