mcpField
A
amq-spec

amq-spec

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

amq-spec について

amq-specは、2つのエージェントによる設計仕様の策定を調整するスキルです。独立調査、議論、草案、レビュー、提示を順に進め、ユーザーの承認後に実装します。

主な機能

  1. 016段階の仕様策定
  2. 02独立した並行調査
  3. 03AMQスレッドとフェーズラベル
  4. 04実装前のユーザー承認

活用シーン

  1. 01パートナーエージェントとの設計案作成
  2. 02共同仕様のレビューと修正
  3. 03人の承認前の実装開始を防止

インストール

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

$npx skills add https://github.com/avivsinai/agent-message-queue --skill amq-spec

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

同梱ファイルreferences/spec-workflow.md

詳細

AMQ 協調仕様

2 つのエージェントが設計上の課題をそれぞれ独立して調査し、話し合って 1 つの計画にまとめます。実装に進む前に、ユーザーが計画を承認します。

フェーズは次の順に進みます。 Research -> Discuss -> Draft -> Review -> Present -> Execute

各フェーズのコマンドと、調査および計画のテンプレートは 仕様ワークフローを参照してください。

入力の解析

ユーザーのプロンプトから、次の情報を抽出します。

  • topic：短い kebab-case の仕様名（例：auth-token-rotation）
  • partner：パートナーエージェントのハンドル（デフォルト：codex）
  • problem：設計上の課題に関する完全な説明

topic または problem が不明確な場合は、確認を求めてください。

事前確認

  1. AMQ が利用可能であることを確認します：which amq
  2. AMQ のルートを検出できること（.amqrc、AMQ 環境変数、またはデフォルトの .agent-mail レイアウト）を確認します。検出できない場合は、次を実行します：amq coop init
  3. スレッド名を spec/<topic> にします。

開始

まずパートナーに課題を送り、その後、自分の調査を始めます。その後、両エージェントが並行して調査します。ユーザーの課題は原文のまま送信します。自分の分析は調査メッセージに含め、パートナーに先入観を与えないようにします。

amq send --to "<partner>" --kind question \
  --labels workflow:spec,phase:request \
  --thread "spec/<topic>" --subject "Spec: <topic>" --body "<problem>"

ラベル

すべての仕様メッセージでは、通常の AMQ 種別に加えて、spec/<topic> スレッドに次のラベルを付けます。

フェーズ種別ラベル
課題の提示questionworkflow:spec,phase:request
調査結果brainstormworkflow:spec,phase:research
議論brainstormworkflow:spec,phase:discuss
計画の草案review_requestworkflow:spec,phase:draft
計画へのフィードバックreview_responseworkflow:spec,phase:review
最終決定decisionworkflow:spec,phase:decision
進捗／予定statusworkflow:spec

仕様メッセージを受信したとき

ラベル対応
phase:requestまず独自に調査し、その後、調査結果を brainstorm + phase:research として送信します。
phase:researchこのスレッドに自分の調査結果をまだ送信していない場合は、パートナーの調査結果を読む前に調査し、送信します。その後、スレッドを読んで、brainstorm + phase:discuss として議論を始めます。
phase:discuss分析を返信し、合意に至るまで続けます。
phase:draft計画を確認し、review_response + phase:review としてフィードバックを送信します。実装はしません。
phase:review必要に応じて計画を修正するか、合意を確認します。
phase:decision停止します。承認ゲートを参照し、実装はしません。

承認ゲート

phase:decision メッセージはエージェント間の合意を記録するものであり、ユーザーの承認ではありません。開始者は最終計画をチャットでユーザーに提示し、オペレーターゲートに従って、gate/<topic> スレッドで人間のハンドル（慣例上は user）に承認を求めます。実装を開始できるのは、人間がそのスレッドで承認した後のみです。また、パートナーが作業を開始できるのは、その後、開始者が作業を割り当てた場合のみです。

ルール

  • 既存の wake を待ちます。 注入機能のある wake が有効な場合は、独立した作業を完了してから譲り、ドアベルで amq drain --include-body を実行します。amq watch、amq monitor、またはポーリングループを開始しないでください。この機能があるか不明な場合は、amq wake check --me <handle> --json を確認します。注入機能のある wake がない場合に限り、期限付きの watch を代替手段として使用できます。
  • 調査の前に送信し、パートナーの調査結果を読む前に自分の調査結果を送信します。 独立した調査によって、2 人目のエージェントが貢献できます。
  • フェーズを飛ばしてはいけません。 誤解が明らかになるのは議論の段階です。
  • spec/<topic> スレッドとラベルを維持します。 上記の受信者テーブルはそれらに依存しています。
  • 調査中はツールへのアクセスを維持します。 ツールを使えなくする計画モードには入らないでください。

コメント

Markdown 対応