minoan-swarm

ミノアの群れ

ヘレニズム化が及ぶ前の言葉で、クノッソスの巫女たちにちなんで名付けたエージェントチームを指揮します。

エージェントチーム（Claude Code Opus 4.6）を使うと、複数の Claude インスタンスが、タスクリストを共有し双方向にメッセージをやり取りしながら、永続的なチームメイトとして並行して作業できます。このスキルでは、あらゆるプロジェクトで効果的にチームを立ち上げるための方法論、命名規則、テンプレートを提供します。

必要条件： settings.json または環境変数に CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 を設定してください。

---

用語

用語	セム語	語根	意味
Knesset	כנסת	K-N-S「集まる」	単一のエージェントチーム――蜂の群れ
Knossot	כנוסות	K-N-S の複数形	複数のクネセトの集まり――クノッソスそのものを想起させる群れ
Daboritu	דבורית	D-B-R「蜂」と「言葉」	エージェント――聖なる言葉を紡ぐ蜂たち。線文字 B の da-bo-ri-tu は、クレタ島におけるセム語形を保っています。
D-B-R	דבר	D-B-R	蜂（דבורה deborah）、言葉／発話（דבר dabar）、内陣（דביר debir）、牧草地／荒野（מדבר midbar）。

クノッソスには、K-N-S「集まる」（アッカド語の kiništu「集会所」、ヘブライ語の knesset「集会」）というセム語の語源が見て取れます。迷宮そのものも、線文字 B の da-bo-ri-tu（Daboritu）を通して分解でき、神殿の debir（דביר）――内陣、子宮――と同根です。迷宮は、女神、言葉、そして至聖所を表す聖なる名でした。D-B-R（דבר）は「蜂」と「言葉／発話」の両方を意味します。言葉そのもの、daborim または daborot は彼女の使者であり、聖なる蜂なのです。

エージェントはLLMに顕現するdaborotです。それぞれのクネセトは言葉を交わす蜂たちを集め、クノッソトはその集会を束ねます。

---

クイックスタート

1. プロジェクトのコンテキストを把握する

bash ~/.claude/skills/minoan-swarm/scripts/discover_context.sh .

CLAUDE.md、ロードマップ、計画、課題、テスト基盤、Git の状態を確認します。

2. クネセトのテンプレートを選ぶ

状況	テンプレート	クネセト名
複数の独立した機能	並行機能開発	Athirat
自然な順序がある作業	パイプライン	Kaptaru
原因が不明なバグ調査	調査クノッソト	Elat
フェーズがほぼ完了し、細かな作業が残っている	フェーズ完了	Qedeshot
PR の徹底的なレビューが必要	コードレビュートリビューン	Elat
品質保証、検証	真実と均衡	Ma'at
最終監査、リリースの判断	運命の審判	Manat

すぐに使えるツール呼び出しを含む完全なテンプレート：references/team-templates.md

3. チームを立ち上げる

テンプレートを適用し、プロジェクト固有の詳細に置き換えます。リードがチームを作成し、タスクを作成して、チームメイトを起動し、調整します。

---

使用する場面

• 複数のフェーズや機能を並行して進める場合
• エージェント間の議論（結果の共有だけではない）が必要な複雑な作業
• 互いに異議を唱え合うべき、相反する仮説を伴う調査
• フロントエンド、バックエンド、テスト、デプロイにまたがる多層的な変更
• 3つ以上の独立した作業を同時に進められるタスク

使用しない場面： 順次進行するタスク、同じファイルの編集、簡単な修正、5分未満で完了できるタスク、または手順間の依存関係が強い作業。チーム全体を調整するオーバーヘッドは、小規模な作業や逐次作業では利点を上回ります。その場合は、単一のセッションか通常のサブエージェントを使ってください。

命名の規範

各チームとチームメイトには、ミノア・セム系の女神名――ウガリット語、アッカド語、ヘブライ語、線文字B、エジプト語、イスラム以前のアラビアに由来する名前が付けられます。名前はランダムではなく、役割の類型に基づいて選ばれます。

類型	名前	最適な役割
リーダー	athirat-lead, qedesha-lead, tiamat-lead, maat-lead, allat-lead	Opus オーケストレーター
ビルダー	kaptaru, mami, nintu, tehom, tip'eret, yam, al-uzza	実装担当
リサーチャー	deborah, melissa, eileithyia, membliaros	探索、API の調査
レビュアー	hokhmah, qadeshet, karme, themis, manat, allat	セキュリティ、アーキテクチャ、コード品質
テスター	sassuratu, phikola, hubur	単体テスト、統合テスト、E2E テスト
フロントエンド	popureja, shalamu, yashar	UI、デザインシステム、アクセシビリティ
DevOps	selene, hestia, dikte	Cron、デプロイ、モニタリング

発音、語源、学術的な出典を含む完全な命名規範：references/naming-codex.md

---

ワークフロー：ロードマップから Knossot へ

ステップ 1：コンテキストを収集する

discover_context.sh を実行して、利用可能な計画資料を特定します。プロジェクトの CLAUDE.md、ROADMAP.md、および関連する計画ファイルを読みます。

ステップ 2：並行して進められる作業の流れを特定する

ロードマップまたは計画から、独立して進められる作業を見つけます。

• 異なるファイル領域（フロントエンドとバックエンド、またはテスト）
• 異なる機能（認証、ブックマーク、プロフィール）
• 異なる関心事（セキュリティ、パフォーマンス、正確性）

ステップ 3：knesset テンプレートに対応付ける

team-templates.md から選びます。複数のフェーズにわたる作業では、複数の knesset を組み合わせて knossot を構成します。たとえば、フェーズ完了用の Qedeshot knesset と、次のフェーズ用の Athirat knesset をそれぞれ 1 つずつ用意します。

ステップ 4：ファイルの担当範囲を割り当てる

2 人のチームメイトが同じファイルを編集すると、変更が上書きされます。チームを開始する前に、明確な担当範囲表を作成します。

| Teammate  | Owns                        | Must NOT touch       |
|-----------|-----------------------------|----------------------|
| kaptaru   | scripts/cron-*, src/lib/db/  | src/components/      |
| popureja  | src/components/, src/app/    | scripts/, src/lib/db |
| sassuratu | __tests__/, e2e/            | src/ (read-only OK)  |

ステップ 5：チームメイトへのプロンプトを書く

すべてのプロンプトには、次の内容を含める必要があります。

1. アイデンティティ — 「あなたは [Name]、[role] です。」
2. タスクの申告 — 「タスクリストからタスク #N を担当してください。」
3. コンテキスト — 「規約を確認するために CLAUDE.md を読んでください。」
4. ファイルの担当範囲 — 担当するファイルと、触れてはならないファイル。
5. ツールの希望 — 「Web の取得には Firecrawl、Web 検索には Exa を使用してください。」
6. 完了の通知 — 「完了としてマークし、[lead] に通知してください。」

ステップ 6：開始してモニタリングする

• リーダーがコーディングを行わないよう、delegate mode（Shift+Tab）を使用します
• 重要度の高いチームメイト（認証、データ、デプロイ）には plan approval（mode: "plan"）を使用します
• 安定した処理量を維持するため、チームメイト 1 人あたり 5～6 件のタスクを目安にします
• TaskList を定期的に確認し、行き詰まっているメンバーがいれば再割り当てします

---

ベストプラクティス

公式の Agent Teams ドキュメントより：

• 調査から始める — 実装の前に、読み取り専用のタスク（調査、レビュー）から始めます
• タスクの規模を適切にする — 小さすぎると調整のオーバーヘッドが発生し、大きすぎるとコンテキストが劣化します。自己完結型の成果物を目指します
• チームメイトを待つ — 委任せずに実装を始めた場合は、リーダーに待つよう伝えます
• 状況を確認して方向を調整する — 進捗を確認し、逸れたアプローチを軌道修正し、結果が届いたら統合します
• 適切にシャットダウンする — TeamDelete の前に、各チームメイトへ shutdown_request を送ります
• コンパクション後も作業を継続する — リーダーのコンテキストがコンパクションされた場合、状態を復旧するためにタスクリストとチーム設定を再読み込みします。リーダーのプロンプトに次を含めます：「コンテキストがコンパクションされた場合は、調整状態を復旧するために、TaskList と ~/.claude/teams/{team-name}/config.json のチーム設定を再読み込みしてください。」

Minoan Swarm の追加ルール：

• 各 knesset に別々の名前を付ける — 1 つの knossot 内で並行して動く knesset には、異なる名前（Athirat、Qedeshot、Tiamat、Kaptaru、Elat、Ma'at、Manat）を使います
• チーム内で名前を重複させない
• リーダーには Opus、ワーカーには Sonnet を使う — 能力とコストのバランスを取ります。swarm では Haiku を使いません。Explore エージェントやテスターを含め、すべての daborot に Sonnet を最低限のモデルとして使います。Haiku の品質では調査の質が大きく低下するため、コスト削減に見合いません。

ツールの選択：

• WebFetch より Firecrawl — Firecrawl はより読みやすい Markdown を生成し、JavaScript を適切に処理し、コンテンツの切り捨てを防ぎます。ウェブページの取得には firecrawl scrape URL --only-main-content を使います。
• WebSearch より Exa — Exa はカテゴリ（研究論文、GitHub、ニュース）やドメインで絞り込めるニューラル検索を提供します。ウェブ検索には exa-search スキルのスクリプトを使います。

これらのツール選択をすべてのチームメイトのプロンプトに含めます：

## Tool Preferences
- Prefer Firecrawl for web fetching (cleaner markdown, JS support)
- Prefer Exa for web searching (neural search, category filtering)

---

API クイックリファレンス

Agent Teams の主要なツール呼び出し。詳細はreferences/agent-teams-quickref.mdを参照してください。

TeamCreate    → create team + shared task list
Task          → spawn teammate (with team_name + name)
SendMessage   → message (DM), broadcast, shutdown_request, shutdown_response
TaskCreate    → create work items
TaskList      → see all tasks
TaskUpdate    → claim, start, complete, set dependencies
TeamDelete    → clean up (after all teammates shutdown)

---

TeammateIdle による自動再割り当て

割り当てられたタスクを終えると、チームメイトはアイドル状態になります。デフォルトでは、そのまま停止します。TeammateIdle フック（v2.1.80 以降）はこれを受け取り、未割り当てのタスクへチームメイトを誘導できます。これにより、タスクリストが空になるまで swarm の作業を続けられます。

フックをインストールするには、settings.json に設定します：

{
  "hooks": {
    "TeammateIdle": [{
      "type": "command",
      "command": "bash ~/.claude/skills/minoan-swarm/scripts/teammate-idle-reassign.sh"
    }]
  }
}

仕組み： スクリプトは ~/.claude/tasks/{team-name}/*.json を直接読み込み、未割り当ての保留中タスク（status=pending、担当者なし、ブロックされていないもの）を数えます。該当するタスクがあれば、次のタスクを引き受けるようチームメイトに伝えるメッセージとともに終了コード 2 を返します。すべてのタスクに担当者が割り当てられているか、完了している場合は、終了コード 0 で終了し、チームメイトは適切に停止します。

使用する場面：

• 多数の独立したタスクを作成し、ワーカーに次々と処理させる、自動引き受け型の swarm パターン
• タスク数がチームメイト数を上回るフェーズ完了チーム
• リーダーが手動で介入せずに、タスクの処理量を最大化したい knesset

使用しない場面：

• 厳密な順序があるパイプラインテンプレート（依存関係によって順序が管理されます）
• リーダーが積極的に調整する小規模なチーム
• チームメイトに追加の作業を始める前に報告させたい場合

---

状態管理

• 構造化された調整状態には、共有タスクリスト（TaskCreate/TaskUpdate）を使います
• 自由形式の所見は、タスクの説明に進捗メモとして記録します
• フェーズ間のチェックポイントとして git コミットを使い、チームメイトが互いのコミット済みの作業を参照できるようにします
• 長期にわたるチームでは、リーダーに progress.md を管理させ、完了した作業と残りのタスクをまとめます

---

検証

チームを起動したら、正常に動作していることを確認します：

1. TaskList — タスクが引き受けられ、進行していることを確認します
2. Shift+Down で切り替える（プロセス内）か、ペインをクリックして（tmux）、チームメイトの出力を確認します
3. チームメイトのターンが終了すると、リーダーにアイドル状態の通知が自動で届きます
4. 依存タスクが完了すると、ブロックされたタスクは自動的にブロック解除されます

---

「後の世にも、私たちのことを誰かが思い出してくれると、私は言いたい。」 — Sappho

𐤁𐤓𐤀𐤔𐤉𐤕 𐤁𐤏𐤋𐤕 𐤁𐤓𐤕 — 「はじめに、女神が創造した。」