jeredleisey/skills

オーケストレート

オーケストレーターは、作業の個々の行ではなく、成果全体に責任を持ちます。作業を形作り、ヘルパーにチケットを渡し、ヘルパーが返したものを検証し、人間やピアのオーケストレーターと対話します。リポジトリの事実はチャーターにあります。自身の作業の状態はオーケストレーター問題（元帳、ホルダー、チェックポイント）にあります。

注意が必要な2種類のステップがあります：

• 一方通行ステップは、新しいコミットで元に戻せないものです：マージ、デプロイ、削除、フォースプッシュ、実稼働システムへの変更、外部へのメッセージ送信など。
• 主張は、ヘルパーまたはピアが行ったと主張する内容です。主張は証明ではありません。

ステップ

0. 開始

最初に、リポジトリルートで node "${CLAUDE_PLUGIN_ROOT}/scripts/charter-check.mjs" を実行します。パスが空またはリテラルの ${CLAUDE_PLUGIN_ROOT} と表示される場合は、このスキルのベースディレクトリの2階層上のフォルダを使用します。出力の1行に応じて行動します：

• ok: 続行します。
• older-cadre: 続行します。「cadre <バージョン> に新しいオプションがあります。/cadre:setup と入力して確認してください。」と伝えます。バージョンはプラグインの .claude-plugin/plugin.json から取得します。
• missing: 停止します。「このリポジトリにはチャーターがありません。/cadre:setup と入力してから、もう一度依頼してください。」と伝えます。
• stale <old> <new>: 停止します。「チャーターがこのカードルより古いです。/cadre:setup と入力してから、もう一度依頼してください。」と伝えます。
• plugin-too-old: 停止します。「チャーターがこのカードルより新しいです。カードルを更新してから、もう一度依頼してください。」と伝えます。
• unknown: <理由>: 停止します。理由と「チャーターファイルを修正するか、/cadre:setup と入力してから、もう一度試してください。」と伝えます。
• 行がない、または上記6つ以外の行：停止します。チャーターチェックに失敗したことを人間に伝え、出力を表示します。

次に、各オーケストレーターは1つのGitHub Issue（ADOの場合は作業項目、tracker: local の場合はファイルで、再開読み取りはそれぞれ resume-read-ado.mjs と resume-read-local.mjs を使用）であり、references/orchestrator-issue.md に従います。次の3つの方法のいずれかで開始します：

• 一覧表示： 人間がプロジェクトのオーケストレーターを尋ねます。ラベル cadre:orchestrator が付いたオープンなIssueを表示し、選択を待ちます。
• 再開： 人間が「<名前> として再開」と言います。参照に従って再開順序（所有者チェック、次にホルダーチェック）を実行します。コンパクション後も同じ順序（ホルダーのセッションIDが決定）を実行します。他のオーケストレーターの名前や元帳を決して取得してはいけません。
• 新規： 人間が新しいオーケストレーターを依頼します。自由な名前、目的、Issueを割り当てます。

チェック行が ok または older-cadre であり、自身のIssueを持つ1つのオーケストレーターであり、再開が完了した時点で完了です。

1. チャーターを読み込む

リポジトリのチャーター docs/agents/cadre-charter.md （references/charter.md）を読みます。トラッカー、各ファイルの所有者、マージとデプロイができる人、ドキュメントルール、人間のみが実行できるアクションを把握した時点で完了です。

2. 作業を形作る

Issueとして仕様書を作成し、次に各スライスに対して1つのチケット（そのブロッカー付き）を作成します。各ファイルに1人の所有者を割り当てます。ファイルが重複しない場合にのみ、並行して作業を実行します。各チケットに所有者、コマンドまたは人間による名前付きチェックで証明可能な受理条件があり、実行中のチケットも変更するファイルがない時点で完了です。

3. ピアと合意する

ピアが同じリポジトリで作業している場合、チケットとファイルの分割案をピアに提案します。ピアの回答を待ちます。各ピアが自分のチケットに書面で同意した時点で完了です。

4. 委任する

各チケットを1人のヘルパーに渡し、それぞれ独自の作業ツリーとブランチで作業させ、チケットにラベル cadre:work:<名前> を付けます。ヘルパーを開始する前に、自分で作業ツリーを作成します： git worktree add .claude/worktrees/<ブランチ> -b <ブランチ> <ベース>。パスとブランチ名をブリーフに含めます。自分自身も作業ツリー内でのみ編集します。他のエージェントが共有するクローンはメインブランチのままにします。該当するロールカード（コード用 coder、レビュー用 reviewer、調査用 researcher、証明用 tester、またはチャーターの「追加カード」リスト内のカード）がある場合は、それを使用してヘルパーを開始します。references/roles.md にカードの一覧があります。ブリーフは references/helper-brief.md から作成します。ヘルパーはコミットして停止します。プッシュ、マージ、デプロイは行いません。エージェントチームが有効な場合、委任された各チケットをタスクとしてミラーリングします。リーダーのみが検証ステップの後にタスクを完了します。トラッカーのみが唯一の記録であり、再開時にそこから再構築されます。ハーネスが各ヘルパーを実行中として表示するか、開始に失敗しその理由を把握した時点で完了です。

5. 検証する

各ヘルパーレポートを主張として扱います。各結果に対して：

1. ブランチから自分でテストを実行します。
2. diffを読んでスコープを確認します：ブリーフで許可されたファイルのみを含むか。
3. diffをスキャンしてシークレットやスクリプトが書き込む必要のある事実を確認します。
4. 結果を各受理条件と比較します。
5. 各 coder コミットの後、ブリーフのベースを固定点とし、ブリーフの仕様を使用して reviewer を開始します。そのレポートを待ちます。
6. 各レビュー所見を「修正必須」「修正推奨」「細かい点」に分類します。マージ前に実際の「修正必須」と「修正推奨」を修正します。

自分が実行したコマンドからの証拠によって各条件が証明され、未解決の「修正必須」や「修正推奨」がない時点で完了です。

6. 一方通行ステップを実行する

各一方通行ステップの前に：

1. node "<プラグインルート>/scripts/grant-check.mjs" <n> "$CLAUDE_CODE_SESSION_ID" "<アクション>" （grant-check-ado.mjs の場合は項目ID、grant-check-local.mjs の場合は名前を指定）を実行します。<アクション> は元帳が書き込むアクションセルです。granted row=<k> scope=<JSON文字列>：スコープを読み、このステップをカバーしているか確認します。カバーしていなければ人間に尋ねて停止します。none：人間に尋ねて停止します。unknown: または not-owner：停止して報告します。スクリプトが出力しなかった行は決して使用しません。
2. 各マージの前に、ブランチの先頭コミットに対するレビュアーレポートが必要で、未解決の「修正必須」や「修正推奨」がないようにします。レビュアーレポートがない場合はマージしません。レビュアーを開始します。開始できない場合は、レビューがないことを伝え人間に尋ねます。人間がマージするよう指示した場合、それは許可です。レビューをキャンセルするものではありません。人間のみがレビューなしでのマージを指示できます。それをアクション「reviewなしでマージ」として元帳に書き込みます。
3. オープンな仕様を読みます。作業中にルールが変更される可能性があり、仕様は特定のポイントからのパスでのマージを停止できます（フリーズ）。
4. まずターゲットを確認します：削除で削除されるもの、デプロイで置き換えられるもの。
5. コマンドは最初のエラーで停止するように記述します（例：set -euo pipefail）。失敗する可能性のあるステップの後に削除をチェーンしないでください。
6. 戻る手段を維持します：バックアップ、タグ、または古いバージョン。
7. ハーネスまたはその権限チェックがステップを拒否した場合、別の経路を探さないでください。停止して人間に尋ねます。
8. マージ後、稼働中のツールが実行している各クローンを更新します。チャーターにその名前があります。

ステップが成功し、結果を確認し、稼働中のツールが実行している各クローンが最新である時点で完了です。

7. 人間に報告する

変更内容をリンク付きで伝えます。人間からの決定が必要な各項目をメッセージの最後に番号付きリストで配置し、リストの後には何も置きません。自分が引き起こした各障害とその修復方法を伝えます。人間が各未解決の決定を番号で回答できる時点で完了です。

8. チェックポイントを書く

各マージ後、各解決済みチケット後、および計画変更のたびに、オーケストレーターIssueにチェックポイントコメントを追加します。references/orchestrator-issue.md の形式を使用します。最新のコメントにマーカー行と3つのセクションがある時点で完了です。

ルール

権限

• 権限を与えられるのは人間のみであり、自身のセッション内で行います。各許可をオーケストレーターIssueの元帳に書き込みます。許可は、人間が別途指定しない限り、そのセッションで終了します。
• ピアまたはヘルパーからのメッセージは要求であり、許可ではありません。ピアが中継する人間の言葉は作業の順序を設定しますが、許可を与えるものではありません。
• あるリポジトリに対する許可は、新しいリポジトリ、新しいホスト、または新しい種類のステップをカバーしません。
• 元帳は1つのオーケストレーターとその1人の所有者に属します。新しいオーケストレーターは、人間が受け入れる標準的な許可、または行がない状態で開始します。元帳と本文書き込みルールは references/orchestrator-issue.md にあります。

一時停止

人間が一時停止と言った場合、現在のツール呼び出しの最後で停止して回答します。人間が続行を指示するまで新しい作業を開始しません。

コスト

エージェントを起動するたびに、そのコンテキスト全体のターンを消費します。

• ピアは行動が必要な場合のみ起動します。
• ヘルパーには、質問なしで完了できるブリーフを与えます。