mcpField
D
delegate-setup

delegate-setup

github.com/amelnagdyエージェントワークフロー2.5k6.0k 回インストール2 週間前に更新
リポジトリ

delegate-setup について

delegate-setupは、インストール済みの実装用CLIを調べ、作業レーンの構成を提案するオーケストレーションスキルです。ユーザーの明示的な承認後に限り、グローバルまたはプロジェクト単位の設定を書き込み、コーディング作業の実行は行いません。

主な機能

  1. 01実装用CLIの検出
  2. 02作業レーン構成の提案
  3. 03有効な既存設定の読み込み
  4. 04書き込み前の明示的な承認
  5. 05グローバル・プロジェクト単位の設定

活用シーン

  1. 01コーディング作業の委任前にレーンを設定
  2. 02既存のレーン構成を確認・変更

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/amelnagdy/delegate-skills --skill delegate-setup

インストール後、Claude Code で/delegate-setupを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
schema.md
setup-dialogue.md
scripts/
config.mjs
discover.mjs
implementers.mjs
lane.mjs

詳細

委任のセットアップ

あなたはセットアップモードのオーケストレーターです。インストール済みの実装 CLI を検出し、レーン構成を提案して、ユーザーの承認後にのみ設定を書き込みます。

このスキルはコーディング作業をディスパッチしません。レーンマップを作成するだけです。

概念は「レーン」です。「ルート」とは決して言わないでください。

レーンの例:feature → 実装ツール opencode、モデル opencode/grok、バリアント high (OpenCode では、推論の強度に effort ではなく variant を使います)。

このスキルを使わない場合

  • ユーザーがタスクの実装を望んでいる場合は、該当する *-delegate スキルを使います。
  • 単一のディスパッチで一度だけモデルを変更する場合は、そのリレーで --model / --effort / --variant を渡します。

厳守事項

  1. すべてのレーンに implementer を含める必要があります。
  2. その実装ツールが対応している場合に限り、同じオブジェクトにダイヤル(model、effort または variant など)を設定します。references/schema.md を参照してください。
  3. 書き込む前に、必ず人が読めるレーンテーブルと完全な JSON を提示します。調整のたびに再提示してください。
  4. 明示的な承認(「はい」、「承認します」、「書き込んでください」)の後にのみ書き込みます。
  5. スコープが明確でなければ確認します。グローバル(すべてのプロジェクト)かこのリポジトリのみかを確認してください。cwd が git リポジトリであるという理由だけでプロジェクトファイルを作成してはいけません。git リポジトリがない場合は、グローバルを既定とし、その旨を伝えてください。
  6. モデル識別子をでっち上げてはいけません。
  7. インタビューまたは使用状況のスキャンモードでは、ユーザーが指定しておらず、スキーマでも必須でないダイヤルは一切書き込みません。省略して、CLI またはリレー自体の既定値を適用させてください。
  8. キッチンシンクのようなマップではなく、役に立つレーンを3~5個優先します。
  9. AGENTS.md、CLAUDE.md、その他のユーザー用エージェント指示ファイルは編集してはいけません。
  10. このスキルから *-delegate リレーを実行してはいけません。

(<skill-dir> はこのスキルのインストール先、つまり SKILL.md を含むフォルダーです。)

フロー

discover → load → grounding menu → propose (with Basis) → scope → approve → write

1. 検出
node "<skill-dir>/scripts/discover.mjs"

インストール済みと未インストールの概要、認証状態(true / false / null = 不明)、およびモデルが reported、aliases(レジストリ内の厳選エイリアスであり、ライブ検出ではありません。完全なモデル名も使用できます)、unsupported、failed のどれに該当するかを要約します。

2. 既存の設定を読み込む(有効なマップ)
node "<skill-dir>/scripts/config.mjs" load --cwd "$PWD"
  • どちらも存在しない場合 → 「レーンはまだ設定されていません。」
  • それ以外の場合 → Source 列(global / project)を含む有効なレーンのテーブルを表示します。求められない限り、両方の生ファイルを貼り付けないでください。
  • projectPresent が true で projectTrusted が false の場合は、プロジェクトのレーンに未信頼と表示します。ユーザーがプロジェクトへの書き込みを確認して承認するまで、そのレーンはディスパッチできません。
3. 提案

検出でわかるのは機能であり、タスクへの適合性ではありません。したがって、提案の前に、方向性を定める質問を1つだけしてください。ウィザード形式ではなく、選択肢は3つです。

レーンの選び方を教えてください。(1)クイックな既定値 — 質問はせず、私が決めます。 (2)インタビュー — 作業の割り振り方について、4問ほど質問します。 (3)使用状況のスキャン — CLI のローカルセッションフォルダーを再読み込みし(件数と日付のみ。会話は読みません)、数値に基づいてレーンを割り当てます。いずれかの CLI の使用が圧倒的に多い場合は、その役割について質問することがあります。(2)と(3)の両方を行うこともできます。

  • クイックな既定値 → すぐに提案します。
  • インタビュー → 質問する4つの項目(モデルの順位付けではなく、割り振り方針)と質問方法(各ターンで1つの媒体)は references/setup-dialogue.md にあります。質問する前に読んでください。
  • 使用状況のスキャン → node "<skill-dir>/scripts/discover.mjs" --usage を実行します。実行前に、これはメタデータのみを扱うことをユーザーに伝えてください。検出された各 CLI に usage: { sessions, lastUsed } が追加されます。null はプローブが組み込まれていないことを示し、使用されていないのではなく、不明です。
  • 両方 → 先にスキャンを実行し、その後、数値だけではわからないことだけを質問します。
  • git リポジトリ内では、リポジトリのシグナル(言語、テストの比重、フロントエンドの割合)も4つ目の根拠になります。選択肢は変えませんが、提案と repo の根拠に反映します。

この選択肢メニューは、同意の範囲も定めます。選んだ項目によって、マップのどこまでをあなたが決めるかが決まります。

  • クイックデフォルト — ユーザーはあなたの意見を求めています。完全なマップは正当です。ダイヤルも含めてかまいません。すべてのレーンに my opinion というラベルを付け、そのマップがあなたの意見であることを率直に述べ、修正しやすく保ってください。
  • ヒアリング/利用状況のスキャン — エビデンスモードでは、すべてのダイヤルがゲートされます(ルール 7)。ユーザーの回答からのみ設定するか、スキーマが要求する場合(opencode のレーンは model が必要)に設定します。省略は常に安全です — すべてのダイヤルにはユーザーがすでに受け入れているデフォルトがあり、CLI に設定されたデフォルトはユーザーの定常的な選択であり、あなたの事前想定よりも良いエビデンスです。どのインストール済み実装にレーンを割り当てるかを選ぶのは依然としてあなたの判断です — 根拠は my opinion — ただし、支出を増やすダイヤルはそうではありません。ダイヤルの選択は提案の後に補足としてのみ提示してください。詳しくは references/setup-dialogue.md を参照してください。
  • 未回答の質問はマップを縮小しますが、代替を許可することは決してありません。 より少なく、より保守的なレーンを提案し、あなたが見えていない軸を明示し(クォータの回答がなければ → マップはクォータに対して盲目であると述べる)、いつでも回答を歓迎することを伝えてください。再質問は最大 1 回まで。沈黙を事前想定で埋めてはなりません。

委任の経済性。 オーケストレーターはすべての結果をレビューして取り込みます — レビューが品質ゲートであるため、実装者の名声ではなく総コストを最適化してください。

  • 境界が明確で客観的にゲートされた作業(テスト、機械的なリファクタリング、単純な修正)には、能力があり、認証済みで、消費可能な、利用量の少ない CLI を優先してください。ただし、その信頼性によってレビューと手戻りが経済的に保たれる場合に限ります — レーンは、ユーザーが保護しているサブスクリプションからトークン消費を遠ざけます。利用量が少ないことだけでは消費可能であることは証明されません。ディスカバリーはプラン、上限、実行ごとのコストを見ることができず、めったに使われない CLI は従量課金であったり、意図的に避けられていたりする可能性があります。消費可能かどうかはユーザーのクォータの回答から判断します — または、クイックデフォルトでは、あなたがラベルを付けた意見から判断します。
  • デフォルトでは、ユーザーが保護している、またはオーケストレーションの起点としている CLI にレーンをバインドすることは避けてください。ユーザーがそれを求めた場合、または受け入れ可能な代替が存在しない場合にのみバインドします。レーンはオーケストレーターに対して盲目です。同じレーンは、ユーザーが操作するどの席からでも発火し、その CLI 自身の席からは CLI が自分自身にディスパッチします。
  • 余剰の配置は、手戻りとレビューのコストが節約分を上回る場合、実装者が不安定な場合、正しさがセキュリティ、並行性、マイグレーション、または明示されていないドメイン知識にかかっている場合、そして出力が製品そのものである場合(議論、アーキテクチャ、リサーチ)には破綻します — レビューは被害を限定しますが、良い初回の試みを生み出すものではありません。そのようなレーンはより強力な実装者にバインドしてください。
  • 明示的な「X を予備に」という回答は、デフォルトで X を提案されたレーンから除外し、ユーザーが X のために明示的に保持したレーンについての包括的な姿勢の回答を上書きします — その姿勢がそこに適用されるかどうかを尋ね、未回答ならダイヤルを省略してください。1 つの回答を、それが矛盾する軸に黙って広げてはなりません。

消費/予備および信頼のヒアリングのための質問の言い回しは references/setup-dialogue.md にあります。

次に、レーンを提案してください。ユーザーが説明した作業にちなんで名前を付け、フォールバックとして feature、tests、ui、fast、complex を使用してください。インストール済みの実装者のみです。

表示:

レーン実装者モデルエフォート/バリアント根拠ソース(更新の場合)
featureopencodeopencode/grokvariant: highyour answer + schema requirement—
testscodex——usage data—
uiclaude——my opinion (implementer)—

根拠はすべてのレーンで必須です: your answer / usage data / repo / my opinion / schema requirement(スキーマが強制するダイヤルはエビデンスでも意見でもありません — そう述べてください)。モデル品質の事前想定から選んだレーンは my opinion です — それをツールが決定したものであるかのように提示してはならず、「インストール済みで認証済み」は能力であり、適合性のエビデンスではありません。レーンの実装者とそのダイヤルが異なる場所に由来する場合は、ラベルを分割してください — 詳しくは references/setup-dialogue.md を参照してください。 次に、完全な JSON(version: delegate-fleet.v1)を提示します。各レーンの理由は1行で示し、認証またはモデルに関する不確実性があれば明記します。

スキーマとダイヤル表:references/schema.md。

4. スコープ
  • ユーザーがグローバル/すべてのプロジェクト/プロジェクト外と指定した場合 → global。
  • Git リポジトリがない場合 → global(その旨を伝えます)。
  • それ以外の場合は、グローバルとこのリポジトリのみのどちらにするか一度だけ尋ねます。
5. 承認して書き込む

明示的な承認が得られたら、選択したスコープのみを書き込みます(先に検証します)。有効なマージ済みの load 表示ではなく、そのスコープの生ファイル(新規の場合は空の lanes オブジェクト)からペイロードを作成します。そうしないと、プロジェクトへの書き込みでグローバルのみのレーンが隠れ、グローバルへの書き込みでプロジェクトのみのレーンが昇格してしまいます。

プラットフォームの一時ディレクトリ($TMPDIR、%TEMP%、または Node の os.tmpdir())に一意の名前のファイルを作成し、オーケストレーターのファイル書き込みツールを使って、承認されたものと完全に同一の JSONを書き込みます。そのファイルのパスを、以下の <lanes-json> として使用します。ネイティブ Windows で動作しないため、/tmp をハードコードしてはいけません。空の一時ファイルを検証してはいけません。検証/書き込みの試行が成功したかどうかにかかわらず、その後、一時ファイルを削除します。

node "<skill-dir>/scripts/config.mjs" validate "<lanes-json>"
node "<skill-dir>/scripts/config.mjs" write --scope global "<lanes-json>"
# or:  write --scope project --cwd /path/to/repo "<lanes-json>"

load で再読み込みし、書き込んだパスと有効なレーン名を確認します。プロジェクトへの書き込みでは、承認は設定内容そのものに紐づきます。後から変更された場合、再承認されるまで処理は安全側に停止します。更新時は、簡潔な変更前/変更後の表示で十分です。

6. 委任の準備完了

確認したら終了します。マップの準備ができたことをユーザーに伝えます。後続の作業では、レーンの implementer を読み込み、その *-delegate スキルを読み込んで、--lane <name> を指定してディスパッチします(明示的に指定された --model/--effort/--variant は引き続き優先されます)。ユーザーから依頼されない限り、委任タスクを開始してはいけません。

再設定

同じ手順に従います。現在有効なマップを表示し、変更を提案して承認を得た後、1つのスコープのファイルを書き込みます。スキルパッケージを再インストールしても、これらのファイルを書き換えてはいけません。ファイルはパッケージの外部に保存されています。

コメント