jagp/kursziel-zerlegen

break-down-course-goal

Wandelt die inputs.json eines Kunden in eine tree.json um: einen Baum, der am Kursziel verwurzelt ist, wobei jede Kante bedeutet „das Kind ist etwas, das der Teilnehmer mit Claude TUN können muss, damit sein Elternteil geschehen kann.“

Designentscheidung dieser Skill: evidenzaufwärts. Die Methode zerlegt das Ziel nicht von oben. Sie beginnt mit den Kriterien und wöchentlichen Zielen, fragt, was beobachtbar wahr sein muss, wenn jedes erfüllt ist, und was der Teilnehmer tun muss, um diesen Nachweis zu erbringen, und arbeitet von diesen Aktionen zurück zum Ziel. Das Ziel wird zuletzt eingefügt, nicht zuerst aufgeteilt. Die Kantenbedeutung ist in beide Richtungen gleich; nur die Reihenfolge der Erstellung unterscheidet sich.

Eingaben und Ausgaben

• Ausführungsordner: vom Benutzer angegeben. Alles wird daraus gelesen und hineingeschrieben.
• Liest: <run>/inputs.json (Schema h0-inputs/1). Kundeninformationen stammen ausschließlich aus dieser Datei. Lesen Sie nichts anderes über den Kunden.
• Schreibt: tree-A.json, tree-B.json, tree-C.json, tree-pitches.md; nach der Auswahl tree.json, skills-list.md und eine Zeile in decisions.md.
• Gate: Führen Sie aus dem Ordner, der schemas/ enthält, Folgendes aus: python schemas/validate.py h1 <run>/tree-X.json --inputs <run>/inputs.json Es muss PASS ausgeben. Korrigieren Sie und führen Sie es erneut aus, bis es bestanden wird. Wenn es nicht PASS erreichen kann, stoppen Sie und melden Sie die verbleibenden Fehler; geben Sie niemals eine fehlschlagende Datei ab.
• Skripte (im scripts/-Ordner dieser Fähigkeit, alle schreiben UTF-8):
  • order_leaves.py <tree.json>: berechnet leaf_order aus den Knoten und schreibt es in die Datei. Schreiben Sie leaf_order niemals von Hand.
  • render_leaves.py <tree.json> [<out.md>]: rendert leaf_order als nummerierte Blattliste skills-list.md. Schreiben Sie die Liste niemals von Hand.
  • pick.py <run> <A|B|C> ["Grund"]: kopiert die Auswahl in tree.json und fügt sie an decisions.md an.

Methode (Version A: evidenzaufwärts)

Arbeiten Sie in dieser Reihenfolge. Führen Sie während der Arbeit eine Notizliste; nur der Baum wird geschrieben.

Schritt 0. Eingaben sortieren

1. Kopieren Sie goal exakt in das goal des Baums.
2. Sortieren Sie jeden Eintrag von constraints in einen von zwei Stapeln:
   • Bindet den Baum: über Daten (woher sie kommen, Lesen/Schreiben) oder Umfang (was drin oder draußen ist). Verwenden Sie ihn in den Schritten 2–4.
   • Auslieferung: über Zeit, Länge, Anzahl der Sitzungen, Format, Zeitplan. Legen Sie es in set_aside ab, wobei die Einschränkung exakt kopiert wird, sowie ein einzeiliger Grund („Auslieferungseinschränkung; der Baum handelt nur von Fähigkeiten“). Es formt, dimensioniert, teilt oder führt niemals einen Knoten zusammen.
3. Lesen Sie presenter_owned (falls vorhanden) als Kontext. Dies sind niemals Knoten, und kein Knoten darf verlangen, dass der Teilnehmer sie ausführt.
4. Listen Sie jetzt, vor dem Aufbau, Glossarprobleme auf:
   • jeder Glossarwert, der mit UNRESOLVED oder PROVISIONAL beginnt → eine undefined_term-Lücke, auch wenn das Ziel den Begriff nicht verwendet;
   • jeder Begriff im Ziel, in den wöchentlichen Zielen, Kriterien oder Einschränkungen, den das Glossar nicht definiert und von dem der Baum abhängt (was als Einheit gilt, die überprüft werden soll, welche Form eine Datendatei hat) → eine undefined_term-Lücke. Definieren Sie keinen davon selbst. Wo ein Knoten von einem abhängt, formulieren Sie den Knoten so, dass er ohne die Definition funktioniert, und benennen Sie die Lücke.

Schritt 1. Den Nachweis aufschreiben

Für jedes Kriterium: Der Nachweis ist sein pass_if, wörtlich gelesen. Schreiben Sie eine Zeile: „Beobachtbar: <pass_if>, erbracht von , aus .“ Für jedes wöchentliche Ziel: Schreiben Sie, was jemand anderes sehen könnte, wenn es erfüllt wäre (ein Produkt, eine Aufzeichnung, eine sichtbare Veränderung). Wenn es um Bequemlichkeit oder Vertrauen geht und kein Produkt hat, nennen Sie das kleinste sichtbare Verhalten, das es zeigt (z. B. „eine überarbeitete Version existiert nach der eigenen Folgeanfrage des Teilnehmers“).

Schritt 2. Die Aktion benennen, die jedes Beweisstück hervorbringt

Fragen Sie für jede Beweiszeile: „Was tut der Teilnehmer mit Claude, das diesen Beweis hinterlässt?“ Schreiben Sie es als imperative Aktion mit einem Objekt („Erstellen …“, „Markieren …“, „Claude bitten, …“), niemals ein Thema („Eingabeaufforderung“, „Datenkompetenz“).

• Wenn zwei Beweiszeilen von derselben Aktion erzeugt werden, teilen sie sich eine Aktion.
• Jede eindeutige Aktion wird zu einem Knoten der obersten Ebene (ein Kind der Wurzel) und erhält serves, das jede ID des wöchentlichen Ziels und des Kriteriums auflistet, deren Beweis es erbringt.
• Abdeckungsprüfung: Jede W- und C-ID in den Eingaben erscheint in mindestens einem serves der obersten Ebene. Wenn der Beweis eines wöchentlichen Ziels wirklich innerhalb einer anderen Aktion (einer kleineren Version davon) erbracht wird, bedient diese Aktion der obersten Ebene es ebenfalls und die kleinere Aktion wird zu einem Nachkommen.
• Wenn zwei Aktionen der obersten Ebene voneinander abhängen (eine benötigt das Produkt der anderen), verknüpfen Sie sie mit prereqs, nicht durch Verschachtelung.

Schritt 3. Von jeder Aktion rückwärts arbeiten

Fragen Sie für jeden Knoten: „Was müssen sie mit Claude tun können, bevor dies geschehen kann?“ Jede neue Antwort wird zu einem Kind.

• Nur Aktionen, die mit Claude durchgeführt werden, sind Kinder. Claude zu bitten zählt, ebenso wie das Beurteilen, Überprüfen oder Handeln basierend auf Claudes Ausgabe (das ist die Hälfte der Arbeit des Teilnehmers). Ein Schritt, der weder Claude noch seine Ausgabe berührt (Bedienen eines anderen Werkzeugs, Senden von etwas), ist kein Knoten: entweder wird er durch das Profil oder Domänenwissen abgedeckt, oder es ist eine Lücke („Eingaben sagen nicht, wer/wie …“).
• Wenn die Antwort bereits ein Knoten anderswo ist, verknüpfen Sie ihn über prereqs, anstatt ihn zu duplizieren.
• Eine Voraussetzung, die mehrere Geschwister benötigen, sitzt unter ihrem niedrigsten gemeinsamen Elternteil, nicht innerhalb des Zweigs eines Geschwisters; andernfalls können die prereqs eines Geschwisters zurück in einen Zweig zeigen, der sie benötigt, was order_leaves.py als Zyklus meldet.
• Teilen Sie nur durch diese Frage auf. Teilen, zusammenführen oder dimensionieren Sie niemals einen Knoten, um zu Sitzungen, Laboren, Zeit oder einer anderen Art des Lehrens zu passen.

Schritt 4. Am Boden anhalten und ihn aufzeichnen

Hören Sie auf, einen Knoten aufzuteilen, wenn die Frage aus Schritt 3 keine neue Antwort ergibt. Der Knoten ist dann ein Blatt und erhält floor:

• profile: das Teilnehmerprofil deckt bereits ab, was davor kommt (zitieren oder paraphrasieren Sie, welches Profilfeld).
• domain_knowledge: es ist gewöhnliches Wissen über die eigene Arbeit des Teilnehmers, das in den Eingaben angegeben ist (sagen Sie wo).
• inputs_stop: die Eingaben sagen nichts, das es Ihnen erlauben würde, weiterzugehen (sagen Sie, was fehlt, und fügen Sie eine Lücke hinzu, wenn es darauf ankommt). Wenn die einzigen verbleibenden Voraussetzungen bereits vorhandene Knoten sind, sind sie in prereqs; wählen Sie den Grund, der erklärt, warum nichts Neues übrig bleibt, und sagen Sie „verbleibende Voraussetzungen sind bereits Knoten: …“ in detail.

Schritt 5. Daten und Claude-Behauptungen

• Daten. Jeder Knoten, der Daten benötigt, erhält einen data-Eintrag: what und source, entnommen aus den Eingaben: live, read-only (echte Daten, die gelesen und nie zurückgeschrieben werden; niemals erfunden), sample oder own (die eigenen des Teilnehmers). Setzen Sie den Eingabesatz, der die Quelle angibt, in quote, exakt kopiert. Wenn die Eingaben nicht sagen, woher die Daten kommen, verwenden Sie UNRESOLVED, lassen Sie quote weg und fügen Sie eine data_provenance-Lücke hinzu, die den Knoten benennt.
• Behauptungen. Jeder Knoten, der annimmt, dass ein Claude-Produkt etwas tun kann (eine angehängte Datei lesen, auf Anfrage überarbeiten, auf eine Quellzeile verweisen), erhält einen claims-Eintrag mit verify: true, es sei denn, Sie zitieren eine aktuelle Dokument-URL, die es angibt (dann cite anstelle von verify). Niemals beides.

Schritt 6. Das Ziel einfügen

Erstellen Sie die Wurzel zuletzt: parent: null, skill = das als Aktion des Teilnehmers umformulierte Ziel, kein serves, kein floor. Zeigen Sie jeden Knoten der obersten Ebene darauf. Nummerieren Sie die Knoten N1 (Wurzel) aufwärts. Überprüfen Sie:

• jeder Knoten außer der Wurzel hat ein Elternteil; Blätter haben floor, Nicht-Blätter nicht; nur Kinder der Wurzel haben serves;
• keine Zeit-, Format- oder Planungswörter in irgendeinem skill.

Schritt 7. Bestellen, Gaten, Rendern

1. python <skill>/scripts/order_leaves.py <run>/tree-A.json (setzt leaf_order; schlägt bei einem Zyklus fehl, was eine zu behebende prereqs-Schleife bedeutet).
2. Gaten Sie tree-A.json, bis es PASS ergibt.
3. Füllen Sie gaps mit allem aus den Schritten 0, 3, 4 und 5. Lücken werden gemeldet, niemals gefüllt.

Drei Versionen

Jeder Durchlauf schreibt drei gate-bestandene Bäume aus derselben inputs.json und demselben Schema. B und C stammen von separaten frischen Unteragenten (niemals Forks), die jeweils nur ihre Kurzbeschreibung unten, den Ausführungsordnerpfad, den scripts/-Pfad dieser Fähigkeit und den Gate-Befehl erhalten. Wenn die Plattform keine Unteragenten hat, schreiben Sie B und C selbst und setzen Sie diesen Satz an den Anfang von tree-pitches.md: „B und C werden vom selben Modell gespielt, nicht von unabhängigen Läufen.“

Kurzbeschreibung für B (alternative Designentscheidung: Ziel-abwärts-Zerlegung). „Lesen Sie nur <run>/inputs.json. Bauen Sie <run>/tree-B.json (Schema h1-tree/1), indem Sie das Ziel von oben zerlegen: Teilen Sie das Wurzelziel in die Aktionen auf, aus denen es besteht, dann teilen Sie jede, bis die Frage ‚was müssen sie mit Claude tun, bevor dies?‘ keine neue Antwort ergibt (dann zeichnen Sie floor auf). Kantenbedeutung: Das Kind ist etwas, das der Teilnehmer mit Claude TUN können muss, damit sein Elternteil geschehen kann. Jedes Wurzelkind deklariert serves; jede W- und C-ID muss bedient werden. Fähigkeiten sind Aktionen, keine Themen. Auslieferungseinschränkungen (Zeit, Länge, Format) kommen in set_aside mit einem Grund; Dateneinschränkungen binden den Baum; präsentatoreigene Elemente sind niemals Knoten. Datenquellen kommen nur aus den Eingaben, mit dem Eingabesatz exakt zitiert, oder UNRESOLVED plus einer Lücke. Melden Sie jeden UNRESOLVED/PROVISIONAL-Glossarbegriff und jeden undefinierten Begriff als Lücke; definieren Sie niemals einen. Claude-Produktbehauptungen tragen verify: true. Führen Sie scripts/order_leaves.py aus, um leaf_order zu setzen, dann das Gate, bis es PASS ausgibt. Geben Sie einen Satz zurück, der für Ihre Version argumentiert, und nennen Sie die Designentscheidung.“

Kurzbeschreibung für C (konträr / Faktenprüfer). „Lesen Sie nur <run>/inputs.json und <run>/tree-A.json. Greifen Sie As Prämissen an: Fragen Sie für jeden Knoten, ob es wirklich etwas ist, das mit Claude getan wird, ob es für sein Elternteil benötigt wird und ob sein Beweis von jemand anderem als seinem Autor überprüft werden könnte. Überprüfen Sie jede Behauptung über Claude-Produkte anhand aktueller Dokumente (docs.claude.com, support.claude.com); behalten Sie verify: true bei allem, was Sie nicht bestätigen können, und zitieren Sie die URL bei allem, was Sie können. Entfernen Sie, was nicht verifiziert oder gemessen werden kann, führen Sie Duplikate in prereqs zusammen und schlagen Sie den schlankeren oder sichereren Baum vor. Behalten Sie dasselbe Schema, dieselbe Kantenbedeutung und dieselben Regeln bei: jede W- und C-ID bedient, Aktionen nicht Themen, Böden auf Blättern, Auslieferungseinschränkungen in set_aside, Datenquellen aus den Eingaben zitiert oder UNRESOLVED mit einer Lücke, undefinierte Begriffe gemeldet, nicht definiert. Schreiben Sie <run>/tree-C.json, führen Sie scripts/order_leaves.py aus, dann das Gate, bis PASS. Geben Sie einen Satz zurück, der für Ihre Version argumentiert.“

Pitches, Auswahl, Protokoll

1. Schreiben Sie <run>/tree-pitches.md: eine Zeile pro Version, A — <ein Satz>, B — …, C — …, jede nennt ihre Designentscheidung. Keine Version wird als empfohlen markiert. Sie dürfen auf einen sachlichen Fehler in einer Version hinweisen; Sie stimmen nicht ab.
2. Der Präsentator wählt aus. Führen Sie python <skill>/scripts/pick.py <run> <A|B|C> "<angegebener Grund, falls vorhanden>" aus. Lesen Sie vor dem Vorschlagen decisions.md, falls es existiert, damit Sie nichts vorschlagen, das bereits abgelehnt wurde.
3. Gaten Sie tree.json ein weiteres Mal, dann python <skill>/scripts/render_leaves.py <run>/tree.json → <run>/skills-list.md.

Bericht (an den Benutzer, am Ende eines Durchlaufs)

• die geschriebenen Dateien;
• die Gate-Ausgabe für jede Version;
• jede Lücke (undefinierte Begriffe, Datenherkunft, andere), wie im Baum aufgelistet;
• jede beiseitegelegte Einschränkung mit ihrem Grund;
• ob B und C unabhängige Unteragenten oder gespielt waren.

Erfundenes Beispiel (generisch, nicht von einem Kunden)

Ziel: „Jeder freiwillige Organisator verwendet Claude, um die Anmeldeliste in einen Schichtplan umzuwandeln und überprüft jeden Slot gegen die Liste.“ Kriterium: „pass_if: ein korrigierter Slot pro Organisator, mit der Anmeldezeile, gegen die er überprüft wurde.“

• Schritt 1 Beweis: „ein korrigierter Slot plus die Zeile, gegen die er überprüft wurde, existiert für jeden Organisator.“
• Schritt 2 Aktion (oberste Ebene, bedient dieses Kriterium): „Überprüfen Sie jeden Rotationsslot gegen die Anmeldeliste und korrigieren Sie jeden Slot, den die Liste nicht unterstützt, und notieren Sie die Zeile.“
• Schritt 3 Rückwärtsschritt: „Claude bitten, für jeden Slot die Listenzeile anzuzeigen, aus der er stammt“ (mit Claude) → Kind. „Die Anmeldeliste öffnen“ (ohne Claude) → kein Knoten; Profil oder Lücke.
• Schritt 4 Boden bei „Beurteilen, ob eine Zeile einen Slot unterstützt“: domain_knowledge, weil Organisatoren bereits Anmeldungen durchführen.