mcpField
C
collaborative-delivery

collaborative-delivery

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

collaborative-delivery について

Collaborative Deliveryは、計画済みのタスクを所定のパネルワークフローで進めるスキルです。各フェーズの役割別応答、決定、検証記録、引き継ぎ資料を残します。

主な機能

  1. 01順序に沿ったデリバリーフェーズの実行
  2. 02タスクと役割ごとのコンテキスト分離
  3. 03パネルの応答と異論の記録
  4. 04検証と引き継ぎの記録

活用シーン

  1. 01パネルの監査記録を伴うタスクの遂行
  2. 02テスト証拠とレビュー決定の追跡

インストール

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

$npx skills add https://github.com/robsonrung/rar-skills --skill collaborative-delivery

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

同梱ファイル

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

agents/
openai.yaml
assets/
routing.toml
references/
output_contract.md
workflow_contract.md

詳細

共同デリバリー

モデルを選択する前にブランチを選択してください。現在のコーディネーターでタスクとパネルの役割を選択してください。パネルの役割を開始する前に、shared/references/model-preview.md を使用して、承認済みルートスナップショットを1つ割り当ててください。

モデル ID、対応する作業量、タスクのデフォルト設定は、すべて shared/model-routing.json のみを参照してください。ディスパッチ、 再試行、再開の際も承認済みスナップショットを維持してください。

承認済みのタスク計画があり、パネルの監査証跡が必要な場合にのみ使用してください。これは通常の実装パスより意図的にコストが高くなっています。このスキルを選択した場合、パネルは必須です。

開始前に shared/collaborative-panel-runner.md と shared/references/host-model-execution.md を読んでください。これらのドキュメントでは、 パネルランナー、実際の参加に関するルール、ステータス分類、完了確認、ネイティブ委任、セッションのルールを定義しています。assets/routing.toml は、1つのホスト用に編集可能なデフォルト設定です。shared/references/task-shaped-model-routing.md を使用して、選択した役割を承認済みスナップショットに割り当ててください。正確なモデル、実行パス、作業量、検証ポリシーをユーザーに提示してください。設定されたモデルラベルは、実際のサービングモデルを示す証明にはなりません。

成果

記録された red、green、refactor、review、verification、handoff の証跡を伴うタスクを1つ完了します。各フェーズは、必要な役割から実際の応答が記録された場合にのみ完了となります。生成されたプロンプトは参加とはみなされません。

ワークフロー

  1. タスクを1つ選び、受け入れ条件、想定されるファイル、最も範囲の狭い検証コマンドを言い換えて提示します。いずれかの役割を開始する前に、スナップショットの上限に照らして、計画されているフェーズ呼び出しと並行実行数を記録します。
  2. フェーズを次の順に実行します:task_intake、red、green、refactor、review、verification、handoff。各フェーズを通じて、タスクと役割ごとに分離されたコンテキストを1つずつ維持します。実装者、レビュアー、統合担当者、敵対的検証役が同じコンテキストを共有することはありません。
  3. 各フェーズには、統合と敵対的検証の基準役割が含まれます。設定された専門役割は、それぞれ独立した応答を追加します。現在の作業範囲がその領域に関わる場合に限り、フェーズの役割として backend または interface を追加します。
  4. red では、失敗するテストを追加または更新し、想定どおり失敗したことを記録します。green では、そのテストを通過させるための最小限の変更を行います。refactor では、テストが通過した状態を保ちながら、簡素化のみを行います。
  5. review では、正確性、データとセキュリティのリスク、保守性、タスクとの適合性を確認します。verification では、コマンド、結果、実行を見送ったチェックとその理由を記録します。
  6. handoff では、変更したファイル、動作、根拠、決定事項、制限事項、次のタスクを記録します。

有効なホストから利用可能な正確なモデルを使用する場合は、永続的なネイティブサブエージェントまたはサポート対象のタスクコンテキストを使用してください。ランナーを使用するのは、別のモデル、またはホストが提供できない正確なルートを使う場合に限ります。コード変更の責任はホストにあります。ルーティングで実装役割が明示的に委任されている場合を除き、パネルの役割は決定事項に異議を唱え、レビューし、方向付けます。異論は決定ログに残してください。役割が1つでも欠けている場合、完全なパネルとはみなされません。不足を容認された例外として報告できるのは、ユーザーが明示的に承認した場合に限ります。

成果物

ユーザーが別の場所を指定しない限り、次のファイルを .ai-workflow/panel/delivery に保存してください。

  1. execution_log.md
  2. test_evidence.md
  3. review_notes.md
  4. changed_files.md
  5. decision_log.md
  6. panel_summary.json

パネルのステータスを解釈したり、最終確定したりする前に、references/output_contract.md を読んでください。ルーティングまたは移植性の境界を変更する前に、references/workflow_contract.md を読んでください。

コメント