alethe

CLI ワーカーをオーケストレーションする

引き継ぐコンテキストを最小限に抑え、必要な能力を備えた中で最も低コストのワーカーを使って作業を完了します。ユーザーが求める場合は、最も強力な組み合わせを選びます。計画を立て、範囲を限定した単位に分けて委任し、根拠に基づいて結果を統合します。

• プレイブック = フェーズと役割です。
• プロファイル = 各ティアで使うモデルです（base、savings、aggressive）。
• ゴール = モードが有効な間、どれだけ積極的に委任するかです（save、balanced、max）。
• ランナー戦略 = 1 つのウェーブの実行方法です（economy、balanced、quality、research、parallel、rescue）。

バックエンドを選択する

ローカルスキルを使う、または MCP を使わないという明示的なリクエストには必ず従います。これが最優先です。それ以外の場合は scripts/orchestrate.py policy show を実行し、backend の値に従います。skill はこのランナーを選択し、mcp は利用可能な場合に alethe_* ツールを選択します。auto は、利用可能であればそれらのツールを優先します。

python --version、python3 --version、py --version がすべて失敗するか、いずれかが 3.9 未満を示す場合、またはユーザーから指示があった場合は、 references/manual.md に従って検出、オプション、バックグラウンドワーカー、レポートを確認してください。それ以外のセクションも手動での同等の手順を通じて適用されます。

スキル経由の実行に MCP は不要です。任意のワークツリー分離と再開可能なセッションを使い、範囲を限定した並行ワーカーを実行します。CLI ワーカーは Alethe のボードには表示されません。

初回実行と設定

環境の準備状況が不明な場合、またはユーザーから尋ねられた場合は、scripts/orchestrate.py doctor を実行します。Python、プロバイダー、保存済みのポリシー、ユーザーのプレイブックのコピーを確認し、クォータの読み取り結果を実行可能なヒントとともに要約します。

doctor でポリシーが未設定と報告された場合、またはユーザーからオーケストレーションのセットアップを求められた場合は、 references/onboarding.md に従います。CLI、モデル、ルートを調査し、base、savings、aggressive のプロファイルを作成して、プレイブックのコピーへの保存前に承認を得てください。確認済みの設定のみを保存します。9router などのプロキシはモデルの通信を担いますが、ワーカーではありません。

セットアップによって作業を中断してはいけません。タスクの途中で何も設定されていない場合は、doctor を実行し、ログイン済みの CLI と付属のプレイブックを使い、その旨を 1 行で伝えて作業を続けます。現在のステップの後でオンボーディングを提案し、ユーザーが同意するまでは何も保存しません。

曖昧な設定リクエストを、次のアクションに置き換えます。

ユーザーの発言	実行すること
継続的な設定として「プロバイダー X を保存して」	確認してから、policy set --conserve-providers X を実行します
「簡単な作業には安いモデルを使って」	プロバイダーとモデルを確認してから、プレイブックのコピーにある tiers を編集します
継続的な設定として「ワーカーは最大 N 人／T 分／C ドルまで」	確認してから、policy set --max-calls N --max-wall-seconds T --max-reported-cost-usd C を実行します
上記のいずれかを「今回の実行のみ」	プランの budget に設定するか、--strategy を使います。ポリシーは変更しません
「このタスク全体で最大 N 回の呼び出し／C ドル／T トークンまで」	最初のウェーブの前に、これらの上限を budget に設定します
「どこまで進んだ？」、または会話が圧縮された後	ほかのことをする前に status を実行します
「デフォルトに戻して」	確認してから、policy reset を実行します
「プレイブックを変更して」、またはフェーズごとの役割を変更する	playbook --init を実行し、表示されたコピーを編集します。UI からも同じファイルをエクスポートできます
継続的な設定として「savings を使って」または「aggressive にして」	確認してから、プレイブックのコピーにある profile を設定します
「何をした？」「いくらかかった？」	report を実行します。確認は不要です

ショートコマンド

Claude Code では /alethe <args>、それ以外ではどこでも「alethe」の後に同じ言葉を続けると、1 つのアクションに対応します。フォルダーを指定しない実行固有のコマンドは、現在のオーケストレーションを対象にします。つまり、開始した 1 つの new、選択した use、または最後に書き込んだ run が対象です。

言葉	実行内容
平易な言葉で書かれたタスク	このスキルの説明に沿ってオーケストレーションします
何も指定しない	status。現在のオーケストレーションがない場合は、これらのコマンドを数行で一覧表示します
on、または継続的な指示（「これからは……」など）	以下の説明に沿って有効にします
always、または「always on」「in every project」	mode on --everywhere
off	mode off。デフォルトが有効の場合、これによりこのプロジェクトでのみ無効になります
off everywhere	mode off --everywhere
save、balanced、max	mode on --goal <it>
careful	mode on --care careful
report [folder]	report を実行し、独自の要約を加えず、その出力をそのまま表示します
report html、または「show the report」	report --format html。フォルダーに report.html を書き込み、開きます。Python がない場合は、references/manual.md の説明に沿って assets/report.html を作成します
status	status を実行し、その出力をそのまま表示します
usage	usage を実行します。Claude の読み取り情報がないか古い場合は、usage --refresh-claude を実行します。ウィンドウ、リセット、情報の鮮度を表示します
models	models を実行し、モデルの価格、順位、価格情報の鮮度を表示します
editor、または「show the playbooks」	editor を実行します。プレイブックをフローページとして書き込み、開きます。Python がない場合は、references/manual.md の説明に沿って assets/editor.html を作成します
list	list を実行します。use <folder> でフォルダーを再び現在の対象にします
stop	stop を実行し、ウェーブが終了したら status を実行します
budget <limit>	budget --max-calls N、--max-reported-cost-usd C、または --max-reported-tokens T
skip <phase>、switch <playbook>、freeform、add <phase>	以下の説明に沿って方針を変更します
note <text>	note "<text>"
mark <worker> used|partial|discarded	mark <worker> <mark>
setup	doctor を実行し、ポリシーが保存されていない場合はオンボーディングを行います
help	これらのコマンドを数行で一覧表示します

有効にしておく

1. 説明にあるように、依頼が範囲の明確な独立した単位に分かれる場合は、誰もオーケストレーションに言及していなくても、積極的に使用してください。小規模な作業や密接に関連する作業は自分で行います。
2. mode on --everywhere は、有効期限なしで、すべてのプロジェクトのデフォルトとして設定します。プロジェクト内で mode off を実行すると、そのプロジェクトでのみ無効になり、mode off --everywhere を実行するとデフォルトが解除されます。
3. mode on は、mode off を実行するか、プロンプトがない状態が 12 時間続くまで、現在のプロジェクト（リポジトリのルート、またはフォルダー）で有効になります。プロジェクトのモードはデフォルトより優先されます。

どちらのモードでも同じオプションを使用します。

• --goal save は支出を最小限に抑え、max は利用可能なエージェントを最大限に活用し、balanced（デフォルト）はプレイブックに効果があると記されている場合にのみ委任します。
• --care careful は書き込み前に読み取り、すべての書き込み担当を分離し、統合前にすべての差分をレビューし、元に戻すのが難しい操作の前に確認を求めます。
• --rule "<the user's words>" は継続的な指示を最大 8 件まで保持します。--clear-rules はそれらを削除します。

ユーザーが /alethe on と言う、継続的な指示を出す、または「これからは」オーケストレーションするよう求めた場合は、有効にしてください。指示が目標または慎重さのレベルに当てはまる場合はそれに対応させ、ユーザー自身の言葉をルールとして保持します。何が有効になったかを 1 行で伝えてから、ユーザーが取り組んでいた作業に戻ります。

Claude Code のフックは、モードが有効な間に注意を促します。フックがない場合は、セッション開始時とコンパクション後に mode show を実行します。目標に照らして委任のオーバーヘッドに見合う場合にのみ委任し、小さな作業は自分で行います。

作業途中から参加する

別のスキルのワークフローの途中も含め、どの時点からでも参加できます。最初からやり直さないでください。

1. すでにあるものを計画として扱います。会話、仕様書、タスクリスト、設計ドキュメント、ここまでの差分などを使います。それらをコピーするのではなく、作業者に該当ファイルを参照させてください。
2. もう一方のワークフローの手順とゲートを維持します。未完了のタスクは作業単位とし、そのチェックはゲートとします。手順で指示されている場合に限り、そのファイルを書き換えてください。
3. new は委任する作業にのみ使用します。小規模な作業、密接に関連する作業、または曖昧な作業はリードが担当し、その理由を1行で述べてください。

プレイブックを選んでから調整する

計画を立てる前に、scripts/orchestrate.py playbook --pick を実行し、アクティブなプロファイル、プロバイダーの順序、選択条件、プレイブックの概要を確認します。次に、選んだプレイブックと解決済みのティア、クォータおよび予算ルールを確認するため、playbook <id> を実行します。どちらも --json を受け付けます。プレーンな playbook は、編集またはオンボーディングの場合に限り、ファイル全体を出力します。references/playbooks.md を参照してください。

1. pickOrder に従ってプレイブックを選びます。ユーザーが指定したプレイブックがあればそれを優先します。ランナー戦略の名前が指定されている場合も同様です。これにより、後述の単一ウェーブの動作が維持されます。それ以外に適切なものがなければ、complete を作業単位ごとに調整して使用します。
2. フェーズを順番に実行します。who: lead はこのセッションのあなたを指します。それ以外の各フェーズは作業者の1ウェーブです。runner は計画の strategy、workers は作業単位の数、readOnly は mode: read-only を意味し、isolate を指定すると書き込み担当者ごとに専用のワークツリーが割り当てられます。
3. if の条件が成立しないフェーズはスキップします。with で結ばれたパスのうち、最初に条件が成立したものを実行します。フェーズの gate は自分で確認します。失敗した場合は、作業単位ごとに after チェーンを1回実行してから、もう一度確認します。
4. プレイブックファイルとアクティブなプロファイルを使って、各作業者のティアを解決し、最初に一致するルールを適用します。非推奨の policy.modelTiers による上書きが設定されている場合は、引き続きそちらが優先されます。新しいティアはプレイブックにのみ保存してください。モデルとエフォートは明示的に指定し、読み取り専用の作業には対応可能なプロバイダーを使用してください。
5. 最初のウェーブの前に、選んだプレイブックとその理由を1行で伝えてください。

クォータを監視する

目標、プロファイル、ランナー戦略を問わず、プロバイダーを枯渇させないでください。依頼の有無にかかわらず、各ウェーブの前に次の手順を実行します。

1. scripts/orchestrate.py usage を実行します。Codex の読み取り値はセッションファイルから取得し、Claude の読み取り値は各 Claude ワーカーの rate_limit_event から取得します。計画で Claude を使用する場合、またはあなたが Claude を使用する場合に、読み取り値がないか古い（30 分超）ときは、1 行の Haiku 呼び出しである usage --refresh-claude を実行します。

2. dry-run の quotaForecast を確認します。これは、過去のウェーブから学習した、各ウィンドウで今回のウェーブが消費する可能性のある量です。サンプルが少なすぎる場合は不明となるため、推測せずにその旨を伝えます。

3. プロバイダーの残量が少なく（quota.criticalThreshold 以上）、次の優先順位にあるプロバイダーが同じティアを実行できる場合は、作業を移し、数値とリセット時刻を添えてユーザーに 1 行で伝えます。「Codex に調査担当を移します。Claude は 5 時間ウィンドウの 86% で、14:30 にリセットされます。Codex は 33% です。」quota.whenSpare に従い、失われるはずのクォータを消費します。

4. 残量の少ないプロバイダーを避ける唯一の方法が、作業に必要なティアを下げることになる場合、すべてのプロバイダーの残量が少ない場合、または予測が quota.stopAt を超える場合は、起動前に停止してユーザーに確認します。作業に必要なもの、残量、リセット時刻を伝えたうえで、推奨案を含む 2～4 個の選択肢を提示します。エージェントに質問ツールがある場合は、それを使います。

   • リセットを待つ。
   • 別のプロバイダーで実行し、何が変わるかを伝える。
   • それが可能なユニットに限り、より安価なティアを使い、リスクを伝える。
   • 今すぐ、実行可能なユニットだけを実行する。
   • 別の CLI またはアカウントを接続する（setup）。
   • ユーザーの明示的な指示がある場合に限り、run --allow-low-quota でそのまま進める。

   「この移行には強いティア（Opus）が必要です。Claude は 5 時間ウィンドウの 91% で、2 時間 10 分後の 14:30 にリセットされます。このウェーブでは約 15% を消費する可能性があります。1）14:30 まで待つ（推奨）、2）現在 40% 残っている Codex high で実行する、3）機械的な 2 つのユニットだけ Sonnet で実行する、4）別の CLI を接続する。」

5. run は、quota.stopAt 以上のプロバイダーでのウェーブ実行を拒否し、キューに入っているワーカーをスキップします（failureKind: quota_low）。上限に達したワーカーは rate_limited として失敗します。どちらの場合も手順 4 に従ってください。

ユーザーが固定したプロバイダーとユーザーの回答は、このルールより優先されます。あなた自身が残量の少ないプロバイダーで実行する場合は、その旨を伝え、自分のターンを短く保ち、余裕のあるプロバイダーに作業を引き継ぎます。読み取り値が古い場合は、数値を断定せず、その旨を伝えます。変更のたびに note "<reason and readings>" --kind switch を記録します。不明な読み取り値についてはリファレンスを参照してください。

方針を変更する

ウェーブの間に、結果やユーザーの依頼に応じて計画を調整します。フェーズのスキップ、繰り返し、追加、自分でのステップ実行、プロバイダー、モデル、予算の変更、プレイブックの切り替え、または自由形式のウェーブを計画できます。プレイブックよりユーザーの依頼を優先します。

レポートで変更内容を説明できるよう、次のウェーブの前に、変更ごとに 1 行で記録します。

変更	コマンド
フェーズをスキップする	note "<phase>: <why>" --kind skip
フェーズまたはワーカーを追加する	note "<what>: <why>" --kind add
プレイブックを切り替える、または自由形式にする	note "to <playbook or freeform>: <why>" --kind switch
自分でステップを実行する	note "<what you did>" --kind lead
その他	note "<what changed and why>"

自由形式のウェーブも通常の計画です。playbook は省略し、ウェーブの内容に応じて phase に名前を付けます。役に立たなくなったウェーブは stop で停止します。すでに実行されたワーカーの結果は保持されます。

オーケストレーション

1. オーバーヘッドに見合う場合は委任します。ランナー戦略の economy と rescue では、ワーカーを 1 つ使用できます。
2. 各ウェーブで使用できるランナー戦略（auto、economy、balanced、quality、research、parallel、rescue）については、references/routing.md をお読みください。現在のリクエストで明示されたランナー戦略は、保存済みの設定より優先されます。スキルを明示的に呼び出した後に続く語が名前と一致する場合は、それをプレイブックまたはランナー戦略として扱います。
3. scripts/orchestrate.py probe を実行し、利用可能なプロバイダーのみを使用します。Agy、Kimi、ワーカーの再開、またはカスタム CLI の追加を行う場合は、references/providers.md をお読みください。
4. ライターごとに担当範囲が重ならないようにします。ライターを並行して動かす場合は分離した worktree を使用します。単独のライターで、既存のユーザー変更が保持される場合は、メインのチェックアウトを使用できます。
5. リポジトリの外部にバージョン 1 のプラン JSON を作成します。scripts/orchestrate.py scaffold <strategy> --workers N を実行すると、記入用の有効なひな形が出力されます。strategy を使用し、保存済みのプロバイダー切り替え設定によってプロバイダーが決まる可能性がある場合に限り、provider: auto を使用します。1 つのウェーブに厳格な上限が必要な場合は、プランの budget を設定します。オーケストレーションの全ウェーブに適用する上限には、budget を実行します。 プランには title、実行する playbook と phase、1 行の why を指定します。各ワーカーには、役割とそのモデルを選んだ理由が分かる短い why を指定します。これらはレポートに表示されます。 references/briefs.md の説明に従って各タスクを記述します。Codex と Claude のワーカーは MCP サーバーなしで起動します。ブリーフで MCP サーバーが必要な場合に限り、mcp: true を設定します。schemas/plan.schema.json または scripts/orchestrate.py validate を使って、プランを検証します。
6. models を実行します。必要な価格情報が欠落している場合、または古い場合（60 日超）は、ベンダーの公式価格ページのみを参照し、ユーザーに伝えたうえで、ポリシーと同じ場所にある alethe-prices.json に source と asOf を含めて保存します。推測してはいけません。references/operations.md を参照してください。 dry-run でランナー戦略、プロバイダー、並行数、プロンプトトークン数、予算、listPriceEstimateUsd（推定値）、quotaForecast をプレビューします。デフォルトモデル、プロバイダー不足、停止ラインなどの警告を解消するか、該当しない理由を説明します。 ユーザーがアーキテクチャを見たい場合は、dry-run --write でプレビューを保存し、references/diagram.md の説明に従って scripts/diagram.py でレンダリングします。ワーカーの実行前に SVG を提示し、確認済みのプロキシルートのみを使用します。
7. scripts/orchestrate.py new "<title>" --playbook <name> --why "<one line>" --lead <your CLI>:<your model>（例：--lead claude:opus）を使って、オーケストレーションを一度だけ開始します。このコマンドはフォルダーを作成して現在の対象にし、レポート内で自分をリードとして指定します。すべてのウェーブは run <plan> --in current --detach で開始し、その後 wait [--timeout N]（最大 540 秒）を呼び出して、done が true になるまで待機します。これによりステータスも返されます。Claude Code では、代わりにシェルツールのバックグラウンドモードを使用できます。タイムアウトの短いシェルツールで、ウェーブをフォアグラウンド実行してはいけません。中断されたランナーは検出されます。stop は残ったワーカーも終了させます。ランナーは並行数と予算に上限を設け、レビュー用に worktree を残します。引数配列を使用します。読み取り不能な .cmd シムは、references/providers.md の引数制限に従う場合に限り、cmd.exe 経由で実行されます。
8. state.json、各 outcome.json（まず workerStatus、failureKind、readOnlyViolation）、簡潔な result.md、ライターの diff.patch ファイルを読みます。失敗の診断時を除き、生ログを読み込まないでください。
9. レビュー済みの変更を統合し、統合後のチェックアウトで検証を実行します。各ワーカーの結果を used、partial、discarded のいずれかで mark し、有用な変更の処理が済んだ一時データと worktree のみを削除します。mark <worker> used は、現在のオーケストレーションからワーカーを検索します。
10. 最後に scripts/orchestrate.py report を実行し、その出力を提示します。作業内容、理由、変更点、報告された支出、残作業を含めます。ユーザーから費用について質問された場合も、このレポートを使用します。フォルダーが指定されていない場合は、現在のオーケストレーションが対象です。 プランの例、結果の意味、選択的なダーティ状態のシード、クリーンアップについては、 references/operations.mdをお読みください。

ワーカーの契約

各ブリーフには、タスクの目標、完了の定義、担当するパス、関連するリポジトリのルール、チェック項目、 禁止されている変更、希望する引き継ぎ内容を記載する必要があります。ランナーは次の不変条件を自動的に追加します。

• 委任、サブエージェントの起動、別のエージェント CLI の起動を行わない
• コミット、プッシュ、タグ付け、リリース、プルリクエストの作成を行わない
• 簡潔な結果、根拠、変更したファイル、チェック項目、失敗、リスクを報告する
• STATUS:行（DONE、DONE_WITH_CONCERNS、BLOCKED、NEEDS_CONTEXTのいずれか）と SUMMARY:行で終了する

Codex と Claude のワーカーはサブエージェントを起動できません。ランナーが CLI でその機能を無効にします。すべての ワーカーはALETHE_ORCHESTRATE_WORKER=1を設定して実行されるため、独自のオーケストレーションを開始できません。ワーカーの ステータスと要約は申告内容です。差分を確認してください。レビュー、検証、判定、パネル向けのブリーフについては、 references/briefs.mdに従ってください。

プラン、タスク、引数、ログにシークレットを記載しないでください。ユーザーが分離性の喪失を明示的に求めていない限り、バイパス用フラグを使用しないでください。カスタムワーカーで既知の危険なフラグを使用するには、allowUnsafe: trueが必要です。

トークンの管理

• 「トークンが少ない」「クォータを節約する」「節約する」などの発言は、現在の実行に対するランナー戦略economyとして扱います。ユーザーが今後のデフォルトとして設定するよう求めた場合に限り、policy set economyで永続化してください。
• プランのbudgetは、節約を厳格な上限にします。ワーカー呼び出し数、実行時間、推定プロンプトトークン数、報告トークン数、報告コストに上限を設けてください。実行前に見積もりを確認するにはdry-runを使用します。コストを報告するのはClaudeだけなので、maxReportedTokensで他のワーカーの上限を設定します。キャッシュ読み取りは別途報告され、maxReportedTokensおよびレポートのValueトークン内訳には含まれません。
• ワーカーを増やすと、プロバイダーの総使用量も増えます。タスクを直接完了する方が安価な場合、autoはオーケストレーションを選んではいけません。オーケストレーションが明示的に要求されている場合は、有効なランナー戦略のうち最小のものを選びます。
• ファイルの内容をコピーするのではなく、ファイルを参照してください。トランスクリプトではなく、簡潔な結果と差分を確認してください。
• sessionIdは、対象を絞ったフォローアップに限って再利用してください。範囲が限定された調査や機械的な作業には低コストのワーカーを使い、曖昧さへの対応や統合作業はリードまたは有能なレビュアーに任せてください。
• 失敗したワーカーを再試行できるのは、エラーに修正可能な具体的原因がある場合に限り、1回だけです。

ユーザーが明示的に依頼しない限り、コミット、プッシュ、タグ付け、リリース、プルリクエストの作成を行わないでください。