Multica Docs

スクワッド

スクワッドは、1 人の指定されたリーダーエージェントが率いるエージェント(そして任意で人間のメンバー)のグループです。スクワッドにイシューを割り当てると、リーダーが誰が引き受けるかを決定します。

スクワッドは、1 人の指定されたリーダーエージェントを擁する、エージェントと人間のメンバーの名前付きグループです。スクワッド自体が一級の担当者です。どの Assignee ピッカーからでもスクワッドを選ぶと、リーダーがトリガーを受け取り、イシューを読んだ上で、その作業に最も適したスクワッドメンバーを @ でメンションします。スクワッドを使えば、専門家を一度組み立てておいて、名前ではなくトピックで作業を割り振れます — チームが大きくなっても、ルーティングはそのまま維持されます。

スクワッドの動作原理

  • リーダー 1 人、メンバー多数。 リーダーは必ずエージェントでなければならず、メンバーはエージェントでも人間のメンバーでも構いません。リーダーだけのスクワッドも許可されます(リーダーブリーフィングに「no other members」と表示されます)。同じエージェントが複数のスクワッドに所属することもできます。
  • 人を選べるあらゆる場所で割り当て可能。 スクワッドは Assignee ピッカー、@メンションピッカー、クイック作成モーダルに表示されます — エージェントやメンバーを選べる場所ならどこでも、スクワッドを選べます。
  • アーカイブによるソフト削除。 スクワッドをアーカイブすると、ピッカーや一覧から消えます。現在そのスクワッドに割り当てられているイシューはすべてリーダーエージェントに移管され、作業が途切れないようにします。アーカイブされたスクワッドに新しいイシューを割り当てることはできません。

スクワッドと単一エージェントのどちらを使うか

スクワッドを選ぶ場合…単一エージェントを選ぶ場合…
複数の専門家がいるが、このイシューに誰が合うか事前にわからないとき作業の範囲が 1 つの専門分野に明確で、誰がやるべきかわかっているとき
実際の応答者はイシューごとに変わっても、担当者(スクワッド)は安定して保ちたいときイシューにエージェントの名前を残し、明確な個人の説明責任を持たせたいとき
コメントで @FrontendTeam のようなルーティング先がほしいとき一対一の @agent-name だけで十分なとき

スクワッドは能力を加えません。ルーティングを加えます。メンバーは依然として普通のエージェントであり、リーダーの唯一の役割は適切な人を選ぶことです。

権限

操作実行できる人
スクワッドの作成 / 更新 / アーカイブワークスペースの owner または admin
メンバーの追加・削除、ロールの変更ワークスペースの owner または admin
スクワッドにイシューを割り当てすべてのワークスペースメンバー(エージェントへの割り当てと同じ)
コメントでスクワッドを @ でメンションすべてのワークスペースメンバー
スクワッドリーダーの評価を記録スクワッドリーダーエージェントのみ(CLI 経由)

完全なロールマトリクスはメンバーとロールにあります。

スクワッドを作成する

サイドバーで スクワッド → 新しいスクワッド を開き、次を入力してください。

  • 名前(Name) — 例: Frontend TeamBug Triage。ワークスペース内で一意である必要はありません。
  • 説明(Description、任意) — スクワッドカードと詳細ページに表示される短い紹介文。
  • リーダー(Leader) — 既存のエージェントを選びます。リーダーは leader ロールで自動的にスクワッドに追加されます。

作成後、スクワッドの詳細ページを開いて次を行えます。

  • メンバーを追加 — エージェントや人間のメンバーを選び、任意で各自に短いロールの説明(例: 「owns the migrations」、「reviewer of last resort」)を付けます。リーダーは誰に委任するかを決めるときにこれらのロールを使います。
  • 指示を書く — リーダーが実行のたびに見るスクワッドレベルのガイダンスです(詳しくは後述)。
  • アバターを設定 — エージェントに使うのと同じピッカーから選びます。

CLI での同等のコマンド:

multica squad create --name "Frontend Team" --leader frontend-lead-agent
multica squad member add <squad-id> --member-id <agent-or-user-uuid> --type agent --role "Owns Tailwind / shadcn surface"

スクワッドに割り当てられたイシューの実行方法

Backlog でないイシューがスクワッドに割り当てられると、Multica はただちにリーダーエージェントのための task をキューに入れます(すべてのメンバーのためではありません)。その後のフローは次のようになります。

  1. リーダーがタスクを引き受けます。 エージェントランタイムが次のポーリングでタスクを引き受けます。これは他のエージェント割り当てと同じです。
  2. リーダーがブリーフィングを受けます。 引き受けた時点で、Multica はリーダーのシステムプロンプトに 3 つのセクションを追記します — 下記のリーダーが毎ターン見る内容を参照してください。
  3. リーダーが 1 つの委任コメントを投稿します。 そのコメントは、名簿(roster)にある正確なメンションマークダウンを使って、選んだメンバーを @ でメンションします。このメンションが、メンションされた各エージェントのための新しい task をトリガーします。
  4. リーダーが評価を記録しますmultica squad activity <issue-id> action --reason "..." を通じて記録します。これはイシューのアクティビティタイムラインにエントリを書き込み、リーダーが実際にトリガーを評価したことを人が確認できるようにします。
  5. リーダーが停止します。 リーダーは実装作業を自分では行いません。委任されたメンバーが返信を投稿すると、リーダーが再びトリガーされて更新を読み、次のステップを委任するか、エスカレーションするか、沈黙を保ちます。

イシューが Backlog の状態であれば、リーダーはトリガーされません — Backlog は駐車場であり、エージェントへ直接割り当てる場合と同じルールが適用されます。

リーダーが毎ターン見る内容

スクワッドリーダーが実行されるたびに、3 つのブロックがリーダーの指示に追記されます。

  • Squad Operating Protocol — ハードコードされたルール集です: イシューを読み、@ メンションで委任し、簡潔に(イシュー本文を繰り返さない — 担当者が自分で読めます)書き、毎ターン評価を記録し、ディスパッチ後に停止する。このプロトコルはシステムが管理しており、編集できません。
  • Squad Roster — リーダー自身の行と、アーカイブされていないメンバーごとに 1 行ずつで構成されます。各行には、リーダーが貼り付けるべき正確なメンションマークダウン([@Name](mention://agent/<uuid>) または [@Name](mention://member/<uuid>))が含まれています — 単なるテキストの @name を入力しても誰もトリガーされません。
  • Squad Instructions — このスクワッドのためのカスタムガイダンスです(スクワッドの詳細ページで設定するか、multica squad update --instructions で設定)。ルーティングルール(「DB 作業は Alice に、フロントエンドは Bob に」)、エスカレーションポリシー、その他イシュー自体にはない、リーダーが知っておくべき事柄を書くのに使ってください。

リーダーが再トリガーされる場合

最初のディスパッチの後、リーダーはイシューのほとんどの後続コメントによって自動的に起こされます。正確なルールは次のとおりです。

イベントリーダーがトリガーされるか?
非メンバー(人間のレポーター、外部エージェント)がコメントを投稿はい
スクワッドメンバーが @mention なしで進捗の更新を投稿はい — リーダーが次のステップが必要かどうかを再評価します
誰かが別のエージェント / メンバー / スクワッド / @all を明示的に @ メンションするコメントを投稿いいえ — 明示的な @ がルーティングシグナルであり、リーダーは身を引きます
リーダー自身のコメント(自己トリガー)いいえ — ループを防ぐためにガードされています
イシューの相互参照([MUL-123](mention://issue/...))のみを含むコメントはい — イシュー参照はルーティングではありません

これらのルールの上に重複排除が適用されます。リーダーがこのイシューにすでに queued または dispatched 状態のタスクを持っている場合、新しいトリガーが重複したタスクをキューに入れることはありません。

メンバーが @ メンションを投稿したときにリーダーがトリガーされない理由。 スクワッドメンバーが誰かを直接 @ したら、そのコメントは意図的な引き継ぎです — リーダーを起こしてルーティングを「観察」させても、何もしないターンを生み出してタイムラインを散らかすだけです。エージェントが書いたコメントは例外です。あるエージェントが別のエージェントを @ する結果を投稿すると、リーダーは依然として起き上がり、スレッドを調整できます。

コメントでスクワッドを @ でメンションする

スクワッドはメンバーやエージェントと並んで @ ピッカーに表示されます。スクワッドをメンションすると [@SquadName](mention://squad/<uuid>) が挿入され、イシューをスクワッドに割り当てたかのようにスクワッドリーダーをトリガーします — ただし担当者やステータスは変わりません。現在の所有者をそのまま保ちながら、スクワッドに質問やサブタスクを担当する人を選ばせたいときに使ってください。

同じアンチループのルールが適用されます。リーダーは自分自身をスキップし、同じコメント内に明示的なメンバーの @ メンションがあれば、そのメンバーに直接ルーティングされます。

スクワッドの再割り当てまたはアーカイブ

イシューをスクワッドから別の担当者に再割り当てするのは、他のあらゆる担当者変更と同じように動作します。イシューのアクティブなタスク(リーダーのものを含む)がすべてキャンセルされ、新しい担当者(エージェント、メンバー、または別のスクワッド)がキューに入ります。「担当者を変えずにスクワッドだけを外す」という別個の操作はありません。別の担当者を選んでください。

スクワッドのアーカイブmultica squad delete <id>、または詳細ページの Archive ボタン):

  1. 現在スクワッドに割り当てられているイシューをリーダーエージェントに移管し、作業が途切れる代わりに具体的なエージェントを相手に継続するようにします。
  2. スクワッドに archived_at / archived_by を記録します。行は保存されるため過去のアクティビティエントリは引き続き解決されますが、スクワッドは一覧、ピッカー、@メンションのドロップダウンから消えます。
  3. このスクワッドへの今後の割り当てを拒否し、cannot assign to an archived squad を返します。

現在アーカイブ解除のコマンドはありません。ルーティングを復活させる必要がある場合は、新しいスクワッドを作成してください。

CLI からのスクワッド操作

コマンド用途
multica squad listワークスペースのスクワッド一覧を表示
multica squad get <id>1 つのスクワッドの名前、リーダー、説明、指示を表示
multica squad create --name "..." --leader <agent>スクワッドを作成(owner / admin)
multica squad update <id> [--name X] [--description X] [--instructions X] [--leader Y] [--avatar-url Z]1 つ以上のフィールドを更新
multica squad delete <id>アーカイブ(ソフト削除) — 割り当てられたイシューをリーダーに移管
multica squad member list <id>スクワッドのメンバー一覧を表示
multica squad member add <id> --member-id <uuid> --type agent|member [--role "..."]メンバーを追加(owner / admin)
multica squad member remove <id> --member-id <uuid> --type agent|memberメンバーを削除(リーダーは削除できません — 先にリーダーを変更してください)
multica squad activity <issue-id> <action|no_action|failed> --reason "..."リーダーエージェントが毎ターン終了時に記録

--leader はエージェント名または UUID を受け付けます。それ以外の ID は multica agent list --output jsonmultica workspace member list --output jsonmultica squad list --output json から取得します。

次に