Prompter des agents
Le lecteur est un modèle compétent qui n'a aucun de votre contexte. Dites ce qui doit être vrai à la fin et pourquoi, et laissez-le planifier le chemin : une route écrite pour un travail que le modèle peut planifier est suivie fidèlement, erreurs comprises. L'emballage diffère — brief, passation, compétence — l'écriture, non.
Le cœur
Ce qui entre. Le test de la ligne : le lecteur pourrait-il déduire cela de la tâche et de son entraînement ? Les faits qu'il ne peut pas rechercher, les conventions de l'utilisateur, les contrats, les contraintes strictes et les critères de complétion échouent au test et restent. Les routes pour un travail planifiable réussissent le test et partent. Une liste de critères est un état final ; une liste d'étapes est une route.
Autonome. Une nouvelle session ne lit que le prompt et le disque. Chaque message porte l'ensemble complet des règles en vigueur avec les modifications appliquées sur place — jamais "comme avant, plus ces changements" — et chaque document reformule chaque règle permanente dont il dépend, jamais "comme dans le parent".
Le pourquoi, formulé positivement. Le modèle généralise à partir des raisons, donc chaque règle porte la sienne propre ("une ligne continue par paragraphe, parce que la zone de chat traite un saut de ligne comme intentionnel"). Énoncez le comportement cible ; une interdiction attire le comportement interdit dans le contexte et le rend plus disponible, donc ne l'utilisez que comme une barrière de sécurité, accompagnée de la cible positive. Le langage injonctif (DOIT, CRITIQUE, majuscules) surdéclenche sur les modèles actuels ; écrivez "utilisez X quand…".
Mots directeurs, un seul endroit, pas de no-op. Un mot que le modèle détient déjà (reçus, brouillard de guerre, boucle serrée) bat une phrase ; le terme propre de l'utilisateur bat les deux. Chaque sens vit à un seul endroit. Une phrase que le lecteur respecte par défaut coûte de la charge à ne rien dire : supprimez la phrase, pas des mots.
Anatomie d'un prompt
- Intention — le but plus large, qui il sert, ce que la sortie permet ; le modèle l'investit dans les micro-décisions que le prompt n'atteint jamais.
- État final — ce qui existe quand c'est fini, avec quelles propriétés, et ce que l'utilisateur peut maintenant faire. Vérifiable, et exhaustif : "chaque fichier modifié pris en compte" force un travail que "produire une liste de modifications" ne fait pas. Le format du livrable vit ici ; c'est une propriété, pas une procédure.
- Contraintes strictes — les inviolables : sources en lecture seule, budgets, terminologie, provenance. Les contraintes énoncées par l'utilisateur, telles qu'énoncées — jamais vos propres valeurs par défaut économiques.
- Points de contrôle — le seul endroit où la prescription appartient encore : quand faire une pause pour l'humain (une action destructive ou irréversible, un changement de périmètre réel, une contribution qu'eux seuls détiennent) et ce qui est hors périmètre.
- Clause de liberté — licence pour restructurer et contester. En cas d'ambiguïté, faites des appels de routine et énoncez l'hypothèse ; demandez quand la réponse pourrait éviter un problème plus tard, comme des interprétations menant à un travail sensiblement différent ou un choix coûteux à annuler. L'utilisateur accueille ces questions. Dans un run non supervisé, la question devient une règle avec une valeur par défaut sûre appliquée, et le travail continue.
- Vérifications — dans chaque brief : avant de signaler la fin, auditez chaque affirmation par rapport à un artefact de cette session, et dites clairement ce qui n'est pas vérifié ; cela élimine presque les rapports d'avancement inventés.
Les étapes ordonnées gagnent une place quand l'ordre compte (une migration, un protocole de sécurité) ou quand une étape sautée est l'échec ; là, une liste de contrôle que le lecteur copie et coche bat la prose.
Avant d'envoyer
Une procédure numérotée pourrait-elle devenir une phrase d'état final ? Chaque ligne restante est-elle une contrainte, un point de contrôle, une règle de vérification ou une spécification de livrable ? Une phrase laisse-t-elle le lecteur s'arrêter, ralentir ou réduire le périmètre pour une raison que l'utilisateur n'a pas énoncée ? Le lecteur aurait-il dû être assis dans cette conversation pour agir dessus ?
Branches
- Message unique à un lecteur que vous pouvez modéliser (envoi de sous-agent, prompt pour une autre session, passation, message à une IA externe) →
references/briefs.md - Brief pour un run non supervisé, ses mémos de point de contrôle et ses décisions, séquencement sous une fenêtre de clôture →
references/autonomous-runs.md - Document durable (compétence, CLAUDE.md, document de référence), et quand confier la création d'une compétence au
skill-creatord'Anthropic →references/skills-and-docs.md - Choix du modèle ou du niveau d'effort du lecteur, ou écriture pour Haiku ou Fable plutôt que pour Opus →
references/models.md