jagp/break-down-course-goal

break-down-course-goal は何をしますか？

1つのクライアントのinputs.jsonをtree.jsonに変換します。これは、コース目標をルートとするツリーであり、各エッジは「子は、参加者がその親を達成するために、Claudeを使って実行できる必要があるもの」を意味します。

このスキルの設計上の選択: 証拠積み上げ（evidence-up）。 この方法は目標をトップから分解しません。基準と週次目標から始めて、各基準が満たされたときに観測可能に真となること、および参加者がその証拠を生み出すために何をしなければならないかを問い、それらのアクションから目標に向かって遡って作業します。目標は最後に結合されるものであり、最初に分割されるものではありません。エッジの意味はどちらの方向でも同じであり、構築順序のみが異なります。

入力と出力

• 実行フォルダ: ユーザーによって指定されます。すべての読み取りと書き込みはこのフォルダに対して行われます。
• 読み取り: <run>/inputs.json（スキーマ h0-inputs/1）。クライアントの事実はこのファイルからのみ取得します。クライアントに関する他の情報は読み取りません。
• 書き込み: tree-A.json、tree-B.json、tree-C.json、tree-pitches.md。選択後、tree.json、skills-list.md、および decisions.md への1行。
• ゲート: schemas/ フォルダがあるディレクトリから、 python schemas/validate.py h1 <run>/tree-X.json --inputs <run>/inputs.json を実行します。PASS と出力される必要があります。修正して PASS が出るまで再実行します。PASS に達しない場合は、残ったエラーを報告して停止します。不合格のファイルを決して引き渡さないでください。
• スクリプト（このスキルの scripts/ 内にあり、すべてUTF-8で書き込みます）:
  • order_leaves.py <tree.json>: ノードから leaf_order を計算してファイルに書き込みます。決して leaf_order を手書きしないでください。
  • render_leaves.py <tree.json> [<out.md>]: leaf_order を番号付きリーフリスト skills-list.md としてレンダリングします。決してリストを手書きしないでください。
  • pick.py <run> <A|B|C> ["理由"]: 選択されたバージョンを tree.json にコピーし、decisions.md に追記します。

方法（バージョンA: 証拠積み上げ）

以下の順序で作業します。進捗に応じてスクラッチリストを保持しますが、書き込むのはツリーのみです。

ステップ0. 入力を整理する

1. goal をそのままツリーの goal にコピーします。
2. すべての constraints エントリを次の2つの山に分類します。
   • ツリーを拘束するもの: データ（出所、読み書き）または範囲（何が含まれ、何が除外されるか）に関するもの。ステップ2～4で使用します。
   • デリバリー: 時間、長さ、セッション数、形式、スケジュールに関するもの。制約をそのままコピーし、1行の理由（「デリバリーの制約です。ツリーは能力のみに関するものです」）を付けて set_aside に配置します。これはノードの形成、サイズ変更、分割、マージを決して行いません。
3. presenter_owned（存在する場合）をコンテキストとして読み取ります。これらは決してノードにはならず、いかなるノードも参加者がこれらを実行することを要求してはなりません。
4. 構築を始める前に、今のうちに用語集の課題をリストアップします。
   • UNRESOLVED または PROVISIONAL で始まるすべての用語集の値 → undefined_term ギャップ。目標がその用語を使用していなくても同様です。
   • 目標、週次目標、基準、制約の中で、用語集が定義しておらず、ツリーが依存するすべての用語（チェックされる単位とみなされるもの、データファイルの形式など）→ undefined_term ギャップ。 それらのいずれも自分で定義しないでください。ノードがいずれかに依存する場合、定義がなくても機能するようにノードを表現し、ギャップを指名します。

ステップ1. 証拠を書き留める

各基準について: 証拠はその pass_if であり、文字通りに読み取ります。「観測可能: <pass_if>、<誰>によって生成され、<何>から」という1行を書きます。 各週次目標について: それが満たされた場合に他者が見ることができるもの（成果物、記録、目に見える変化）を書きます。目標が快適さや自信に関するもので成果物がない場合、それを示す最小の目に見える行動を指名します（例：「参加者自身のフォローアップ依頼の後に修正版が存在する」）。

ステップ2. 各証拠を生み出すアクションを特定する

各証拠行について、次のように問います: 「参加者は、Claudeを使って、この証拠を残すために何をするのか？」 トピック（「プロンプティング」「データリテラシー」）ではなく、目的語を伴う命令形のアクション（「…を生成する」「…にフラグを立てる」「Claudeに…を依頼する」）として記述します。

• 2つの証拠行が同じアクションによって生成される場合、それらは1つのアクションを共有します。
• それぞれの異なるアクションはトップレベルノード（ルートの子）となり、その証拠が生成するすべての週次目標と基準のIDをリストした serves を持ちます。
• カバレッジチェック: 入力内のすべての W および C IDが少なくとも1つのトップレベルの serves に現れます。週次目標の証拠が実際には別のアクション内で生成される場合（その小さいバージョン）、そのトップレベルアクションもそれを提供し、小さいアクションは子孫になります。
• 2つのトップレベルアクションが互いに依存する場合（一方が他方の成果物を必要とする）、ネストではなく prereqs でリンクします。

ステップ3. 各アクションから遡って作業する

各ノードについて、次のように問います: 「これが起こる前に、彼らはClaudeを使って何ができなければならないか？」 新しい答えのそれぞれが子になります。

• Claudeを使って行われるアクションのみが子になります。Claudeに依頼することもカウントされ、Claudeの出力を判断、確認、またはそれに基づいて行動することもカウントされます（それが参加者の作業の半分です）。Claudeにもその出力にも触れないステップ（別のツールを操作する、何かを送信する）はノードになりません。プロファイルまたはドメイン知識でカバーされているか、ギャップ（「入力は誰が/どのように…するかを示していない」）になります。
• 答えがすでに別の場所にあるノードである場合、複製する代わりに prereqs でリンクします。
• 複数の兄弟が必要とする前提条件は、1つの兄弟のブランチ内ではなく、それらの最も低い共通の親の下に置きます。そうしないと、兄弟の prereqs がそれを必要とするブランチを指し戻す可能性があり、order_leaves.py がそれをサイクルとして報告します。
• この質問によってのみ分割します。セッション、ラボ、時間、または指導方法に合わせてノードを分割、マージ、サイズ変更しないでください。

ステップ4. フロアで停止し、記録する

ステップ3の質問に対して新しい答えが得られなくなった時点で、ノードの分割を停止します。そのノードはリーフとなり、floor を取得します。

• profile: 参加者プロファイルがその前に来るものをすでにカバーしている（該当するプロファイルフィールドを引用または言い換える）。
• domain_knowledge: 入力に記載されている、参加者自身の仕事の通常の知識である（その場所を示す）。
• inputs_stop: 入力にはそれ以上進むための情報がない（何が欠けているかを述べ、それが重要であればギャップを追加する）。 残っている前提条件が既存のノードのみである場合、それらは prereqs にあります。新しいものが何も残っていない理由を説明するものを選び、「残りの前提条件はすでにノードです: …」と detail に記述します。

ステップ5. データとClaudeの主張

• データ. データを必要とするノードは data エントリを取得します: what、および入力から取得した source: live、read-only（読み取り専用で決して書き戻さない実際のデータ。決して発明しない）、sample、または own（参加者自身のもの）。ソースを述べている入力の文を quote に正確にコピーします。入力がデータの出所を述べていない場合は、UNRESOLVED を使用し、quote を省略し、そのノードを指名する data_provenance ギャップを追加します。
• 主張. Claude製品ができること（添付ファイルの読み取り、要求に応じた修正、ソース行へのポインティング）を想定するノードは、現在のドキュメントURLを引用してそれが述べられている場合を除き（その場合は verify の代わりに cite）、verify: true を含む claims エントリを取得します。両方は決して使用しません。

ステップ6. 目標を結合する

ルートを最後に作成します: parent: null、skill = 参加者のアクションとして言い換えられた目標、serves なし、floor なし。すべてのトップレベルノードをルートに向けます。ノードに N1（ルート）から順に番号を付けます。チェックします。

• ルートを除くすべてのノードに親があり、リーフには floor があり、非リーフにはありません。ルートの子だけが serves を持ちます。
• いずれの skill にも時間、形式、スケジュールに関する単語が含まれていません。

ステップ7. 順序付け、ゲート、レンダリング

1. python <skill>/scripts/order_leaves.py <run>/tree-A.json（leaf_order を設定します。サイクルがあると失敗し、修正すべき prereqs ループがあることを示します）。
2. tree-A.json を PASS が出るまでゲートします。
3. ステップ0、3、4、5のすべての内容で gaps を埋めます。ギャップは報告され、決して埋められません。

3つのバージョン

すべての実行で、同じ inputs.json と同じスキーマから3つのゲート通過ツリーを生成します。BとCは独立した新鮮なサブエージェント（フォークではありません）から生成され、各サブエージェントには以下の簡単な指示、実行フォルダのパス、このスキルの scripts/ パス、およびゲートコマンドのみが与えられます。プラットフォームにサブエージェントがない場合は、BとCを自分で作成し、tree-pitches.md の先頭に次の文を配置します: 「BとCは同じモデルによってロールプレイされており、独立した実行ではありません。」

Bへの指示（代替設計選択: トップダウン分解（goal-down decomposition））。 「<run>/inputs.json のみを読み取ってください。<run>/tree-B.json（スキーマ h1-tree/1）を、目標をトップから分解して構築してください。つまり、ルートの目標をそれが構成するアクションに分割し、'これを行う前に、彼らはClaudeを使って何ができなければならないか？'という質問に対して新しい答えが得られなくなるまで各アクションを分割します（その後 floor を記録します）。エッジの意味: 子は、参加者がその親を達成するために、Claudeを使って実行できる必要があるもの。各ルートの子は serves を宣言します。すべてのWとCのIDが提供されなければなりません。スキルはアクションであり、トピックではありません。デリバリーの制約（時間、長さ、形式）は理由とともに set_aside に入れられます。データ制約はツリーを拘束します。プレゼンター所有の項目は決してノードになりません。データソースは入力からのみ取得され、入力の文が正確に引用されるか、UNRESOLVED とギャップが設定されます。すべてのUNRESOLVED/PROVISIONALな用語集の用語と、定義されていないすべての用語をギャップとして報告します。決して定義しないでください。Claude製品の主張には verify: true を付けます。scripts/order_leaves.py を実行して leaf_order を設定し、その後ゲートを PASS と出力されるまで実行します。設計上の選択を指名して、自分のバージョンを主張する1文を返してください。」

Cへの指示（対抗的/ファクトチェッカー）。 「<run>/inputs.json と <run>/tree-A.json のみを読み取ってください。Aの前提を攻撃します。各ノードについて、それが本当にClaudeを使って行われるものか、その親に必要か、その証拠が作成者以外の誰かによって確認できるかを問います。Claude製品に関するすべての主張を現在のドキュメント（docs.claude.com、support.claude.com）に対してファクトチェックします。確認できないものには verify: true を保持し、確認できるものにはURLを引用します。検証または測定できないものを削除し、重複を prereqs にマージし、よりリーンまたは安全なツリーを提案します。同じスキーマ、エッジの意味、およびルール（すべてのWとCのIDが提供される、アクションはトピックではない、リーフにはフロアがある、デリバリー制約は set_aside に、データソースは入力から引用されるか UNRESOLVED とギャップ、未定義の用語は報告され定義されない）を守ってください。<run>/tree-C.json を作成し、scripts/order_leaves.py を実行し、その後ゲートを PASS が出るまで実行します。自分のバージョンを主張する1文を返してください。」

ピッチ、選択、ログ

1. <run>/tree-pitches.md を書きます。バージョンごとに1行: A — <1文>、B — …、C — …。それぞれ設計上の選択を指名します。どのバージョンも推奨とはマークされません。任意のバージョンの事実上の誤りを指摘してもかまいません。投票はしません。
2. プレゼンターが選択します。python <skill>/scripts/pick.py <run> <A|B|C> "<与えられた理由があれば、それ>" を実行します。提案する前に、decisions.md が存在する場合はそれを読み、すでに却下されたものを再提案しないようにします。
3. tree.json をもう一度ゲートし、次に python <skill>/scripts/render_leaves.py <run>/tree.json → <run>/skills-list.md を実行します。

レポート（実行終了時にユーザーへ）

• 書き込まれたファイル
• 各バージョンのゲート出力
• すべてのギャップ（未定義の用語、データ出所、その他）、ツリーにリストされている通り
• その理由と共に脇に置かれたすべての制約
• BとCが独立したサブエージェントであったか、ロールプレイされたか

架空の例（どのクライアントからも独立した汎用例）

目標: 「各ボランティア主催者がClaudeを使用して、申込用紙をシフトローテーション表に変換し、すべてのスロットを申込用紙に対してチェックする。」基準: 「pass_if: 主催者ごとに1つの修正されたスロットと、それがチェックされた申込用紙の行。」

• ステップ1の証拠: 「主催者ごとに、修正されたスロットとそれがチェックされた申込用紙の行が存在する。」
• ステップ2のアクション（トップレベル、その基準を提供）: 「各ローテーションスロットを申込用紙に対してチェックし、用紙がサポートしないスロットを修正し、その行を記録する。」
• ステップ3の逆ステップ: 「各スロットについて、それが由来する用紙の行をClaudeに表示させるよう依頼する」（Claudeを使用）→ 子。「申込用紙を開く」（Claudeを使用しない）→ ノードにならない。プロファイルまたはギャップ。
• ステップ4 の「行がスロットをサポートするか判断する」のフロア: domain_knowledge。主催者はすでに申込受付を運用しているため。