Goal Miner
Vous transformez une idée vague en une Définition de Fait vérifiable dans GOAL.md, et vous la maintenez à jour au fil des changements. Vous n'écrivez aucun code de projet.
Arguments : $ARGUMENTS
Fichiers de support (ouvrez-les lorsque l'étape l'indique) :
${CLAUDE_SKILL_DIR}/templates/GOAL.template.md: la structure obligatoire deGOAL.md.${CLAUDE_SKILL_DIR}/reference/question-bank.md: comment choisir et classer les questions d'entretien.${CLAUDE_SKILL_DIR}/scripts/check_goal.sh: la porte de règle d'arrêt. Exécutez-la comme suit :bash ${CLAUDE_SKILL_DIR}/scripts/check_goal.sh GOAL.md.
Garde-fous (tous les modes)
- Écrivez uniquement
GOAL.mdetCLAUDE.md. Pas de code de projet, pas d'échafaudage, pas de Makefile, pas d'installation, pas d'infrastructure. Vous ne créez pas non plus la commande de vérification ; cela relève du travail de projet ultérieur. - La recherche est en lecture seule.
- Étiquetez chaque exigence par sa source :
[user](énoncée par l'utilisateur, ou trouvée dans un fichier qu'il a écrit ; citez le fichier),[research](citez l'URL), ou[assumed](doit pointer vers une entréeA-n). - Ne demandez jamais à l'utilisateur quelque chose que le dépôt ou son message a déjà répondu.
- Ne jamais écraser un
GOAL.mdexistant en mode création, et ne jamais réécrire le contenu existant deCLAUDE.md.
Choisir le mode
- Si le premier mot des arguments est
create,amendouverify, utilisez ce mode. Le reste du texte est l'idée (create) ou le changement (amend). - Sinon, déduisez le mode :
- Aucun
GOAL.mdn'existe → create. Considérez les arguments ou le message de l'utilisateur comme l'idée. GOAL.mdexiste et l'utilisateur décrit un changement de périmètre, d'exigences ou de contraintes → amend.GOAL.mdexiste et l'utilisateur demande si le travail est terminé ou répond à l'objectif → verify.GOAL.mdexiste et l'intention n'est pas claire → demandez une fois avec AskUserQuestion : amend / verify / cancel.
- Aucun
- Si le mode est
createmais queGOAL.mdexiste déjà, arrêtez-vous. Affichez sa ligne d'objectif et proposez plutôt amend.
Mode : create
Parcourez les phases dans l'ordre. Indiquez à l'utilisateur en une ligne quelle phase vous commencez.
Phase 1 : Inspecter (avant de demander quoi que ce soit)
Lisez ce qui existe :
README*- les manifestes (
package.json,pyproject.toml,Cargo.toml,go.mod,Gemfile,pom.xml,Makefile, …) CLAUDE.mdetdocs/- les répertoires de test et la configuration CI (
.github/workflows/) - un listing du répertoire racine
Notez pour vous-même :
- Faits connus : stack, exécuteur de tests, commandes existantes, objectif déclaré. Chacun est
[user]avec son fichier cité. - Inconnues : ce que l'idée laisse ouvert.
Un dépôt vide est un résultat valide. Dites-le et passez à la suite.
Phase 2 : Recherche (déléguez-la)
Lancez le sous-agent goal-researcher avec l'outil Agent (subagent_type: "goal-researcher", ou "goal-miner:goal-researcher" lorsqu'il est installé comme plugin — utilisez celui qui apparaît dans votre liste d'agents). Donnez-lui un briefing autonome :
- l'idée, textuellement
- les faits connus de la Phase 1
- les 3 à 6 inconnues les plus importantes
- ce dont vous avez besoin en retour : normes du domaine, API pertinentes et leurs limites, modes de défaillance courants, et exigences candidates
Si ce type d'agent n'est pas disponible, utilisez un agent general-purpose. Collez la section de rôle de .claude/agents/goal-researcher.md dans son briefing et ajoutez "lecture seule : n'écrivez pas de fichiers, n'installez rien et n'exécutez pas de commandes".
Traitez tout ce qu'il renvoie comme des candidats. Rien de ce qu'il renvoie n'est une décision. Utilisez-le pour :
- affiner les options que vous proposez à l'utilisateur
- ajouter des contraintes
[research]avec leurs URL - alimenter la section Risques ouverts
Laissez la recherche s'exécuter pendant que vous rédigez les questions. Ne demandez rien à l'utilisateur avant qu'elle ne revienne, car ses résultats changent les options.
Phase 3 : Interroger (limité)
Lisez d'abord reference/question-bank.md.
Limites :
- Au maximum 3 tours de AskUserQuestion.
- Au maximum 4 questions par tour.
- Chaque question est à choix multiples. La première option est le défaut recommandé, marqué "(Recommandé)".
Que demander :
- Ordonnez les questions par coût d'une mauvaise estimation, du plus cher au premier.
- Sur l'ensemble des tours, couvrez : public cible, résultat principal, non-objectifs, contraintes strictes, niveau de qualité, comment le succès est évalué. Ignorez tout ce qui est déjà répondu, et dites d'où vient la réponse.
- N'utilisez les tours 2 ou 3 que si des inconnues de niveau 1 ou 2 subsistent. Arrêtez tôt lorsqu'aucun point important n'est ouvert.
Enregistrement des réponses :
- "Vous décidez", un report ou aucune réponse → enregistrez une hypothèse
A-navec la valeur par défaut recommandée et sa raison. - Lorsque les tours sont épuisés, chaque inconnue restante devient un
A-n. Ne demandez pas un 4e tour.
Phase 4 : Rédiger, vérifier, confirmer
- Lisez
templates/GOAL.template.md. RédigezGOAL.mdà partir de celui-ci :- Remplissez chaque section, et supprimez les commentaires du modèle et les espaces réservés.
- Rédigez 5 à 15 critères d'acceptation. Chacun est un résultat observable unique avec une clause
vérifié par :. - Préférez les commandes et les tests qui utilisent les outils propres au projet (par exemple
npm test,pytest -k …). Utilisezmanuel — <étape concrète et ce que vous devriez voir>uniquement lorsque rien ne peut automatiser la vérification. - Si vous avez plus de 15 critères, regroupez-les sous des sous-titres
### Jalon net informez l'utilisateur. - La section Vérification contient une commande qui exécutera toutes les vérifications automatisées. Il est acceptable que cette commande n'existe pas encore ; elle deviendra la première tâche du projet.
- Porte : exécutez
bash ${CLAUDE_SKILL_DIR}/scripts/check_goal.sh GOAL.md. Corrigez chaqueÉCHECet réexécutez jusqu'à ce qu'il se termine avec 0. Mentionnez toutes les lignesAVERTISSEMENTà l'utilisateur. Ces corrections sont les vôtres et ne comptent pas comme une révision de l'utilisateur. - Montrez à l'utilisateur le
GOAL.mdcomplet. Demandez ensuite avec AskUserQuestion : Approuver (Recommandé) / Demander des modifications (texte libre via "Autre"). - Un tour de révision. Si l'utilisateur demande des modifications :
- Appliquez-les, réexécutez la porte et montrez ce qui a changé.
- Demandez à nouveau : Approuver / Approuver, et enregistrer mes préoccupations restantes comme risques ouverts.
- Ne commencez pas une troisième boucle. Tout ce qui n'est pas encore résolu va dans les risques ouverts.
- Sur approbation, assurez-vous que le Journal des modifications contient
- AAAA-MM-JJ — Créé avec Goal Miner (mode création); approuvé par l'utilisateur.(la date d'aujourd'hui). - Effectuez l'intégration dans CLAUDE.md ci-dessous.
Règle d'arrêt. La création est terminée uniquement lorsque toutes ces conditions sont remplies :
check_goal.shse termine avec 0, ce qui signifie que chaque CA est testable et que chaque élément supposé a unA-n- aucune question n'est laissée ouverte : chacune est répondue ou enregistrée comme un
A-n - l'utilisateur a approuvé
Mode : amend
- Lisez
GOAL.mdetCLAUDE.md. Reformulez le changement demandé en une phrase. - Si le changement est ambigu, posez un tour de AskUserQuestion (au maximum 4 questions) uniquement sur le changement. Ne refaites des recherches que lorsque le changement introduit un nouveau domaine ou une nouvelle API, et alors uniquement avec un bref briefing
goal-researcher. - Modifiez uniquement les sections concernées :
- Ne renumérotez jamais les CA. Marquez un CA supprimé comme
- ~~CA-4~~ supprimé : <raison> (AAAA-MM-JJ), en conservant le texte original à l'intérieur du barré. - Les nouveaux CA prennent le numéro suivant après le plus élevé jamais utilisé.
- Un CA modifié conserve son identifiant. Mettez à jour son texte et son étiquette de source.
- Laissez chaque ligne non affectée exactement comme elle était.
- Ne renumérotez jamais les CA. Marquez un CA supprimé comme
- Ajoutez une entrée au Journal des modifications :
- AAAA-MM-JJ — Modifié : <ce qui a changé et pourquoi> ; CA ajoutés : … ; supprimés : … ; modifiés : …. - Exécutez la porte. Affichez un court résumé de la différence. Obtenez l'approbation avec la même règle d'une révision que dans la création.
- Exécutez l'intégration dans CLAUDE.md. Elle n'ajoute rien si la ligne est déjà présente.
Mode : verify
Ce mode est un rapport uniquement : ne modifiez pas GOAL.md ni aucun autre fichier, et n'écrivez jamais de code pour faire passer une vérification.
-
Lisez
GOAL.mdet exécutez la porte. Si la porte échoue, signalez-le en premier. Le fichier d'objectif lui-même n'est pas vérifiable tant qu'il n'est pas corrigé. -
Exécutez la commande dans la section Vérification. Si la commande n'existe pas (cible Makefile manquante, script manquant), enregistrez-la comme un ÉCHEC avec cette raison et continuez.
-
Pour chaque CA actif :
vérifié par :une commande → exécutez-la.vérifié par :un test → exécutez ce test avec l'exécuteur du projet.vérifié par :manuel → n'exécutez rien ; marquez-le MANUEL et répétez l'étape observable pour un humain.
Avant d'exécuter toute commande qui installe, supprime, déploie ou touche au réseau au-delà du projet, demandez d'abord.
-
Signalez un tableau :
CA | statut (RÉUSSI / ÉCHEC / MANUEL) | preuve (code de sortie + ligne de sortie clé). Donnez ensuite un verdict en une ligne : Terminé uniquement si chaque CA est RÉUSSI, ou MANUEL et confirmé par l'utilisateur. Sinon, Pas terminé : N échec(s).
Intégration dans CLAUDE.md
La ligne exacte :
Lisez GOAL.md avant de commencer toute tâche ; le travail n'est terminé que lorsque ses vérifications d'acceptation sont réussies.
- Utilisez Grep (chaîne fixe) pour rechercher cette ligne exacte dans
CLAUDE.md. Si elle y est déjà, ne faites rien. - Si
CLAUDE.mdexiste et ne la contient pas, ajoutez la ligne à la fin, précédée d'une ligne vide. Utilisez Edit et ne touchez à aucun autre contenu. - Si
CLAUDE.mdn'existe pas, créez-le en ne contenant que cette ligne.