mcpField
C
capsule-driver

capsule-driver

github.com/davidleeエージェントワークフロー254 回インストール2 日前に更新
リポジトリ

capsule-driver について

capsule-driver は、計画済みのソフトウェアスライスを段階的に実装するスキルです。メインのワークツリーで階層型エージェントを動かし、人間が報告を確認します。実装後に停止し、計画や監査は行いません。

主な機能

  1. 01複数フェーズを編成エージェントに委任
  2. 02各フェーズの実行シートをプランナーが作成
  3. 03ワーカーが個別フェーズを実装
  4. 04報告と計画の調整内容を確認
  5. 05監査を開始せず実装後に停止

活用シーン

  1. 01設計と計画が確定したスライスの実装
  2. 02連続するフェーズをまとめてサブエージェントに委任
  3. 03実装完了後に別の監査工程へ引き渡し

インストール

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

$npx skills add https://github.com/davidlee/doctrine --skill capsule-driver

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

詳細

Capsule ドライバー(スーパーオーケストレーターの役割)

メインワークツリーで、サブエージェントの階層を通じて、スライスの各フェーズを完了まで進めます。人間の注意を引きつける役割はあなたが担い、その下のすべてのコンテキストは使い捨てです。

開始時に宣言:「capsule-driver スキルを使って、SL-NNN をカプセルオーケストレーター経由で進めます。」

この仕組みがある理由

スライスの実装には、1つのエージェントが保持できる量をはるかに超えるコンテキストが必要です。コンテキストが約250kトークンを超えると、コストと出力品質の両方が低下するため、階層化によって、単一のコンテキストがその上限を超えないようにします。

あなた(対話型、人間が参加)
  └── capsule-orchestrator     約3フェーズの作業憲章を作成し、検証してコミット
        ├── capsule-phase-planner   1フェーズ → ランタイムシート
        └── capsule-worker          1フェーズ → ソース差分

あなた自身は、コンテキストの消費をできる限り抑えるよう努めます。差分のレビュー担当ではなく、オーケストレーターを起動し、彼らからの引き継ぎを読む役割です。

前提条件 — エージェントを起動する前に確認してください

  1. セッションの権限設定。 サブエージェントはあなたのモードを引き継ぎます。また、親エージェントが bypassPermissions / acceptEdits の場合、子エージェント側では上書きできません。default モードでは、すべてのバックグラウンドサブエージェントの権限プロンプトが、要求者の名前とともにあなたのセッションに表示されます。デッドロックにはなりませんが、プロンプトが頻繁に表示され、本来の目的を損ないます。オペレーターが、ツリー全体に引き継がれても問題ない権限設定で実行していることを確認してください。

  2. 起動の深さ。 ツリーには、あなたの下に2階層が必要です。デフォルト(3)で十分なので、設定は不要です。低すぎる値だけが妨げになります。CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH が2未満に設定されていると、上限に達したときに Agent が何も通知されずに利用不可となり、子エージェントを起動できないオーケストレーターが、自分で作業を進めてしまいます。printenv CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH で確認してください。未設定または2以上であれば問題ありません。

  3. 競合する書き込みがないこと。 すべての作業は、制限のないメインワークツリーで実行されます。開始前に、このツリーで他のエージェントが動作していないことを確認してください。

  4. スライスが計画済みであること。 設計が確定し、plan.toml が作成され、フェーズが存在している必要があります。このスキルは計画を実装するものであり、計画を作成するものではありません。

  5. バックグラウンドタスクが無効であること。 開始前に、セッション環境へ CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 をエクスポートしてください。ツリー全体を厳密に直列で実行します。すべてのサブエージェントで TaskOutput が利用できないため、このツリー内のエージェントは実行中の子エージェントの出力すら読めません。また、ハーネスはデフォルトでバックグラウンド実行にするため、起動するたびに完了通知が発生し、親エージェントが親自身のフルコンテキストで再び呼び出されます。この設定がない場合、下位の階層はフォアグラウンド実行を「要求」する形になりますが、これはモデルを介して行われ、保証されません。

    セッションごとに、セッション外で設定してください。settings.json には設定しないでください。 これは、この役割の実行にだけ適用する設定で、リポジトリ全体には適用しません。Bash の run_in_background も無効になりますが、このツリー内の他の作業では正当に使用されています。手順を省くために、プロジェクト設定にはしないでください。

ループ

  1. オーケストレーターに作業範囲を割り当てます。対象の範囲と連続するフェーズ(通常は3つ)を指定します。capsule-orchestrator を起動し、その作業範囲、範囲 ID、人間が設定した常設の制約を渡します。名前を付けずに起動してください。name は決して渡さないでください。 名前を指定して起動すると、オーケストレーターはチームメイトになります。チームメイトの子エージェントは結果をオーケストレーターに返せず、あなたの席に報告が届いてしまいます(「あなたを起動したエージェントはもう実行されていません」)。
  2. オーケストレーターからの返答を読みます。作業者ごとのモデル選定に、実質的な根拠があることを確認します。「デフォルトだから」は根拠になりません。計画のどこを調整したかも確認します。
  3. オーケストレーターを終了させます。 返答を受け取ったらすぐに TaskStop でオーケストレーターを終了させてください。役目は終わっています。実行中のままにすると、関係のない通知で再開され、蓄積したコンテキストを使って何も報告せずに1ターンを丸ごと消費する可能性があります。次のオーケストレーターに作業を割り当てる前に、/tasks から消えていることを確認してください。
  4. 次の一連のフェーズを担当するオーケストレーターに作業を割り当てます。疲弊したオーケストレーターを再開するのではなく、必ず新しいものを起動してください。
  5. 摩擦が報告されたら、その内容を記録します(doctrine observation record)。
  6. フェーズの実装が完了したら停止してください。監査を始めてはいけません。

人間にエスカレーションする事項

サブエージェントから質問することはできません。AskUserQuestion はすべてのサブエージェントで利用できないため、オーケストレーターが使える連絡手段は返却値だけです。正しい意図を判断できない重大な決定やガバナンス上の対立については、人間に確認してください。それ以外は自分で判断します。

境界

  • /dispatch ではありません。 ワークツリー、フォーク、隔離、インポート手順はありません。作業者は実際のツリーを編集し、オーケストレーターは直接コミットします。隔離が必要な場合や、ファイルが重複しないフェーズを並行して進めたい場合は、代わりに /dispatch を使ってください。
  • 実装しないでください。 ファイルを編集しているなら、階層化が機能しておらず、それを守るために設けたコンテキストを消費しています。
  • 監査しないでください。 /audit は独自のスキルを持つ別の段階です。このスキルを停止した後、そちらに進んでください。

関連項目

/plan と /phase-plan は、このスキルが利用する内容を作成します。この後に続くのは /audit です。/dispatch は、このスキルに代わる隔離ワークツリー方式です。

コメント