goal-miner

Transforme une idée de projet vague en une Définition de Fait vérifiable (GOAL.md) avant d'écrire du code, la modifie lorsque le périmètre change, et vérifie si le projet l'atteint.

Qu'est-ce que goal-miner ?

Goal Miner est une compétence pour agents d'IA comme Claude Code qui agit comme un architecte de projet. Elle prend une idée vague (« Je veux construire… », « Nouveau projet ») et la transforme en une Définition de Fait vérifiable dans un fichier `GOAL.md` structuré, contenant des critères d'acceptation observables. Cela se produit en plusieurs phases : inspection du dépôt, recherche (avec un sous-agent), questions structurées à l'utilisateur, rédaction du fichier, vérification par un script de gate (check_goal.sh), et approbation par l'utilisateur. La compétence ne génère aucun code de projet, seulement les fichiers `GOAL.md` et `CLAUDE.md`. En mode `amend`, elle met à jour `GOAL.md` lorsque le périmètre change, en préservant les références des critères. En mode `verify`, elle exécute les vérifications spécifiées pour indiquer si le projet est terminé. L'outil est crucial pour éviter le *scope creep* et garantir une validation objective de l'achèvement, en se basant sur une traçabilité des exigences (source utilisateur, recherche, ou hypothèses).

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/GalacticChill/goal-miner/tree/main/skills/goal-miner

Installed? Explore more Développement et programmation skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

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 de GOAL.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.md et CLAUDE.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ée A-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.md existant en mode création, et ne jamais réécrire le contenu existant de CLAUDE.md.

Choisir le mode

  1. Si le premier mot des arguments est create, amend ou verify, utilisez ce mode. Le reste du texte est l'idée (create) ou le changement (amend).
  2. Sinon, déduisez le mode :
    • Aucun GOAL.md n'existe → create. Considérez les arguments ou le message de l'utilisateur comme l'idée.
    • GOAL.md existe et l'utilisateur décrit un changement de périmètre, d'exigences ou de contraintes → amend.
    • GOAL.md existe et l'utilisateur demande si le travail est terminé ou répond à l'objectif → verify.
    • GOAL.md existe et l'intention n'est pas claire → demandez une fois avec AskUserQuestion : amend / verify / cancel.
  3. Si le mode est create mais que GOAL.md existe 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.md et docs/
  • 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-n avec 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

  1. Lisez templates/GOAL.template.md. Rédigez GOAL.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 …). Utilisez manuel — <é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 n et 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.
  2. Porte : exécutez bash ${CLAUDE_SKILL_DIR}/scripts/check_goal.sh GOAL.md. Corrigez chaque ÉCHEC et réexécutez jusqu'à ce qu'il se termine avec 0. Mentionnez toutes les lignes AVERTISSEMENT à l'utilisateur. Ces corrections sont les vôtres et ne comptent pas comme une révision de l'utilisateur.
  3. Montrez à l'utilisateur le GOAL.md complet. Demandez ensuite avec AskUserQuestion : Approuver (Recommandé) / Demander des modifications (texte libre via "Autre").
  4. 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.
  5. 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).
  6. 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.sh se termine avec 0, ce qui signifie que chaque CA est testable et que chaque élément supposé a un A-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

  1. Lisez GOAL.md et CLAUDE.md. Reformulez le changement demandé en une phrase.
  2. 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.
  3. 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.
  4. 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 : ….
  5. 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.
  6. 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.

  1. Lisez GOAL.md et 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é.

  2. 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.

  3. 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.

  4. 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.md existe 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.md n'existe pas, créez-le en ne contenant que cette ligne.

Skills associés