snuffish/plan

Skill : /plan — Gestionnaire de plan d'implémentation

Gère le plan d'implémentation actif (<préfixe>-plan_implémentation-<suffixe>.md) de la session. Cette skill possède le squelette du plan, ses valeurs de statut, son bloc de liens et sa révision (--review). Toute autre commande qui écrit ou lit un plan (/implement-feature, /problem, /refine, /pr-fix-pipeline, /proceed) utilise les définitions ici.

---

Modules

Les chemins sont relatifs au dossier réel de cette skill. Exécutez realpath sur le répertoire de base de la skill une fois (il peut s'agir d'un lien symbolique), puis résolvez chaque chemin à partir de là. Si un module ne peut pas être lu, arrêtez-vous et signalez le chemin. Ne continuez pas sans lui.

Lisez-les avant l'étape 1 :

• ../_modules/core.md
• ../_modules/artifact-protocol.md : écrit <préfixe>-plan_implémentation-<suffixe>.md dans le répertoire des artéfacts (artifact-protocol)
• ../_modules/project-profile.md : profil de base uniquement (pas de profil de commande), pour la révision (Cas D) ; lit les Références par couche, les Points de contact du contrat, la Chaîne de fratrie et un champ facultatif Vérifications de révision du plan

Références à la demande (references/) :

• references/review.md — cinq piliers de révision (Cas D étape 3) et modèle de rapport pour --review (Cas D) et l'auto-révision (Cas B étape 4)

---

1. Le contrat du plan

Valeurs de statut

La deuxième ligne d'un plan porte **Statut :** <valeur>, avec l'une des valeurs suivantes :

Valeur	Signification	Défini par
Brouillon	En cours d'écriture ; pas prêt pour la révision	Le rédacteur, pendant la rédaction
En attente de révision utilisateur	Complet et en attente à la porte	Le rédacteur, lors de la présentation
Approuvé	L'utilisateur a ouvert la porte ; l'implémentation est en cours	core › La porte /proceed
Terminé	Chaque phase dans le périmètre est réalisée et vérifiée	core › La porte /proceed

Une courte note peut suivre la valeur (Approuvé — phase 2 sur 3 terminée). Les lecteurs ne comparent que la valeur principale.

Squelette

<!-- artifact-owner: … -->                 <!-- artifact-protocol › Revendication -->

# Plan d'implémentation : <titre>

**Statut :** En attente de révision utilisateur
**Suffixe :** `<suffixe>`
**Entrées :** <liens d'investigation / révision / ticket, ou "aucun">
**Révision :** <_Cas D_ verdict après pliage> · <n> résultats pliés <!-- Cas B étape 4 -->

## 1. Contexte et objectif

## 2. Décisions <!-- tableau : décision · pourquoi -->

## 3. Changements proposés <!-- par phase ou par dépôt : [NOUVEAU|MODIFIER|SUPPRIMER] <chemin> — quoi et pourquoi -->

## 4. Plan de vérification <!-- commandes exactes, plus étapes manuelles -->

## 5. Risques <!-- tableau : risque · mitigation -->

## 6. Liste de tâches <!-- la liste de contrôle en direct : [ ] / [/] / [x] -->

## 7. Questions ouvertes <!-- questions non résolues ; toujours en dernier, le cas échéant ; chacune avec une recommandation -->

Une commande peut ajouter les sections dont elle a besoin (/implement-feature ajoute Révision utilisateur requise, Passage en aveugle et Ordre inter-dépôts). Elle conserve ces sept sections, dans cet ordre, afin que /plan, /plan --review et /proceed puissent les trouver. Questions ouvertes (questions non résolues) est toujours la dernière section ; une section ajoutée va avant elle.

Style

La règle de l'utilisateur (~/.claude/CLAUDE.md › Mode Plan) s'applique : extrêmement concis, la grammaire sacrifiée ; terminez par Étapes, puis Questions non résolues (chacune avec une recommandation, omises lorsqu'il n'y en a pas).

Tout rédacteur de plan l'applique à l'ensemble du fichier et à la réponse de chat qui présente le plan :

• Fragments, pas de prose : pas de paragraphes, pas d'explications en phrases complètes.
• Une idée par puce ; divisez une idée plus longue en sous-puces.
• Décisions et Risques sous forme de tableaux.
• Chaque question ouverte porte Recommandation : avec la réponse recommandée.
• Rien après Questions ouvertes. S'il n'y a pas de questions non résolues, notez "Aucune" (ou omettez).

Bloc de liens

Chaque réponse de chat qui présente un plan commence par le artifact-protocol › Bloc de liens de discussion (numéros de ligne réels provenant de grep -n '^#\{1,3\} ' <fichier> après l'écriture) liant Contexte et objectif, Changements proposés, Plan de vérification et Questions ouvertes, suivi de **Statut :** <valeur>. Une commande peut ajouter un résumé d'une ligne après chaque lien de section (/plan --review le fait).

---

2. Comportements principaux

Choisissez le cas parmi les arguments, la première correspondance gagne :

Arguments	Cas
Contient --review	D : réviser un plan
Commence par preview	C : prévisualiser
Aucun	A : nu
Tout autre	B : brouillon ou mise à jour

Cas A : Commande nue (/plan sans argument ni message)

1. Localiser le plan : recherchez <préfixe>-plan_implémentation-*.md dans le répertoire des artéfacts (artifact-protocol) et sélectionnez la famille selon artifact-protocol › Revendication › Lecteurs et sélection de famille (dites à l'utilisateur qu'il peut ignorer l'invite la prochaine fois avec /plan <suffixe>). S'il n'en existe aucun, dites-le et proposez d'en créer un à partir de la prochaine invite de l'utilisateur.
2. Afficher le bloc de liens (§1 Bloc de liens) pour le plan choisi, avec son Statut actuel. Ne modifiez rien et n'exécutez pas de commandes en arrière-plan.

Cas B : Commande avec instructions (/plan <instructions>)

1. Résoudre le suffixe contextuel selon artifact-protocol › règle 2.
2. Planifier, sans modifier le code :
   • Vérifiez d'abord l'existence d'une investigation. Si <préfixe>-investigation-<suffixe>.md existe dans le répertoire des artéfacts (artifact-protocol) et couvre ce sujet, construisez dessus : sa Graine de plan, ses Options et compromis et son Registre de confiance. Ne refaites pas la recherche qu'il documente déjà ; résolvez uniquement les ❓ Inconnu dont dépend le plan.
   • Sinon, recherchez le code pertinent en lecture seule. Si le sujet est vaste ou les inconnues substantielles, exécutez d'abord /investigate.
   • Concevez selon les propres conventions du projet : ses cahiers des règles de l'espace de travail, ses Références et son Profil à portée de projet (core › Précédence).
3. Écrire le plan dans le §1 Squelette, dans le répertoire des artéfacts (artifact-protocol) :
   • Nouveau plan : rédigez-le dans un chemin privé à la session, puis publiez-le avec Revendication (artifact-protocol › règle 4). Si le nom de base est pris, Revendication écrit …-2.md ; utilisez le chemin qu'il a imprimé et dites-le dans le chat.
   • Plan existant : mettez-le à jour uniquement si son marqueur de propriétaire nomme cette session, ou si l'utilisateur a nommé ce fichier et demandé sa mise à jour (artifact-protocol › règle 3). Sinon, écrivez une nouvelle révision via Revendication, et liez celle qu'elle remplace dans Entrées.
   • Définissez Statut sur En attente de révision utilisateur lorsqu'il est complet. Sous Antigravity, lors de l'écriture d'une copie d'artéfact en miroir à l'intérieur de <appDataDir>/brain/<conversation-id>/, définissez UserFacing = true et RequestFeedback = true dans ArtifactMetadata (omettez ArtifactMetadata sur le fichier du répertoire des artéfacts).
4. Auto-révision avant de présenter : lisez references/review.md et exécutez les Cas D étapes 2 à 3 sur le plan qui vient d'être écrit, dans le contexte principal. Utilisez ses piliers et ses sévérités. N'imprimez pas son rapport ni sa porte : cela fait partie de la rédaction, et l'utilisateur révise le plan plié.

   • Pliez chaque résultat dans le plan avant de le présenter :

     Résultat	Va dans
     🔴 / 🟡, vérifié (chemin:ligne rouvert)	Changements proposés, Liste de tâches, et une vérification Plan de vérification qui échoue sans le correctif
     🔴 / 🟡 nécessitant une décision utilisateur	Questions ouvertes, avec Recommandation :
     🟢	Appliquez si une ligne ; sinon supprimez
     Résultat rejeté	Risques, une ligne avec la raison

   • Relisez le plan une fois pour toute contradiction avec un correctif (une étape antérieure, un test, une ligne de décision), et corrigez-la.

   • Exécutez la révision une seule fois. Remplissez la ligne d'en-tête Révision : avec le verdict que le plan plié obtiendrait.

   • Exécutez-la sur chaque nouveau plan, et sur chaque mise à jour qui modifie Changements proposés ou Plan de vérification. Ignorez-la pour une mise à jour qui ne fait que cocher la liste de contrôle ou modifier le Statut.

5. Présenter le plan : le bloc de liens (§1 Bloc de liens), le verdict de révision et les résultats qui ont modifié la conception (une puce chacun), les décisions clés sous forme de puces fragmentaires, puis les questions ouvertes en dernier, chacune avec sa Recommandation : (§1 Style s'applique également à ce texte de chat : pas de paragraphes, pas de phrases complètes). Attendez que l'utilisateur ouvre la porte (core › La porte /proceed) avant toute modification de code.

Cas C : Commande de prévisualisation (/plan preview [cible])

Affiche un plan existant dans le panneau de prévisualisation de planification de l'hôte (en utilisant ExitPlanMode lorsque disponible), afin que l'utilisateur puisse le lire, commenter et approuver de manière interactive.

1. Résoudre le plan : Utilisez l'argument (chemin ou suffixe), le fichier de plan actif de la session ou la dernière famille de plans dans le répertoire des artéfacts (Cas A).
2. Vérification des capacités de l'hôte : Si l'hôte ne dispose pas de ExitPlanMode (comme Antigravity IDE), affichez le bloc de liens du plan (Cas A) et expliquez que l'hôte affiche les plans directement via des liens Markdown.
3. Entrer en mode plan et copier : Appelez EnterPlanMode, lisez le chemin du fichier de plan de l'hôte à partir du message système, et copiez le plan source dedans (en omettant le commentaire <!-- artifact-owner: … --> de début).
4. Ouvrir la prévisualisation : Appelez ExitPlanMode.
5. Gérer la décision :
   • Approuver : L'utilisateur a autorisé l'implémentation (core › La porte /proceed). Commencez l'exécution.
   • Continuer la planification / Commentaires : Restez en mode plan, transmettez les commentaires au Cas B pour mettre à jour le plan, et rouvrez la prévisualisation.
   • Fermé / Erreur : Signalez le statut et fournissez le lien du fichier.

Cas D : Commande de révision (/plan --review [cible])

Audit strict, en lecture seule, d'un plan d'implémentation, d'une proposition architecturale ou d'une conception de modification, avant toute écriture de code. Lecture seule jusqu'à /proceed (core › La porte /proceed) :

• Ne modifiez jamais de fichiers, n'exécutez pas de commandes modificatrices (migrations, commits, échafaudage) et ne commencez pas à implémenter, même lorsque le plan est parfait.
• Chaque réponse sous --review, y compris les suivis, commence par le bloc de liens : l'utilisateur ferme souvent l'onglet du plan et le rouvre à partir du chat.

Mauvais outil :

Situation	Utilisez plutôt
Un diff de code, une branche ou une PR plutôt qu'un plan	/code-review
Commentaires et votes d'un relecteur sur une PR	/pr-feedback-review
Recherche avant l'existence d'un plan	/investigate
Hypothèses cachées et modes de défaillance d'une conception	/what-am-I-missing

Lisez references/review.md et exécutez les Cas D étapes 1 à 4 (étape 1 : localiser le plan ; étape 2 : lire les règles du projet ; Cas D étape 3 : évaluer selon les cinq piliers + profil Vérifications de révision du plan ; étape 4 : afficher le bloc de liens et le rapport de révision), puis attendez à core › La porte /proceed.