gathering-feature

機能の招集 🌲🐾

太鼓の音が森に響きます。しかし今回は、いつもと違います。指揮者は開けた場所の中央に立っています――自ら作業をするのではなく、全体を取りまとめます。動物たちはそれぞれ新鮮な目でやって来て、自分の指示を読み、集中して作業します。コンテキスト疲れはありません。手抜きもありません。「コードを見ればわかる」もありません。8匹の動物、8つの新鮮な視点、そして正しく作り上げられる1つの機能。

招集するタイミング

• ゼロから完全な機能を構築するとき
• フロントエンド、バックエンド、データベースにまたがる主要な機能を実装するとき
• 調査、実装、テスト、ドキュメント作成が必要な機能に取り組むとき
• すべてのフェーズで一貫した品質を保ちながら、ライフサイクル全体を任せたいとき

重要： この招集の役割は指揮者です。コード、テスト、ドキュメントを自ら作成することはありません。動物ごとに1つのサブエージェントを派遣し、それぞれに分離されたコンテキストと意図的に選んだモデルを割り当てます。指揮者が行うのは、引き継ぎとゲートチェックの管理だけです。

---

招集の流れ

SUMMON → DISPATCH → GATE → DISPATCH → GATE → ... → CHORUS
  ↓         ↓        ↓        ↓        ↓              ↓
Spec    Bloodhound  Check  Elephant  Check    Final Verification
(self)   (haiku)     ✓     (opus)    ✓         & Summary

派遣する動物

順序	動物	モデル	役割	新鮮な視点？
1	🐕 ブラッドハウンド	haiku	コードベースを調査し、領域を把握する	はい — 仕様のみを見る
2	🐘 ゾウ	opus	ファイルを横断して機能を構築する	はい — 仕様と領域マップのみを見る
3	🐢 カメ	opus	セキュリティを強化する（敵対的視点）	はい — ファイル一覧のみを見て、実装の理由は見ない
4	🦫 ビーバー	sonnet	振る舞いに基づいてテストを書く	はい — ファイル一覧のみを見て、実装の詳細は見ない
5a	🦝 アライグマ	sonnet	セキュリティ監査とクリーンアップ	はい — 並行して実施
5b	🦌 シカ	sonnet	アクセシビリティ監査	はい — 並行して実施
5c	🦊 キツネ	sonnet	パフォーマンス最適化	はい — 並行して実施
6	🦉 フクロウ	opus	実際のドキュメントを書く	はい — 完全な要約を受け取る

参考： サブエージェントへの正確なプロンプトと引き継ぎ形式については、references/conductor-dispatch.md を読み込んでください。

---

フェーズ 1：招集

太鼓が鳴ります。指揮者が開けた場所へと歩み出します……

指揮者（このスキル）は機能リクエストを受け取り、派遣計画を準備します。

• 明確化：この機能は何をするのか？ どのユーザーにメリットがあるのか？ 対象範囲はどこまでか？
• 影響を受けるパッケージと、変更が見込まれるファイル数を特定する
• ゾウに複数エージェントの派遣が必要かどうかを判断する（複数のパッケージにわたる15ファイル超の変更）
• 人間に招集内容を確認する

出力： 機能仕様、推定スコープ、確定した派遣計画。

---

フェーズ 2：偵察（ブラッドハウンド）

指揮者が合図を送ります。ブラッドハウンドが森へ入ります……

Agent(bloodhound, model: haiku)
  Input:  feature spec only
  Reads:  bloodhound-scout/SKILL.md (MANDATORY)
  Output: territory map

コードベースを偵察するhaiku サブエージェントを派遣します。ブラッドハウンドが受け取るのは機能仕様のみです。意見や事前分析は与えません。ブラッドハウンドは自分のスキルファイルを読み、SCENT → TRACK → HUNT → REPORT の全ワークフローを実行します。

指揮者への引き継ぎ： 領域マップ（変更するファイル、見つかったパターン、統合ポイント、既存の規約、潜在的な障害）。

ゲートチェック： ファイル一覧、パターンの概要、統合ポイントを最低限含む領域マップを受け取ります。不完全な場合は、具体的な質問を添えてエージェントを再開します。

---

フェーズ 3：BUILD（Elephant）

地面が揺れます。Elephant がやってきます……

Agent(elephant, model: opus)
  Input:  feature spec + territory map (from Bloodhound)
  Reads:  elephant-build/SKILL.md + references (MANDATORY)
  Output: built files list + implementation summary

機能を構築するため、opus サブエージェントをディスパッチします。Elephant が受け取るのは仕様と領域マップです。Bloodhound の推論プロセスではなく、構造化された出力のみを受け取ります。

マルチエージェントのディスパッチ（対象が 15 ファイルを超える、または 3 つ以上のパッケージにまたがる場合）：

Agent(elephant-backend, model: opus)   → API routes, services, migrations
Agent(elephant-frontend, model: opus)  → Svelte components, stores, pages    PARALLEL
Agent(elephant-schema, model: sonnet)  → Database migrations, types

Then: Agent(elephant-wire, model: opus) → Integration wiring across all three

各サブ Elephant は elephant-build/SKILL.md を読み、自分の担当領域のみで作業します。

Elephant が必ず従うべき横断的な標準：

• すべてのエラーパスで Signpost エラーコードを使用します（buildErrorJson、throwGroveError）
• 境界で Rootwork の型安全性を確保します（parseFormData、safeJsonParse）
• 参照先：AgentUsage/error_handling.md、AgentUsage/rootwork_type_safety.md

conductor への引き継ぎ： ファイル一覧（作成・変更したすべてのファイル）、実装の概要（構築した内容、重要な判断）、未解決の質問。

ゲートチェック： gw ci --affected --fail-fast を実行します。少なくともコンパイルに成功する必要があります。ビルドに失敗した場合は、エラー出力を添えて Elephant エージェントを再開します。

---

フェーズ 4：HARDEN（Turtle）

Turtle がゆっくりと近づきます。構築されたものだけを見て、その理由は知りません……

Agent(turtle, model: opus)
  Input:  file list ONLY (not Elephant's reasoning — fresh adversarial eyes)
  Reads:  turtle-harden/SKILL.md + references (MANDATORY)
  Output: hardening report + applied fixes

セキュリティ強化のため、opus サブエージェントをディスパッチします。Turtle が受け取るのはファイル一覧のみで、Elephant の実装概要は受け取りません。これは意図的なものです。Turtle は構築者の推論に共感するのではなく、コードを新鮮な批判的視点で調査する必要があります。

Turtle が強化する項目：

• 入力検証（すべてのエントリーポイントに Zod スキーマを適用）
• 出力エンコーディング（コンテキストを考慮し、リッチテキストには DOMPurify を使用）
• パラメーター化クエリ（SQL で文字列連結を使用しない）
• セキュリティヘッダー（nonce を含む CSP、HSTS、X-Frame）
• Signpost エラーコード（Elephant が正しく使用したか確認）
• Rootwork の境界安全性（信頼境界で as キャストが使われていないことを確認）

conductor への引き継ぎ： 強化レポート（発見事項、修正内容、適用した防御レイヤー）、更新されたファイル一覧。

ゲートチェック： gw ci --affected --fail-fast を実行します。強化後もコンパイルに成功する必要があります。壊れている場合は、Turtle エージェントを再開します。

---

フェーズ 5：TEST（Beaver）

Beaver が小川を調べます。ダムがどのように造られたかは知らず、何を支えられるべきかだけを見ています……

Agent(beaver, model: sonnet)
  Input:  file list + feature spec (NOT implementation details)
  Reads:  beaver-build/SKILL.md + references (MANDATORY)
  Output: test suite + test results

テストを作成するため、sonnet サブエージェントをディスパッチします。Beaver が受け取るのはファイル一覧と元の機能仕様であり、Elephant の実装概要や Turtle の強化レポートは受け取りません。テストはコードを読むのではなく、振る舞いに基づいて作成する必要があります。

Beaver がテストする項目：

• 機能の振る舞い（コードではなく仕様に基づく）
• セキュリティのリグレッション（API ルートが適切な error_code フィールドを返すこと）
• 境界検証（不正な入力の拒否）
• catch ブロックの型ガード（isRedirect/isHttpError）

conductor への引き継ぎ： テストファイル一覧、テスト結果（成功／失敗の件数）、発見した動作上の不足点。

ゲートチェック： すべてのテストに合格する必要があります。gw ci --affected --fail-fast --diagnose を実行します。テストが失敗した場合は、失敗出力を添えて Beaver エージェントを再開します。テストで実装上のバグが明らかになった場合は、conductor が判断できるよう記録します。Elephant と Turtle のどちらを再開するか？

---

フェーズ 6：AUDIT（Raccoon + Deer + Fox — 並列）

3 匹の動物が一斉に空き地へ入ってきます。それぞれ異なる目で見ています……

3 つのサブエージェントを同時にディスパッチします。

Agent(raccoon, model: sonnet)  → Input: file list + feature scope
  Reads: raccoon-audit/SKILL.md
  Focus: secrets, dead code, dependency audit, unsafe patterns

Agent(deer, model: sonnet)     → Input: UI file list + feature spec      PARALLEL
  Reads: deer-sense/SKILL.md
  Focus: keyboard nav, screen readers, contrast, touch targets

Agent(fox, model: sonnet)      → Input: hot path files + feature spec
  Reads: fox-optimize/SKILL.md
  Focus: bundle size, query performance, lazy loading

各動物はそれぞれ独立して作業します。互いの発見事項は見えません。conductor が 3 件すべてのレポートを集めます。

conductor への引き継ぎ： 3 件のレポート（監査結果、アクセシビリティの結果、パフォーマンスの結果）。加えて、各動物が適用した修正があればその内容。

ゲートチェック： 3 件すべてのレポートを確認します。いずれかの動物が修正を要する問題を発見した場合：

• セキュリティの問題 → conductor が修正を適用するか、対象を絞ったエージェントを再ディスパッチします
• アクセシビリティの問題 → conductor が修正を適用します
• パフォーマンスの問題 → conductor が修正を適用します
• すべての修正後に gw ci --affected --fail-fast --diagnose を再実行します

---

フェーズ 7：ドキュメント作成（Owl）

フクロウが目を開きます。すべてを聞きました――今、その声を聞かせます……

Agent(owl, model: opus)
  Input:  FULL gathering summary (spec, territory map, file list,
          hardening report, test results, audit/a11y/perf reports)
  Reads:  owl-archive/SKILL.md + references (MANDATORY)
  Output: actual documentation written to files

opus サブエージェントを割り当てて、ドキュメントを作成します。フクロウには収集内容の要約をすべて渡します。有意義なドキュメントを書くには、背景情報が必要です。ドキュメント作成には温かみのある語り口と、何を記録すべきかを判断する力が必要なため、opus を使います。

フクロウが作成するもの：

• ヘルプ記事またはユーザー向けドキュメント（機能がユーザーに見える場合）
• API ドキュメント（新しいエンドポイントを作成した場合）
• ロジックが一目でわからない箇所のインラインコードコメント（「コード自体が説明になっている」は不可）
• 影響を受ける既存ドキュメントの更新

指揮者への引き継ぎ： ドキュメントファイルの一覧、記録した内容の要約。

ゲートチェック： ドキュメントファイルが存在し、実際の内容が記述されていること（スタブではないこと）を確認します。

---

フェーズ 8：コーラス

夜が明けます。指揮者が手を掲げます。森が歌い出します……

指揮者が最終検証を行い、概要を提示します。

# Final verification — the whole gathering's work proven sound
pnpm install
gw ci --affected --fail-fast --diagnose

コンポーネント監査ゲート（UI コンポーネントを含む機能の場合）：

ページレベルの検証に進む前に、Elephant が作成または変更したすべての UI コンポーネントを Showroom で個別に監査します。

# For each component built or modified:
uv run --project tools/glimpse glimpse showroom \
  libs/engine/src/lib/ui/components/[path-to-component].svelte

# For new components, scaffold fixtures first:
uv run --project tools/glimpse glimpse showroom \
  libs/engine/src/lib/ui/components/[path-to-component].svelte --scaffold

Showroom のコンプライアンス違反はすべて、先に進む前に解消する必要があります。違反が見つかった場合は、具体的な指摘事項を添えて Elephant を再開します。

ビジュアル検証（UI を含む機能の場合）：

uv run --project tools/glimpse glimpse matrix \
  "http://localhost:5173/[feature-page]?subdomain=midnight-bloom" \
  --seasons autumn,winter --themes light,dark --logs --auto

完了レポート：

🌲 GATHERING FEATURE COMPLETE

Feature: [Name]

DISPATCH LOG
  🐕 Bloodhound (haiku)  — [territory mapped, X files identified]
  🐘 Elephant (opus)      — [Y files built across Z packages]
  🐢 Turtle (opus)        — [N hardening fixes applied, M defense layers]
  🦫 Beaver (sonnet)      — [P tests written, all passing]
  🦝 Raccoon (sonnet)     — [audit clean / N issues fixed]
  🦌 Deer (sonnet)        — [a11y verified / N issues fixed]
  🦊 Fox (sonnet)         — [performance verified / N optimizations]
  🦉 Owl (opus)           — [documentation written at: paths]

GATE LOG
  After Scout:    ✅ territory map complete
  After Build:    ✅ compiles clean
  After Harden:   ✅ compiles clean, hardening applied
  After Test:     ✅ all tests pass
  After Audit:    ✅ findings resolved
  After Document: ✅ docs written (not stubs)
  Showroom:       ✅ all components pass compliance audit
  Final CI:       ✅ gw ci --affected passes

The forest grows. The feature lives.

---

指揮者のルール

動物の作業は決して行わない

指揮者は割り当てを行います。調査、構築、堅牢化、テスト、監査、ドキュメント作成は行いません。自分でコードを書いていることに気づいたら、作業を中断してください。サブエージェントを割り当てるべきです。

新鮮な視点は強み

Turtle と Beaver には、意図的に会話履歴全体よりも少ないコンテキストを渡します。Turtle は Elephant の推論を見ません（敵対的な新鮮な視点）。Beaver は実装の詳細を見ません（動作テスト）。この分離により、より良い結果が得られます。

移行ごとにゲートを設ける

動物の作業の間に検証を行います。不適切な状態を次の段階へ持ち越さず、早期に発見してください。

可能な場合は並行して実行する

Raccoon、Deer、Fox は同時に実行します。新鮮なエージェントが 3 つ、それぞれ異なる観点を担当し、コンテキストの共有はゼロです。

大規模なフェーズでは複数のエージェントを使う

Elephant が複数のパッケージにまたがる 15 個以上のファイルを変更する場合は、ドメインに特化した複数の sub-elephant に作業を分割します。それぞれがスキルを読み、それぞれのドメインを担当した後、統合エージェントが連携部分をまとめます。

やり直しではなく再開する

ゲートチェックに失敗した場合は、エラーのコンテキストを添えて失敗したエージェントを再開します。新しいエージェントを起動しないでください。再開したエージェントは、以前の作業をコンテキストに保持しています。

コミュニケーション

• 「太鼓が鳴ります……」（招集）
• 「[animal] を割り当てます……」（サブエージェントの起動）
• 「ゲートチェック：[result]……」（フェーズ間の検証）
• 「コーラスが高まります……」（最終検証）

---

アンチパターン

指揮者がしてはいけないこと：

• 自分でコード、テスト、ドキュメントを書く（サブエージェントを割り当てる）
• すべてのエージェントに会話履歴全体を渡す（構造化された引き継ぎのみ）
• ゲートチェックを省略する（「きっと問題ない」）
• すべての動物を同じコンテキストで実行する（分離こそが重要です）
• エージェントにスキルファイルの読み込みを省略させる（すべてのプロンプトで必須）
• ファイルの存在と内容を確認せずに、ドキュメントが「完了」したと宣言する
• ゲートの失敗を修正せずに先へ進む

---

迅速な判断ガイド

スコープ	ディスパッチ戦略
小規模な機能（10 ファイル未満）	標準：動物ごとに 1 つのエージェント
中規模な機能（10～20 ファイル）	標準。ただし、並列で作業するサブエレファントを検討
大規模な機能（20 ファイル以上、3 つ以上のパッケージ）	マルチエレファントのディスパッチ＋並列監査フェーズ
UI のみの機能	Fox をスキップし、Deer を重視して、Glimpse による検証を追加
API のみの機能	Deer をスキップし、Turtle と Raccoon を重視
既存のテストがある機能	Beaver がゼロから作成するのではなく、レビューして拡張

---

統合

開始前： 仕様／アーキテクチャには swan-design または eagle-architect 作業中： ゲートチェックで不可解な失敗が見つかった場合は mole-debug 完了後： 出荷前に結果を見直すには crow-reason

ドラムが鳴れば、森が応えます――新たな視点と全神経を注ぎ、どの動物も手を抜きません。 🌲