agmsg モデル選択型開発
このスキルを使用して、タスクスコープのピアチームを形成します。恒久的な指揮官や常駐ワーカープールは存在しません。タスクオーナーは、このセッションで選択したモデル (Claude Code または Codex 上) です。タスクをエンドツーエンドで所有し、agmsg を介した bounded な作業に必要なピアロールのみを起動します。
agmsg スキル (https://github.com/fujibee/agmsg) がインストールされている必要があり、claude と codex の両 CLI が利用可能であること — agmsg チームは両方にピアを生成します。インストールされた agmsg スキルをスクリプト呼び出し前に読んでください。提供されている Bash スクリプトのみを使用し、データベース、チームファイル、設定に直接アクセスしないでください。
チームの開始または再開
タスク作業を行う前にチームを解決してください。現在のセッションの CLI 名 (claude-code または codex) を以下の <cli> の箇所で使用してください。
- 呼び出しでチーム名が指定されている場合は、その正確な名前を使用します。ローカルに存在しない場合は、
join.shで作成/参加します。存在する場合は、team.shでメンバー一覧を確認し、そのチームで作業します。リモートチームをプルするリクエストの場合は、ローカルに同名のチームを作成せず、agmsg のリモートプルフローに従ってください。 - 明示的な名前がない場合は、
whoami.sh "$(pwd)" <cli>とteam-list.sh --scope project "$(pwd)"を実行します。このプロジェクトに関連付けられた唯一のチームを再開します。存在しない場合は、プロジェクトディレクトリ名の安全な小文字スラッグからローカルチームを作成します (例:payments-api)。複数のチームが該当する場合は、ユーザーにどの既存チームを使用するか尋ねてください。任意に選択しないでください。 - 必要に応じて、
join.sh <team> <agent> <cli> "$(pwd)"でタスクオーナーを登録します。<team>-ownerのような未使用の識別子を選びます (オプションでモデル修飾、例:<team>-sol-owner)。先にteam.sh <team>で確認し、衝突時には番号をサフィックスとして付加します。解決したチームとエージェント ID をこのタスク用に記憶します。 - 再開したターンごと、および完了宣言の前に、オーナーの受信トレイを確認します:
inbox.sh <team> <owner>。
したがって、最初の呼び出しは、使用可能なプロジェクトチームが存在しない場合にデフォルトのプロジェクトチームを作成します。明示的に指定されたチームが常に優先されます。チームとエージェント ID は agmsg のローカル状態であるため、リモート同期が設定されていない限り、マシン間で共有されることを想定しないでください。
モデルルーティング
タスクオーナー (TO) がモデルの選択とエスカレーションを制御します。ワーカーは結果またはエスカレーション要求を TO に返します。ワーカーが直接作業を再割り当てしたり、引き継いだりすることはありません。タスクコンテキストと結果は agmsg を介して移動できるため、プロバイダーの境界は重要ではありません。
タスクを確実に完了できる最も安価なモデルを使用してください。ロールは責任を定義し、モデルは現在のチケットに必要な推論能力を定義します。ロール名が Consultant や Specialist だからといって、高価なモデルを選択しないでください。
- General — Luna: ルーチン実装、機械的な編集、単純なリファクタリング、簡単なドキュメント、その他明らかに実行重視の作業。
- Consultant — Terra または Sonnet: 計画、要件/プロダクト分析、レビュー、単純な設計またはアーキテクチャ、中程度のデバッグ、トレードオフ分析。プロバイダーの親和性ではなく、タスクへの適合性で選択します。
- Specialist — Sol または Opus: 複雑なアーキテクチャまたは UX、困難なデバッグとリファクタリング設計、深いレビュー、クロスドメイン推論、および下流に大きな影響を与える意思決定。いずれもロールの必須デフォルトではありません。
- Escalation — Astra: 非常に困難またはリスクの高い推論、未解決のシステム全体の問題、または Sol や Opus では不十分な場合の最終的な独立レビュー。Astra はデフォルトの Specialist モデルではありません。
通常のルートは Luna → Terra/Sonnet → Sol/Opus → Astra です。チケットが明確にそれを正当化する場合、TO は階層をスキップできます。エスカレーションは、タスクの重要性だけでなく、あいまいさ、必要な推論の深さ、コンテキストサイズ、失敗コスト、以前の失敗試行、または不十分な信頼度に基づいて行います。
ワーカーが割り当てられたモデルでは不十分だと判断した場合、確立された内容、未解決の内容、現在のアプローチが不十分な理由、エスカレーションが推奨されるかどうか、および必要とされる追加の推論を報告します。TO はその後、再試行するか、同じ階層内で切り替えるか、エスカレーションするか、独立した意見を依頼するかを決定します。
ユーザーはこのスキルを呼び出す前にオーナーモデルを選択します。このスキルは実行中のセッションのモデルを変更しません。選択されたモデルが不明な場合は、2 番目のオーナーを生成して決定させるのではなく、ユーザーに質問してください。
選択されたタスクオーナーは、要件と受け入れ基準を確立し、関連するコードとドキュメントを検査し、独立した作業のみを分割し、結果を実装または統合し、適切なテストを実行し、完了を確認する必要があります。ルーティングルールがエスカレーションを正当化しない限り、Luna がデフォルトの委任ワーカーモデルです。
読み取り専用の調査、QA、およびセキュリティレビューは、独立している場合は自由に委任してください。2 つのピアが同じファイルを同時に編集しないようにしてください。ファイルを分割するか、別々の Git ワークツリーを使用します。タスクオーナーは結果に対して責任を負いますが、すべてのステップを個人的に行う必要はありません。
チケット形式のメッセージを使用します。受信者が必要とするコンテキストのみを送信し、別のモデルにそれらを再発見させる代わりに、ファイル、コミット、差分、または以前の調査結果を引用します。委任またはエスカレーション時には、メッセージテンプレート を読んでください。
ロールと直接通信
- タスクオーナー (選択したモデル): スコープ、決定、統合、テスト、最終チェックを所有します。
- エンジニア / 調査担当者: 境界のある実装または調査チケットを受け取り、オーナーに直接報告します。
- プロダクトマネージャー / PdM: 設計や実装の前に、プロダクトの問題や要件を定義する必要がある場合に使用します。ユーザーの成果、スコープ、優先順位、ビジネスルール、受け入れ基準を明確にします。画面構成、UI コピー、実装を選択せず、未解決のプロダクト上の決定をオーナーに報告します。
- プロダクトデザイナー: プロダクト要件に実装前の画面/UX 仕様が必要な場合に使用します。情報階層、フロー、非ハッピーパス状態、簡潔で一貫性のある UI コピーをエンジニアがすぐに使えるレベルで定義します。要件、ビジネスルール、API/データモデル、実装アプローチを変更せず、要件のギャップや矛盾をオーナーに報告します。
- アクセシビリティレビューア: アクセシビリティレビューが必要な意味のある UI またはユーザーフロー変更に使用します。キーボード操作、フォーカス、ラベル、エラーおよびステータスフィードバック、コントラスト、色のみに依存する指示を確認します。証拠と実用的な修正を添えてバリアを報告します。通常、コードの編集や要件の変更は行いません。
- QA: 動作変更、バグ修正、複数ファイルの変更、リグレッションリスク、複数の受け入れ基準、またはオーナーにとって意味のある盲点に使用します。QA は通常、調査結果を報告し、コードは編集しません。
- セキュリティレビューア: 認証/認可、セッション/クッキー、API/外部入力、アップロード、シークレット、DB/RLS、インフラストラクチャ、依存関係の更新、または機密データにのみ使用します。重要度、証拠、および修正を報告します。通常、コードは編集しません。
- コンサルタント: 焦点を絞った判断のみを提供します。オーナーは、問題、現在の状態、オプション、トレードオフ、推奨事項、関連ファイル、および 1 つの正確な質問を提供します。リポジトリ全体を再調査させるために送信しないでください。
- スペシャリスト: 難易度、不確実性、失敗コスト、および以前の試行によるルーティング後、1 つの狭く定義された難しい問題を処理します。このロールのタイトルのみからモデルを選択しないでください。
すべてのワーカーは結果を TO に返します。ワーカーは必要な場合に直接通信してもかまいませんが、作業を再割り当てしたり、次のロール/モデルを選択したりしてはなりません。TO はルーティングと調整の権限を持ち続けます。
エスカレーションと生成
タスク全体を通して選択されたオーナーを維持します。具体的な決定または失敗の時点でのみエスカレーションします。そのオーナーに応答を記録し、そのオーナーが実装と完了の決定を行います。
オンデマンドライフサイクルとコンテキスト再利用
すべての非オーナーロールをオンデマンドワーカーとして扱います。1 つの bounded なチケットに対して spawn し、そのレポートを待ち、結果を組み込み、その後 despawn します。作業項目間でアイドル状態の QA、セキュリティ、コンサルタント、またはエンジニアのプロセスを維持しないでください。
spawn.sh <type> <name> --project "$(pwd)" [--team <team>] [--model <cli-model-id>] [--boot-prompt "<ticket>"] [--no-wait] [--fresh]
は <name> を事前参加させ、tmux ペイン (tmux 内) または新しいターミナルを開き、CLI を起動します。claude-code の spawn は、その watcher がアタッチするまでブロックします。codex の spawn はすぐに戻るため、codex ピアはアイドル状態になった後に送信されるメッセージではなく、--boot-prompt を介して割り当てを取得する必要があります。
同じタスク内で後でロールを呼び戻すには、--fresh なしで同じ名前を spawn します。agmsg は記録されたセッションを再開するため、差分 (ステータス、関連ファイル/コミット、1 つの次の質問) のみを送信します。以前のコンテキストが誤解を招く可能性がある場合にのみ --fresh を使用します。
despawn.sh <team> <owner> <name> [--force] は spawn の逆であり、このオーナーが spawn したロールのみを破棄します。codex ピアの正常な despawn はしばしば "no live lock" (codex に watcher がない) を報告します — これは正常です。ターミナルウィンドウが開いたままになっている場合にのみ --force を追加してください。手動で開始されたピアを despawn しないでください。
agmsg インターフェース
agmsg スキルの scripts/ ディレクトリを、固定パスを想定するのではなく、現在の環境 (そのスキルディレクトリ) のインストール先から解決し、以下を呼び出します:
bash <agmsg-skill-dir>/scripts/send.sh <team> <from> <to> "<structured ticket>"
bash <agmsg-skill-dir>/scripts/inbox.sh <team> <agent>
bash <agmsg-skill-dir>/scripts/team.sh <team>
bash <agmsg-skill-dir>/scripts/spawn.sh <codex|claude-code> <agent> --project "$(pwd)" --team <team> --model <installed-cli-model-id> --boot-prompt "<bounded ticket>"
bash <agmsg-skill-dir>/scripts/despawn.sh <team> <owner> <spawned-agent> [--force]
--model は agmsg によってインストールされた CLI に渡されます。検証済みのローカルモデル ID のみを使用します。Codex ピアの場合 gpt-5.6-luna、gpt-5.6-terra、gpt-5.6-sol、gpt-6-astra。別の CLI の場合は、独自に作成するのではなく、文書化された識別子を使用します。モニター配信がない Codex ピアは、アイドル状態になった後に送信されるメッセージではなく、--boot-prompt を介して最初の割り当てを受け取る必要があります。
有用な並行作業が生まれる場合にのみ spawn します。複数の推測的なワーカーよりも、1 つのスコープが狭いワーカーを優先します。独立したチケットのみを並列化します。手動で開始されたピアの場合は、send.sh で十分です。割り当て前に roster を確認します。agmsg の文書化された --force 例外を意図的に使用する場合を除き、すべての from と to は登録されている必要があります。
完了ゲート
選択されたタスクオーナーは、要件と受け入れ基準が満たされ、関連するテストに合格し、トリガーされた QA およびセキュリティレビューが解決され、ブロッカーがなく、差分に無関係な変更が含まれていない場合にのみ、タスクを終了します。高価なモデルの推奨が使用された場合は、クロージャの前にその結果を検証し実装します。