wellwelwel/blue-spec

Simulation d'une commande Blue Spec

Ce skill existe parce que simuler une commande est trompeusement facile à mal faire, ce qui fait perdre du temps et de la confiance à l'utilisateur. Les sessions difficiles ont produit quatre règles non négociables et une méthode. Suivez-les exactement.

Utilisez ce skill chaque fois que l'utilisateur demande de « simuler », « démontrer », « montrer en pratique », « exécuter » ou « voir en action » n'importe quelle commande /bluespec.* (charter, detect, plan, harden, verify), ou de prévisualiser le comportement d'une commande avant de la déployer.

Avant de commencer (obligatoire)

Ne commencez pas une simulation, ne construisez pas un scénario et ne copiez pas un environnement de test tant que ces deux points ne sont pas réglés, dans cet ordre :

1. L'utilisateur doit vous dire quelle commande Blue Spec simuler. C'est obligatoire. Ne supposez jamais et n'en choisissez pas une. Si l'utilisateur n'a pas nommé de commande (charter, detect, plan, harden ou verify), demandez-lui laquelle avant de faire quoi que ce soit d'autre. S'il en a nommé plusieurs, confirmez l'ordre dans lequel vous les exécuterez.
2. Proposez ensuite l'environnement de test, sous forme de liste numérotée, et laissez l'utilisateur choisir. Une fois la commande connue, listez les environnements de test disponibles (dans .claude/skills/simulate/fixtures/) sous forme de liste numérotée, chacun avec une description d'une ligne de son scénario, et demandez à l'utilisateur d'en choisir un par son numéro. Ne choisissez pas un environnement par défaut en silence. S'il n'existe qu'un seul environnement, présentez-le quand même et confirmez avant de l'utiliser. Si aucun ne correspond à la commande, dites-le et proposez d'ajouter un nouvel environnement (voir la section des environnements de test).

Ce n'est qu'après que la commande est nommée et l'environnement choisi que vous procédez aux règles et à la méthode ci-dessous.

Pourquoi ce skill existe (lisez ceci d'abord)

Une commande Blue Spec n'est pas un programme autonome. C'est un fichier d'instructions (spec/commands/bluespec.<phase>.md, structuré comme un skill que l'agent lit) qui indique à un agent IA comment réaliser une phase de travail de sécurité. « Exécuter la commande » signifie qu'un agent suit ces instructions. Il n'existe pas de binaire qui émet un résultat déterministe indépendant de l'agent. Ainsi, une « simulation » est l'agent qui exécute les étapes de la commande pour de vrai, dans un scénario réel, tout en montrant son travail.

Le mode d'échec à éviter : raconter ce que vous imaginez que la commande afficherait, le formater pour ressembler à un terminal et le présenter comme si elle avait été exécutée. C'est du théâtre. L'utilisateur ne peut pas distinguer une sortie inventée d'une sortie réelle, et il aura (à juste titre) l'impression d'une supercherie. Tout ce qui suit est conçu pour rendre la simulation réelle et vérifiable par l'utilisateur, et non une performance.

Les quatre règles strictes

Règle 1 : Exécutez le scénario dans ./temp

Construisez tout ce que la simulation touche (l'environnement de test, les artefacts .bluespec/memory/ produits par les phases, toutes les entrées) à l'intérieur de ./temp à la racine du dépôt, jamais dans /tmp du système.

• /tmp est invisible pour l'utilisateur : il ne peut pas ouvrir ces fichiers dans son éditeur, donc tout ce que vous y faites devient « croyez-moi sur parole ». ./temp est dans son espace de travail, ouvrable, inspectable.
• ./temp est ignoré par git, donc la simulation ne pollue jamais les commits.
• Nettoyez ./temp lorsque l'utilisateur a terminé, ou laissez-le pour qu'il l'inspecte, mais demandez-lui d'abord.

Les environnements de test : commencez chaque simulation à partir de l'un d'eux

Des exemples de projets neutres sont fournis avec ce skill, chacun dans son propre répertoire sous .claude/skills/simulate/fixtures/<nom>/>. Choisissez l'environnement dont le scénario correspond à ce dont la commande a besoin, ou ajoutez-en un nouveau (voir ci-dessous). Chaque environnement est un petit projet réel qui contient délibérément à la fois du code robuste et du code fragile, en paires neutres afin que la commande doive analyser le code, et non lire une étiquette.

Environnements disponibles :

• image-upload-service : un petit service HTTP ESM qui accepte des téléchargements d'images et les renvoie.
• template-toolkit : un package npm ESM publiable (une bibliothèque plus un CLI tmpl) pour le rendu de modèles et l'analyse de texte.

Commencez toujours une simulation en copiant un environnement brut dans ./temp. Si ./temp existe déjà et n'est pas vide, videz-le d'abord, afin que chaque exécution démarre proprement (remplacez <nom> par l'environnement que vous avez choisi) :

rm -rf ./temp && mkdir -p ./temp
cp -R .claude/skills/simulate/fixtures/<nom>/. ./temp/

Ensuite, construisez la chaîne par-dessus dans ./temp en exécutant les phases amont pour de vrai (conformément à la Règle 4), de sorte que l'artefact .bluespec/memory/*.md que la commande lit soit produit par sa propre phase, et non écrit à la main. Exécutez les étapes de la commande dans ./temp, en suivant sa spécification à la lettre (conformément à la Règle 3), et montrez la sortie de chaque étape conformément à la Règle 2.

Pour ajouter un environnement, créez .claude/skills/simulate/fixtures/<nouveau-nom>/ comme un petit projet réel avec son propre package.json, gardez le code robuste et fragile en paires neutres, n'ajoutez pas de commentaires ou de noms révélateurs, et listez-le ci-dessus. Ajoutez-en un lorsqu'une commande a besoin de matériel que les environnements actuels ne couvrent pas (un langage ou une pile différents, la gestion des secrets, l'authentification, une base de données, etc.).

Règle 2 : Exposez les requêtes et les réponses sous forme de blocs de code dans le message de chat

C'est la règle qui a mis le plus de temps à être apprise. Lorsque vous exécutez un outil (Bash, Read), l'interface de l'utilisateur montre un aperçu tronqué de IN et OUT de cet outil. Vous ne contrôlez pas la quantité affichée, et elle est généralement coupée. Si la preuve qui étaye une affirmation ne vit qu'à l'intérieur de la sortie d'un appel d'outil, l'utilisateur ne la voit pas, et toute phrase que vous écrivez pour la décrire est perçue comme une invention.

Par conséquent :

• Après avoir exécuté un outil, copiez la sortie brute pertinente dans un bloc de code (triple backticks) dans votre message de chat normal. Le bloc de code s'affiche complètement et à l'identique dans toutes les interfaces. C'est ce que l'utilisateur entend par « lettres jaunes » : un bloc de code markdown.
• La requête et l'interaction de la commande (ce que /bluespec.<phase> montre pendant son exécution : le pas à pas, la décision de périmètre, les verdicts) vont également dans un bloc de code, stylisé comme une transcription.
• N'écrivez jamais « la sortie ci-dessus montre X » en pointant vers un appel d'outil. Pointez vers le bloc de code que vous avez collé, que l'utilisateur peut lire en entier.
• Lorsqu'un nombre ou une ligne dans votre transcription provient d'une exécution réelle, il doit correspondre à la sortie brute que vous avez collée. Si vous écrivez une ligne de transcription qui n'est pas étayée par une sortie brute collée, vous inventez, alors arrêtez-vous.

Un modèle fiable : exécutez la commande, redirigez la sortie brute vers un fichier dans ./temp (par exemple ./temp/run.log), puis utilisez Read sur ce fichier (le résultat de Read vous est montré en entier) et collez son contenu dans un bloc de code. L'utilisateur peut également ouvrir ./temp/run.log pour vérifier.

Montrez au fur et à mesure, jamais en lot à la fin. Le déclencheur est par étape : dès qu'une étape produit quelque chose que l'utilisateur doit voir (une entrée qu'elle a lue, sa transcription, l'artefact qu'elle a écrit), collez-le dans un bloc de code dans le même message, avant l'étape suivante. Si vous êtes sur le point de commencer la phase suivante ou une correction et que la sortie de l'étape précédente n'est pas encore à l'écran, arrêtez-vous et collez-la d'abord. Si l'utilisateur doit vous rappeler de montrer la sortie d'une commande, la règle a déjà échoué.

Règle 3 : Vous êtes la commande, alors suivez sa spécification à la lettre

« Exécuter la commande », c'est vous qui exécutez spec/commands/bluespec.<phase>.md étape par étape, et non qui faites la phase à votre manière en l'appelant la commande.

• Ouvrez d'abord cette spécification et traitez-la comme l'unique source de vérité. Suivez ses étapes dans l'ordre. N'exécutez pas la phase de mémoire ou à partir du résumé de ce skill.
• Effectuez chaque arrêt de confirmation que la spécification impose, pour de vrai. harden doit confirmer avant de modifier du code, une analyse detect complète doit être confirmée car elle consomme beaucoup de tokens. Présentez ce que la spécification dit de présenter, dans un bloc de transcription, et attendez. Ne modifiez jamais de code et n'exécutez pas une étape soumise à une confirmation sans avoir obtenu cette confirmation au préalable.
• Décidez du périmètre, des verdicts, des correctifs, des priorités et des conclusions comme les étapes de la spécification les décident, dans le scénario réel. Si vous ne pouvez pas pointer vers l'étape de la spécification qui justifie une ligne de sortie, vous agissez en tant que vous-même, alors arrêtez-vous et suivez la spécification.

Règle 4 : L'entrée de chaque phase doit provenir de l'exécution de la phase précédente, pas de vous

La chaîne est charter → detect → plan → harden → verify, chaque phase lisant ce que la précédente a écrit. Rédiger à la main un artefact en aval avec les réponses que vous attendez (un harden.md qui enregistre exactement ce que vous voulez que verify confirme ou détecte) est l'échec : la phase en aval est alors testée par rapport à votre prédiction, et non à la réalité, donc elle passe à côté de ce que vous avez manqué.

• Produisez chaque artefact amont en exécutant sa phase, sous sa propre spécification, montrée conformément à la Règle 2. Pour démontrer verify, exécutez detect (lit le code), puis plan (lit detect.md), puis harden (lit plan.md, modifie le code). Même lorsque l'utilisateur commence au milieu de la chaîne, construisez les artefacts manquants de cette façon, dans l'ordre.
• Laissez l'artefact dire ce que l'exécution a réellement produit, lacunes comprises : un Partial, un Blocked, une constatation que vous n'aviez pas prévue. Un artefact suspectement propre est le signe que cette règle a été enfreinte.
• Un scénario délibérément divergent est acceptable (harden applique tout, puis le code est restauré pour que verify doive détecter la dérive), mais introduisez la divergence visiblement (restaurez dans un appel d'outil montré, conservez les artefacts réels), jamais en écrivant à la main un enregistrement que l'exécution n'a jamais produit.

La méthode, étape par étape

Chaque phase lit la précédente et écrit un artefact. Connaissez cette chaîne et ne la brisez pas :

Phase	Lit	Écrit
charter	le contexte du projet	.bluespec/memory/charter.md
detect	le code	.bluespec/memory/detect.md
plan	uniquement detect.md, jamais le code	.bluespec/memory/plan.md
harden	uniquement plan.md plus la charte, et modifie le code de l'utilisateur	.bluespec/memory/harden.md
verify	harden.md et le code, confrontant l'enregistrement à la réalité, ne change rien	.bluespec/memory/verify.md

Ensuite, pour la commande que vous simulez :

1. Copiez l'environnement brut dans ./temp (Règle 1).
2. Construisez la chaîne en exécutant chaque phase amont, dans l'ordre, dans ./temp (Règle 4).
3. Exécutez la phase cible selon sa spec/commands/bluespec.<phase>.md, à la lettre (Règle 3).
4. Montrez chaque entrée, transcription et artefact dans un bloc de code au fur et à mesure (Règle 2). Écrivez chaque artefact de sortie comme un fichier réel, puis lisez-le et montrez-le.

Vérifications d'honnêteté avant de présenter quoi que ce soit

• Cela a-t-il réellement été exécuté, ou suis-je en train de taper ce que je pense qu'il se passerait ?
• Chaque ligne de transcription est-elle étayée par une sortie brute que j'ai collée, ou par un fichier ./temp que l'utilisateur peut ouvrir, plutôt que par un appel d'outil tronqué ? (Règle 2)
• Ai-je déjà collé la sortie de chaque étape jusqu'à présent, afin que l'utilisateur n'ait jamais à demander ? (Règle 2)
• Ai-je suivi la spécification de chaque phase, y compris les arrêts de confirmation, au lieu d'agir comme moi-même ? (Règle 3)
• Chaque artefact amont provient-il de l'exécution de sa phase, et non de ma rédaction du résultat que je souhaitais ? (Règle 4)
• Le scénario est-il dans ./temp, et non caché dans /tmp ? (Règle 1)

Si l'une des réponses est non, corrigez-la avant d'envoyer. L'utilisateur préfère voir une sortie réelle et modeste qu'une invention polie.