用途：在动手实现前先确定项目形态与最小架构，明确所有权、副作用、错误与测试边界，而不是照搬某个被推崇的项目。适用于用户询问“该用什么架构”“是否属于堆叠式工作”“写完整规格”“设计运行时”“比较优秀库”，或改动涉及运行时、状态所有权、适配器、插件、事件循环、渲染、调度器、持久化、跨模块契约时；也用于大量 issue/PR 看似各自合理但可能不收敛于同一架构、成熟仓库存在重复路径与兼容垫片、或新技能/框架/库/大功能需要基础指南时。小型局部修复且现有架构明确时不适用。
主要能力：先检索现有架构文档、入口点、清单、模块树、公开 API、issue/PR 与测试；对已有仓库还要检查生成/配置产物、迁移文件、后台 worker、cron、适配器及最大文件与测试。将项目形态归类为简单库、CLI/开发工具、API 网关或模型路由、长运行运行时、生命周期/组合框架、事件/缓存/协调控制器、配置/模块平台、UI 或应用外壳、服务框架、智能体或工作流系统等。选择一种主状态所有权模型（应用自有实体与句柄、状态加类型化消息、虚拟 DOM/信号、类型化状态或服务实例状态、事件日志加投影/发件箱、world/resource/system、快照数据库或输入事实、流式管道）。划分 product/app、core/domain、runtime/application、adapters/backends、plugins/components、testing/headless 等边界。
使用方式：先审计现有边界健康度，为每个契约指明当前事实来源（代码、数据库表、SQL 种子、JSON/YAML 配置、生成文档或外部提供方契约），标记重复路径为有意桥接、遗留兼容或意外分叉，并要求兼容路径有退出条件。先写契约再写任务，契约涵盖所有权、生命周期、副作用契约、事件/动作、错误策略、配置/资源、可观测性、测试。产出规格而非仅图，可用 references/spec-template.md；把规格转为 P0/P1/P2 工作，每项任务映射到一个契约。快速回答按 verdict、chosen_shape、state_owner、boundaries、contracts、migration_debt、validation、risks、next_steps 输出。
限制与决策规则：产品不需要自持运行时则优先薄适配器；仅在稳定 API 边界、副作用隔离、编译期隔离、独立测试或真实复用时拆分 crate/模块；已有仓库若真正问题是事实来源重复、迁移未完成或缺少闭环测试，不要先拆包。core 不得含平台句柄、事件循环、渲染句柄、webview、数据库客户端、HTTP 请求、进程生成与环境读取。隐藏全局状态非法，除非显式建模为类型化运行时状态或作用域资源。插件不得成为架构逃生舱，每个插件需 API、配置/权限、生命周期、错误与测试。不接受静默降级，缺失能力须按契约显式报不支持错误、诊断或空结果。设计 Rust 时读 references/rust-architecture-patterns.md，设计 Go 时读 references/go-architecture-patterns.md，需要独立架构评审智能体时使用 agents/openai.yaml。具体安装命令与收费信息暂未提供。