jagp/break-down-course-goal

Que fait break-down-course-goal ?

Transformez le fichier inputs.json d'un client en tree.json : un arbre dont la racine est l'objectif de cours, et dont chaque arête signifie « l'enfant est quelque chose que le participant doit être capable de FAIRE, avec Claude, pour que son parent puisse se réaliser. »

Choix de conception de ce skill : evidence-up. La méthode ne décompose pas l'objectif depuis le sommet. Elle part des critères et des objectifs hebdomadaires, se demande ce qui doit être observablement vrai lorsque chacun est atteint et ce que le participant doit faire pour produire cette preuve, et remonte de ces actions vers l'objectif. L'objectif est la dernière chose jointe, pas la première chose divisée. La signification de l'arête est la même dans les deux sens ; seul l'ordre de construction diffère.

Entrées et sorties

• Dossier d'exécution : donné par l'utilisateur. Tout est lu et écrit dans ce dossier.
• Lecture : <run>/inputs.json (schéma h0-inputs/1). Les faits client proviennent UNIQUEMENT de ce fichier. Ne rien lire d'autre sur le client.
• Écriture : tree-A.json, tree-B.json, tree-C.json, tree-pitches.md ; après la sélection, tree.json, skills-list.md et une ligne dans decisions.md.
• Portail : depuis le dossier qui contient schemas/, exécutez python schemas/validate.py h1 <run>/tree-X.json --inputs <run>/inputs.json Il doit afficher PASS. Corrigez et réexécutez jusqu'à ce que ce soit le cas. S'il ne peut pas atteindre PASS, arrêtez-vous et signalez les erreurs restantes ; ne transmettez jamais un fichier défaillant.
• Scripts (dans le dossier scripts/ de ce skill, tous écrivent en UTF-8) :
  • order_leaves.py <tree.json> : calcule leaf_order à partir des nœuds et l'écrit dans le fichier. Ne jamais écrire manuellement leaf_order.
  • render_leaves.py <tree.json> [<out.md>] : transforme leaf_order en la liste numérotée de feuilles skills-list.md. Ne jamais écrire la liste manuellement.
  • pick.py <run> <A|B|C> ["raison"] : copie la version choisie dans tree.json et ajoute une entrée dans decisions.md.

Méthode (version A : evidence-up)

Travaillez dans cet ordre. Gardez une liste de brouillon au fur et à mesure ; seul l'arbre est écrit.

Étape 0. Trier les entrées

1. Copiez exactement goal dans la propriété goal de l'arbre.
2. Triez chaque entrée de constraints dans l'une des deux piles :
   • Contraintes qui lient l'arbre : concernant les données (d'où elles viennent, lecture/écriture) ou le périmètre (ce qui est inclus ou exclu). Utilisez-les aux étapes 2 à 4.
   • Contraintes de livraison : concernant le temps, la durée, le nombre de sessions, le format, la planification. Placez-les dans set_aside avec la contrainte copiée exactement et une raison d'une ligne (« contrainte de livraison ; l'arbre ne porte que sur les capacités »). Cela ne façonne, ne dimensionne, ne divise ni ne fusionne jamais un nœud.
3. Lisez presenter_owned (le cas échéant) comme contexte. Ce ne sont jamais des nœuds, et aucun nœud ne peut exiger du participant qu'il les exécute.
4. Listez les problèmes de glossaire maintenant, avant de construire :
   • toute valeur de glossaire qui commence par UNRESOLVED ou PROVISIONAL → un écart undefined_term, même si l'objectif n'utilise pas le terme ;
   • tout terme dans l'objectif, les objectifs hebdomadaires, les critères ou les contraintes que le glossaire ne définit pas et dont l'arbre dépend (ce qui constitue une unité à vérifier, la forme d'un fichier de données) → un écart undefined_term. Ne définissez aucun d'entre vous-même. Lorsqu'un nœud dépend d'un tel terme, formulez le nœud pour qu'il fonctionne sans la définition et mentionnez l'écart.

Étape 1. Écrire les preuves

Pour chaque critère : la preuve est son pass_if, lu littéralement. Écrivez une ligne : « Observable : <pass_if>, produit par , à partir de . » Pour chaque objectif hebdomadaire : écrivez ce que quelqu'un d'autre pourrait voir s'il était atteint (un produit, un enregistrement, un changement visible). Si l'objectif concerne le confort ou la confiance et n'a pas de produit, nommez le plus petit comportement visible qui le montre (par exemple, « une version révisée existe après une demande de suivi du participant lui-même »).

Étape 2. Nommer l'action qui produit chaque preuve

Pour chaque ligne de preuve, demandez : « Que fait le participant, avec Claude, qui laisse cette preuve derrière lui ? » Écrivez-la comme une action impérative avec un objet (« Produire … », « Signaler … », « Demander à Claude de … »), jamais comme un sujet (« Initiation aux invites », « Culture des données »).

• Si deux lignes de preuve sont produites par la même action, elles partagent une seule action.
• Chaque action distincte devient un nœud de premier niveau (un enfant de la racine) et reçoit serves listant chaque objectif hebdomadaire et chaque identifiant de critère dont elle produit la preuve.
• Vérification de couverture : chaque identifiant W et C dans les entrées apparaît dans au moins un serves de premier niveau. Si la preuve d'un objectif hebdomadaire est réellement produite à l'intérieur d'une autre action (une version plus petite de celle-ci), cette action de premier niveau la dessert également et l'action plus petite devient un descendant.
• Si deux actions de premier niveau dépendent l'une de l'autre (l'une a besoin du produit de l'autre), reliez-les avec prereqs, pas par imbrication.

Étape 3. Revenir en arrière à partir de chaque action

Pour chaque nœud, demandez : « Que doivent-ils être capables de faire, avec Claude, avant que cela puisse se produire ? » Chaque nouvelle réponse devient un enfant.

• Seules les actions effectuées avec Claude sont des enfants. Demander à Claude compte, tout comme juger, vérifier ou agir sur la sortie de Claude (c'est la moitié du travail du participant). Une étape qui ne touche ni Claude ni sa sortie (utiliser un autre outil, envoyer quelque chose) n'est pas un nœud : soit elle est couverte par le profil ou les connaissances du domaine, soit c'est une lacune (« les entrées ne disent pas qui/comment … »).
• Si la réponse est déjà un nœud ailleurs, liez-la dans prereqs au lieu de la dupliquer.
• Un prérequis que plusieurs frères et sœurs partagent se place sous leur parent commun le plus bas, pas à l'intérieur de la branche d'un seul frère ; sinon, les prereqs d'un frère peuvent pointer vers une branche qui en a besoin, ce que order_leaves.py signale comme un cycle.
• Divisez uniquement par cette question. Ne divisez, ne fusionnez ni ne dimensionnez jamais un nœud pour l'adapter à des sessions, des laboratoires, du temps ou à une manière de l'enseigner.

Étape 4. S'arrêter au niveau du sol, et l'enregistrer

Arrêtez de diviser un nœud lorsque la question de l'étape 3 ne donne aucune nouvelle réponse. Le nœud est alors une feuille et reçoit floor :

• profile : le profil du participant couvre déjà ce qui précède (citez ou paraphrasez quel champ du profil).
• domain_knowledge : il s'agit de connaissances ordinaires du travail du participant, indiquées dans les entrées (dites où).
• inputs_stop : les entrées ne disent rien qui vous permettrait d'aller plus loin (dites ce qui manque, et ajoutez une lacune si important). Lorsque les seuls prérequis restants sont des nœuds existants, ils sont dans prereqs ; choisissez la raison qui explique pourquoi rien de nouveau ne reste, et dites « les prérequis restants sont déjà des nœuds : … » dans detail.

Étape 5. Données et revendications sur Claude

• Données. Tout nœud qui a besoin de données reçoit une entrée data : what, et source provenant des entrées : live, read-only (données réelles qui sont lues et jamais réécrites ; jamais inventées), sample, ou own (propres au participant). Mettez la phrase des entrées qui indique la source dans quote, copiée exactement. Si les entrées ne disent pas d'où viennent les données, utilisez UNRESOLVED, omettez quote, et ajoutez une lacune data_provenance nommant le nœud.
• Revendications. Tout nœud qui suppose qu'un produit Claude peut faire quelque chose (lire un fichier joint, réviser sur demande, pointer vers une ligne source) reçoit une entrée claims avec verify: true, à moins que vous ne citiez une URL de documentation actuelle qui l'énonce (alors cite au lieu de verify). Jamais les deux.

Étape 6. Joindre l'objectif

Créez la racine en dernier : parent: null, skill = l'objectif reformulé comme une action du participant, pas de serves, pas de floor. Pointez chaque nœud de premier niveau vers elle. Numérotez les nœuds N1 (racine) en montant. Vérifiez :

• chaque nœud sauf la racine a un parent ; les feuilles ont floor, les nœuds non-feuilles n'en ont pas ; seuls les enfants de la racine ont serves ;
• aucun mot de temps, format ou planification dans aucun skill.

Étape 7. Ordonner, passer le portail, rendre

1. python <skill>/scripts/order_leaves.py <run>/tree-A.json (définit leaf_order ; échoue sur un cycle, ce qui signifie une boucle de prereqs à corriger).
2. Passez tree-A.json au portail jusqu'à PASS.
3. Remplissez gaps avec tout ce qui vient des étapes 0, 3, 4 et 5. Les lacunes sont signalées, jamais comblées.

Trois versions

Chaque exécution écrit trois arbres passant le portail à partir du même inputs.json et du même schéma. B et C proviennent de sous-agents séparés et frais (jamais de forks), chacun recevant uniquement son briefing ci-dessous, le chemin du dossier d'exécution, le chemin du dossier scripts/ de ce skill et la commande du portail. Si la plateforme n'a pas de sous-agents, écrivez B et C vous-même et placez cette phrase en haut de tree-pitches.md : « B et C sont joués par le même modèle, pas des exécutions indépendantes. »

Briefing pour B (choix de conception alternatif : décomposition descendante de l'objectif). « Lisez <run>/inputs.json uniquement. Construisez <run>/tree-B.json (schéma h1-tree/1) en décomposant l'objectif depuis le sommet : divisez l'objectif racine en les actions qui le composent, puis divisez chacune jusqu'à ce que la question « que doivent-ils faire, avec Claude, avant cela ? » ne donne plus de nouvelle réponse (alors enregistrez floor). Signification de l'arête : l'enfant est quelque chose que le participant doit être capable de FAIRE, avec Claude, pour que son parent se réalise. Chaque enfant racine déclare serves ; chaque identifiant W et C doit être desservi. Les compétences sont des actions, pas des sujets. Les contraintes de livraison (temps, durée, format) vont dans set_aside avec une raison ; les contraintes de données lient l'arbre ; les éléments détenus par le présentateur ne sont jamais des nœuds. Les sources de données proviennent uniquement des entrées, avec la phrase des entrées citée exactement, ou UNRESOLVED plus une lacune. Signalez tout terme de glossaire UNRESOLVED/PROVISIONAL et tout terme non défini comme une lacune ; n'en définissez jamais. Les revendications sur les produits Claude portent verify: true. Exécutez scripts/order_leaves.py pour définir leaf_order, puis le portail, jusqu'à ce qu'il imprime PASS. Renvoyez une phrase argumentant en faveur de votre version, nommant le choix de conception. »

Briefing pour C (contradicteur / vérificateur de faits). « Lisez <run>/inputs.json et <run>/tree-A.json uniquement. Attaquez les prémisses de A : pour chaque nœud, demandez-vous s'il s'agit vraiment de quelque chose fait avec Claude, s'il est nécessaire pour son parent, et si sa preuve pourrait être vérifiée par quelqu'un d'autre que son auteur. Vérifiez les faits concernant toutes les revendications sur les produits Claude par rapport à la documentation actuelle (docs.claude.com, support.claude.com) ; gardez verify: true sur ce que vous ne pouvez pas confirmer, et citez l'URL sur ce que vous pouvez. Supprimez ce qui ne peut être vérifié ou mesuré, fusionnez les doublons dans prereqs, et proposez l'arbre le plus léger ou le plus sûr. Conservez le même schéma, la même signification des arêtes et les mêmes règles : chaque identifiant W et C desservi, actions pas de sujets, floors sur les feuilles, contraintes de livraison dans set_aside, sources de données citées depuis les entrées ou UNRESOLVED avec une lacune, termes non définis signalés et non définis. Écrivez <run>/tree-C.json, exécutez scripts/order_leaves.py, puis le portail, jusqu'à PASS. Renvoyez une phrase argumentant en faveur de votre version. »

Présentations, sélection, journal

1. Écrivez <run>/tree-pitches.md : une ligne par version, A — <une phrase>, B — …, C — …, chacune nommant son choix de conception. Aucune version n'est marquée comme recommandée. Vous pouvez signaler une erreur factuelle dans n'importe quelle version ; vous ne votez pas.
2. Le présentateur choisit. Exécutez python <skill>/scripts/pick.py <run> <A|B|C> "<raison donnée, le cas échéant>". Avant de proposer, lisez decisions.md s'il existe pour ne pas reproposer quelque chose déjà rejeté.
3. Passez tree.json au portail une fois de plus, puis python <skill>/scripts/render_leaves.py <run>/tree.json → <run>/skills-list.md.

Rapport (à l'utilisateur, à la fin d'une exécution)

• les fichiers écrits ;
• la sortie du portail pour chaque version ;
• chaque lacune (termes non définis, provenance des données, autres), telle que listée dans l'arbre ;
• chaque contrainte mise de côté, avec sa raison ;
• si B et C étaient des sous-agents indépendants ou joués.

Exemple inventé (générique, ne provenant d'aucun client)

Objectif : « Chaque organisateur bénévole utilise Claude pour transformer la feuille d'inscription en un planning de rotation et vérifie chaque créneau par rapport à la feuille. » Critère : « pass_if : un créneau corrigé par organisateur, avec la ligne de la feuille d'inscription sur laquelle il a été vérifié. »

• Étape 1 preuve : « un créneau corrigé plus la ligne sur laquelle il a été vérifié existe pour chaque organisateur. »
• Étape 2 action (premier niveau, dessert ce critère) : « Vérifiez chaque créneau du planning par rapport à la feuille d'inscription et corrigez tout créneau que la feuille ne supporte pas, en enregistrant la ligne. »
• Étape 3 rétroaction : « Demandez à Claude d'afficher, pour chaque créneau, la ligne de la feuille dont il provient » (avec Claude) → enfant. « Ouvrez la feuille d'inscription » (sans Claude) → pas un nœud ; profil ou lacune.
• Étape 4 floor sur « Juger si une ligne supporte un créneau » : domain_knowledge, car les organisateurs gèrent déjà les inscriptions.