mcpField
G
gathering-architecture

gathering-architecture

github.com/autumnsgrove开发669 次安装6 天前更新
代码仓库

关于 gathering-architecture

通过协调彼此隔离的子 Agent，依次完成架构设计、质疑审查、编写规格和基础实现。适用于系统设计与重大改造，并以阶段检查和明确交接控制流程。

主要功能

  1. 01按顺序分派子 Agent
  2. 02隔离设计与审查上下文
  3. 03各阶段间设置检查门槛
  4. 04涵盖架构、规格与构建阶段
  5. 05检查失败后恢复原 Agent

适用场景

  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

详细介绍

汇聚架构 🌲🦅

鼓声在树冠高处回荡。指挥者站在下方，协调每只动物依次登场。鹰在清新的空气中翱翔，不带偏见地观察模式。乌鸦随后独自到来，毫不留情地质疑架构师。天鹅接过经过强化的设计，而非妥协后的设计。大象依据自己信任的规格进行构建。四个彼此隔离的思维，四种有意设计的模型，共同铸就一座代码大教堂。

何时召集

  • 设计新系统或服务
  • 做出重大架构决策
  • 重构核心基础设施
  • 创建供其他功能构建其上的平台
  • 当愿景、质疑、规格和实现必须依次推进时

重要：这场汇聚由指挥者统筹。它绝不会直接进行设计、质疑、编写规格或构建。它会派遣子 Agent——每种动物各一位——每位都拥有隔离的上下文和专属模型。指挥者只负责协调交接和把关。

汇聚流程

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，查看准确的子 Agent 提示词和交接格式

阶段 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 子 Agent 设计架构。鹰只会收到系统规格。它会读取自己的技能文件，并执行完整工作流。

鹰的产出：

  • 系统边界和组件交互
  • 技术选型及其理由
  • 规模约束和增长策略
  • 数据流图
  • 架构决策记录（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

以红队模式派遣一个 sonnet 子 Agent，针对 Eagle 的架构进行审查。Crow 只会收到架构文档——不会收到 Eagle 的内部推理。这种隔离是有意为之：Crow 应根据设计本身的优劣提出质疑，而不是被架构师的论证说服。

Crow 会质疑的内容：

  • 未经证实的假设
  • 单点故障
  • 本可简化的复杂性
  • 缺乏证据的规模声明
  • 缺失的故障模式
  • 小团队承担的运维负担

**移交给 conductor：**挑战报告（Roost 摘要），其中包含具体建议。随后 conductor 决定哪些挑战需要 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 子 Agent 撰写详细规范。Swan 收到的是经 Crow 挑战完善后的架构文档——它看到的是已敲定的设计，而非辩论过程。

Swan 产出的内容：

  • API 契约（请求/响应格式）
  • 含关联关系的数据库架构
  • 关键操作的流程图
  • 按依赖关系排序的实施清单
  • 错误处理模式（Signpost 代码）
  • 配置和部署要求

**移交给 conductor：**完整的技术规范文档。

**关卡检查：**规范包含：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 子 Agent 搭建架构基础。Elephant 只会收到 Swan 的规范——不会收到 Eagle 的愿景文档或 Crow 的挑战。规范是构建时唯一的事实来源。

Elephant 构建的内容：

  • 数据库迁移和架构
  • 核心服务和业务逻辑
  • 具备恰当错误处理的 API 路由骨架
  • 类型定义
  • 基础功能所需的测试
  • 配置文件

横切标准（不可协商）：

  • 所有错误路径都使用 Signpost 错误代码
  • 所有边界都具备 Rootwork 类型安全
  • 优先使用 Engine 模式（先检查再重复实现）

**移交给 conductor：**文件列表（创建/修改的每个文件）、实施摘要，以及任何偏离规范之处。

关卡检查：

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

必须编译通过并通过测试。如果失败，则将错误信息提供给 Elephant，让其继续处理。

阶段 6：CHORUS

黎明破晓。架构巍然矗立……

conductor 执行最终验证并呈现摘要：

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.

conductor 规则

绝不承担动物的工作

conductor 负责派遣，不负责设计、质疑、编写规范或构建。

保持独立视角是优势

Crow 只查看架构文档，不看 Eagle 的推理。Elephant 只查看 Swan 的规范，不看辩论历史。这种隔离能提升每个阶段的结果。

每次交接都要设关卡

每个阶段结束后都要验证产出。完成架构后才能提出挑战。解决挑战后才能编写规范。完成规范后才能开始构建。

继续处理，不要重启

如果关卡检查失败，或 Crow 揭示了根本性的设计问题，就让相关 Agent 继续处理。不要新建 Agent。

反模式

指挥者不会：

  • 自己设计架构（将任务派发给 Eagle）
  • 缓和 Crow 提出的质疑（不加修改地转交给 Eagle）
  • 让 Elephant 看到设计辩论过程（只提供最终规格）
  • 跳过 Crow 阶段（“设计看起来没问题”）
  • 让 Agent 跳过阅读自己的技能文件
  • 在关卡失败后继续

快速决策指南

范围策略
新系统，需要完整设计全部四个：Eagle → Crow → Swan → Elephant
已有规格，需要实现仅 Elephant（以规格为输入）
设计评审，不需要实现Eagle → Crow → Swan（跳过 Elephant）
快速设计，由团队负责构建Eagle → Crow（跳过 Swan + Elephant）
大型基础功能（20+ 个文件）多个 Elephant 派发（参见 gathering-feature）

从愿景到基础，森林不断生长。 🌲

评论

支持 Markdown