mcpField
G
gathering-architecture

gathering-architecture

github.com/autumnsgrove開発669 回インストール6 日前に更新
リポジトリ

gathering-architecture について

互いに独立したサブエージェントを調整し、アーキテクチャ設計、批評、仕様作成、基盤構築を順に進めるスキルです。各段階で成果物を確認して引き継ぐため、システム設計や大規模な変更に適しています。

主な機能

  1. 01サブエージェントの順次起動
  2. 02設計とレビューのコンテキスト分離
  3. 03各フェーズ間のゲート確認
  4. 04設計・仕様・構築の各段階
  5. 05確認失敗時のエージェント再開

活用シーン

  1. 01新規システムの一貫した設計
  2. 02仕様化前のアーキテクチャレビュー
  3. 03既存仕様に基づく基盤構築

インストール

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

$npx skills add https://github.com/autumnsgrove/lattice --skill gathering-architecture

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

同梱ファイルreferences/conductor-dispatch.md

詳細

Gathering Architecture 🌲🦅

太鼓の音が樹冠に響き渡ります。指揮者はその下に立ち、動物たちの登場を一つずつ指揮します。ワシは新鮮な空気の中を舞い上がり、偏りなくパターンを見つめます。カラスは別行動で現れ、設計者への遠慮なく異議を唱えます。白鳥は妥協した設計ではなく、強化された設計を受け取ります。ゾウは信頼できる仕様に基づいて構築します。隔離された四つの知性、意図された四つのモデル、そして一つのコードの大聖堂。

招集するタイミング

  • 新しいシステムやサービスを設計するとき
  • 重要なアーキテクチャ上の決定を行うとき
  • コアインフラをリファクタリングするとき
  • 他の機能の基盤となるプラットフォームを作成するとき
  • ビジョン、検証、仕様、実装を順番に進める必要があるとき

重要： この集まりは指揮者です。設計、検証、仕様作成、構築を直接行うことはありません。動物ごとに一つずつサブエージェントを派遣し、それぞれに隔離されたコンテキストと意図されたモデルを与えます。指揮者は引き継ぎとゲートチェックのみを管理します。

集まり

SUMMON → DISPATCH → GATE → DISPATCH → GATE → DISPATCH → GATE → DISPATCH → GATE → CHORUS
  ↓         ↓        ↓        ↓        ↓        ↓        ↓        ↓        ↓        ↓
Spec     Eagle    Check     Crow    Check     Swan    Check   Elephant  Check    Final
(self)   (opus)    ✓      (sonnet)   ✓      (opus)    ✓      (opus)     ✓     Verify
派遣する動物たち
順序動物モデル役割新鮮な視点？
1🦅 ワシopus高レベルのアーキテクチャを設計するはい — システム仕様のみを確認します
2🐦‍⬛ カラスsonnet設計を検証するはい — アーキテクチャ文書のみを確認し、ワシの推論は見ません
3🦢 白鳥opus詳細な仕様を作成するはい — 強化されたアーキテクチャ（ワシの設計＋カラスの修正）を確認します
4🐘 ゾウopus基盤を構築するはい — 白鳥の仕様のみを確認します

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

フェーズ 1：招集

太鼓が鳴り、樹冠がざわめきます……

指揮者はアーキテクチャの依頼を受け取り、派遣計画を準備します。

システムを明確にする：

  • どのような問題を解決しますか？
  • 規模の要件は何ですか？
  • 制約は何ですか？
  • どのような成長を見込んでいますか？

自然のメタファー：

「すべてのアーキテクチャには自然のメタファーが必要です。このシステムは何に似ていますか？ Heartwood（中核）、Wisp（穏やかな案内役）、Porch（集いの場）、それとも別のものですか？」

インフラストラクチャの抽象化：

  • 移植性を確保するため、Server SDK の GroveDatabase／GroveStorage／GroveKV／GroveServiceBus を使用します。
  • ユーザーファイルの管理には Amber SDK（FileManager、QuotaManager）を使用し、生の R2 は使用しません。
  • すべてのデータ境界で Rootwork ユーティリティを使用します。

人間に確認してから、次に進みます。

出力： システム仕様、確認済みの派遣計画。

フェーズ 2：設計（ワシ）

指揮者が合図し、ワシが舞い上がります……

Agent(eagle, model: opus)
  Input:  system specification only
  Reads:  eagle-architect/SKILL.md + references (MANDATORY)
  Output: architecture overview document

opus サブエージェントを派遣して、アーキテクチャを設計させます。ワシが受け取るのはシステム仕様のみです。ワシは自身のスキルファイルを読み込み、ワークフロー全体を実行します。

ワシが作成するもの：

  • システム境界とコンポーネント間の相互作用
  • 根拠を添えた技術選定
  • 規模の制約と成長戦略
  • データフロー図
  • アーキテクチャ決定記録（ADR）
  • システムの自然のメタファー

指揮者への引き継ぎ： アーキテクチャ概要文書（会話形式ではなく、構造化された形式）。

ゲートチェック： アーキテクチャ文書に、システム境界、コンポーネント図、技術選定、ADR が含まれていることを確認します。不足がある場合は、具体的な質問を添えてワシに作業を再開させます。

フェーズ 3：CHALLENGE（Crow）

Crowが止まり木にとまります。ほかの者が疑問に思わないことに、首をかしげます……

Agent(crow, model: sonnet)
  Input:  architecture document ONLY (not Eagle's reasoning process)
  Reads:  crow-reason/SKILL.md (MANDATORY)
  Output: challenge report + strengthened design recommendations

Red Teamモードでsonnet subagentを起動し、Eagleのアーキテクチャに対する課題を洗い出します。Crowが受け取るのはアーキテクチャ文書のみで、Eagleの内部推論は受け取りません。この隔離は意図的なものです。Crowは設計者の正当化に説得されるのではなく、設計そのものの価値に基づいて課題を指摘する必要があります。

Crowが検証する項目：

  • 実証されていない前提
  • 単一障害点
  • よりシンプルにできる複雑さ
  • 根拠のないスケーラビリティの主張
  • 想定されていない障害モード
  • 小規模チームにかかる運用負荷

指揮者への引き継ぎ： 具体的な推奨事項を含む課題レポート（Roostの要約）。その後、指揮者がどの課題についてEagleに修正を求めるかを判断します。

ゲートチェック： Crowが、具体的で実行可能な推奨事項を含む課題を提示していること（曖昧な懸念ではないこと）。課題によって設計に根本的な問題が明らかになった場合は、Crowの指摘を添えてEagleを再開し、修正を依頼します。

反復： Eagleに修正が必要な場合：

  1. Crowの具体的な指摘を添えてEagleを再開します
  2. Eagleがアーキテクチャを改訂します
  3. 必要に応じてCrowを再開し、再度課題を洗い出します（最大2回）
フェーズ 4：SPECIFY（Swan）

Swanが滑るように進みます。優雅さと精密さが出会います……

Agent(swan, model: opus)
  Input:  strengthened architecture (Eagle's doc + resolved Crow challenges)
  Reads:  swan-design/SKILL.md + references (MANDATORY)
  Output: complete technical specification

詳細仕様を作成するためにopus subagentを起動します。Swanが受け取るのは、Crowの課題によって強化されたアーキテクチャ文書です。議論ではなく、解決済みの設計を確認します。

Swanが作成するもの：

  • APIコントラクト（リクエスト／レスポンス形式）
  • リレーションシップを含むデータベーススキーマ
  • 主要な操作のフロー図
  • 依存関係順に並べた実装チェックリスト
  • エラー処理パターン（Signpostコード）
  • 設定およびデプロイ要件

指揮者への引き継ぎ： 完全な技術仕様書。

ゲートチェック： 仕様にAPIコントラクト、データベーススキーマ、フロー図、実装チェックリストが含まれていること。不足しているセクションがある場合はSwanを再開します。

フェーズ 5：BUILD（Elephant）

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

Agent(elephant, model: opus)
  Input:  Swan's technical specification ONLY
  Reads:  elephant-build/SKILL.md + references (MANDATORY)
  Output: built foundation + file list

アーキテクチャの基盤を構築するためにopus subagentを起動します。Elephantが受け取るのはSwanの仕様のみで、Eagleのビジョン文書やCrowの課題は受け取りません。構築においては、仕様を唯一の信頼できる情報源とします。

Elephantが構築するもの：

  • データベースマイグレーションとスキーマ
  • コアサービスとビジネスロジック
  • 適切なエラー処理を備えたAPIルートの骨組み
  • 型定義
  • 基盤に必要なテスト
  • 設定ファイル

横断的な標準（必須）：

  • すべてのエラーパスでSignpostエラーコードを使用する
  • すべての境界でRootworkによる型安全性を確保する
  • Engine優先のパターン（重複を避けるため、まず確認する）

指揮者への引き継ぎ： ファイル一覧（作成／変更したすべてのファイル）、実装の概要、仕様からの逸脱があればその内容。

ゲートチェック：

pnpm install
gw dev ci --affected --fail-fast --diagnose

コンパイルとテストに合格する必要があります。失敗した場合は、エラーを添えてElephantを再開します。

フェーズ 6：CHORUS

夜が明けます。アーキテクチャが完成します……

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

gw dev ci --affected --fail-fast --diagnose

完了レポート：

🌲 GATHERING ARCHITECTURE COMPLETE

System: [Name]

DISPATCH LOG
  🦅 Eagle (opus)      — [architecture designed, X ADRs written]
  🐦‍⬛ Crow (sonnet)   — [Y challenges raised, Z resolved]
  🦢 Swan (opus)        — [specification written, N sections]
  🐘 Elephant (opus)    — [foundation built, M files across P packages]

GATE LOG
  After Eagle:    ✅ architecture document complete
  After Crow:     ✅ challenges resolved, design strengthened
  After Swan:     ✅ specification complete with all sections
  After Elephant: ✅ compiles clean, foundation tested
  Final CI:       ✅ gw dev ci --affected passes

ARTIFACTS
  Architecture: [doc path]
  Specification: [spec path]
  Foundation: [code locations]
  Tests: [test locations]

The forest has a new landmark.

指揮者のルール

動物の仕事は決してしない

指揮者はエージェントを起動します。設計、課題の指摘、仕様の作成、構築は行いません。

新鮮な視点を活用する

Crowが見るのはアーキテクチャ文書のみで、Eagleの推論は見ません。Elephantが見るのはSwanの仕様のみで、議論の履歴は見ません。この隔離によって、すべての段階でより良い結果が得られます。

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

各段階の間で出力を確認します。課題を洗い出す前にアーキテクチャを完成させます。仕様を作成する前に課題を解決します。構築を始める前に仕様を完成させます。

最初からやり直さず、再開する

ゲートチェックに失敗した場合や、Crowによって設計の根本的な問題が明らかになった場合は、該当するエージェントを再開します。新しいエージェントを起動してはいけません。

反パターン

コンダクターは次のことをしてはいけません。

  • 自らアーキテクチャを設計する（Eagle に割り当てます）
  • Crow の指摘を和らげる（そのまま Eagle に伝えます）
  • Eagle に設計の議論を見せる（最終仕様のみを渡します）
  • Crow のフェーズを省略する（「設計に問題はなさそうです」）
  • エージェントにスキルファイルの読み込みを省略させる
  • ゲートの失敗後も続行する

すばやく判断するためのガイド

範囲戦略
新しいシステムで、設計全体が必要4 つすべて：Eagle → Crow → Swan → Elephant
仕様があり、実装が必要Elephant のみ（仕様を入力として渡します）
実装なしの設計レビューEagle → Crow → Swan（Elephant を省略します）
チームが構築する簡易設計Eagle → Crow（Swan と Elephant を省略します）
大規模な基盤（20 以上のファイル）複数の Elephant を割り当てます（gathering-feature を参照）

ビジョンから基盤へ、森は育っていきます。 🌲

コメント

Markdown 対応