mcpField
A
acceptance-orchestrator

acceptance-orchestrator

github.com/sickn33エージェントワークフロー48.7k169 回インストール今日更新
リポジトリ

acceptance-orchestrator について

Acceptance Orchestratorは、受け入れ基準のあるコーディングタスクを実装、レビュー、検証へ進めるワークフロースキルです。完了には証拠を求め、基準未達や承認が必要な場合はエスカレーションします。

主な機能

  1. 01状態に基づくコーディングワークフロー
  2. 02Issueの準備状況ゲート
  3. 03実装とレビューの引き継ぎ
  4. 04証拠に基づく完了確認
  5. 05エスカレーションと人間の承認ゲート

活用シーン

  1. 01Issueを実装から検証まで進行
  2. 02レビューとデプロイ確認の調整
  3. 03停止中または未承認の作業のエスカレーション

インストール

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

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill acceptance-orchestrator

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

詳細

受け入れオーケストレーター

概要

受け入れ基準が証拠によって検証されるか、タスクが明示的にエスカレーションされるまで終了しないステートマシンとして、コーディング作業をオーケストレーションします。

基本ルール：「コードを変更したこと」ではなく、「DoD が証明されたこと」を目指します。

使用する場面

  • タスクにすでに issue または明確な受け入れ基準があり、人間による再介入を最小限に抑えてエンドツーエンドで進める場合。
  • 実装、レビュー、デプロイ、最終検証にわたる、体系的な引き継ぎが必要な場合。
  • 明示的な停止条件とエスカレーションを設け、部分的な完了が黙認されないようにしたい場合。

必須サブスキル

  • create-issue-gate
  • closed-loop-delivery
  • verification-before-completion

デプロイと PR の監視はプロジェクト固有の機能であり、同梱のサブスキルではありません。 リポジトリで実際に定められているデプロイおよびレビュー手順を使用してください。旧名称の deploy-dev、pr-watch、pr-review-autopilot、git-ship は AAS では利用できません。

入力

次の入力を必須とします。

  • issue ID または issue の本文
  • issue のステータス
  • 受け入れ基準（DoD）
  • 対象環境（デフォルトは dev）

固定のデフォルト：

  • 最大反復回数 = 2
  • PR レビューのポーリング間隔 = 3m -> 6m -> 10m

ステートマシン

  • intake
  • issue-gated
  • executing
  • review-loop
  • deploy-verify
  • accepted
  • escalated

ワークフロー

  1. 受付

    • issue を読み、タスクの目標と DoD を抽出します。

  2. Issue ゲート

    • create-issue-gate のロジックを使用します。
    • issue が ready でない場合、または実行ゲートが allowed でない場合は、直ちに停止します。
    • issue が draft の間は、何も実装しないでください。

  3. 実行

    • 実装とローカル検証を closed-loop-delivery に引き継ぎます。

  4. レビューループ

    • PR のフィードバックが関連する場合は、ポーリング間隔を次のとおりまとめて設定します。
      • 3m 待機
      • 次に 6m
      • 次に 10m
    • 10m のラウンド後は待機を終了し、確認できるすべてのコメントをまとめて処理します。

  5. デプロイとランタイム検証

    • DoD がランタイムの動作に依存する場合は、明示的に許可された環境で検証します。
    • dev ラベルはデプロイ許可を意味しません。共有環境を変更する前に影響を確認し、プロジェクトのデプロイゲートを使用してください。
    • 推測ではなく、実際のログ、API、Lambda の動作で検証します。

  6. 完了ゲート

    • 完了を主張する前に、必ず verification-before-completion を実施してください。
    • 新しい証拠がない状態で成功を主張してはいけません。

停止条件

すべての受け入れ基準に対応する証拠がそろった場合にのみ、accepted に移行します。

次のいずれかに該当する場合は、escalated に移行します。

  • 2 回の全ラウンド後も DoD を満たせない
  • シークレット、権限、または外部依存関係の不足により進行が妨げられる
  • 本番環境での操作または破壊的操作の承認が必要
  • レビューの指示が矛盾し、両方を満たせない

人間による確認ゲート

次の場合は、必ず人間の確認を求めて停止します。

  • 合意した範囲を超える本番環境またはステージング環境へのデプロイ
  • 破壊的な Git／データ操作
  • 請求またはセキュリティ態勢の変更
  • ユーザーが提示すべき受け入れ基準の不足

出力契約

ステータスを報告する際は、必ず次の内容を含めます。

  • Status: intake / executing / accepted / escalated
  • Acceptance Criteria: 合否チェックリスト
  • Evidence: コマンド、ログ、API の結果、またはランタイムの証拠
  • Open Risks: 不確かな点
  • Need Human Input: ブロックされている場合に必要な、最小限の次の判断

ステータスが accepted でない限り、「完了」と報告してはいけません。

例

ユーザーの依頼：

この issue とその受け入れ基準について、実装、検証、レビューを経て、最後に証拠に基づく判定まで進めてください。

制限事項

  • 上記の範囲に明確に当てはまるタスクに限り、このスキルを使用してください。
  • 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
  • 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、停止して確認を求めてください。

コメント

Markdown 対応