用途：帮助在具体项目中选定并应用软件架构风格，核心是管理“改动代价高的边界”，让领域显式、I/O 留在边缘，而不是把分层图照搬到每个 CRUD。
主要能力：提供诊断问题（领域还是 I/O 是风险中心、单团队还是多团队、单部署还是多部署、读写模型是否差异大、是否已有统一语言与限界上下文）；给出风格选型表，包括简单分层、MVVM、Clean/六边形、DDD、模块化单体、垂直切片、CQRS、事件驱动、微服务，并说明各自适用条件；给出整合规则，如按变更原因而非技术类型划分内聚、只依赖他模块公开 API、依赖指向领域、打破模块循环、先在进程内划出边界再抽微服务。
使用方式：先做 project-discovery 了解仓库现状；命名上下文与数据归属；决定单进程（模块化单体）还是多进程（微服务）；仅在 I/O 妨碍测试与演进处调整依赖方向；只有出现具体读痛点或解耦需求时才引入 CQRS 与事件。可与 ddd、clean-architecture、modular-monolith、cqrs、event-driven-architecture、microservices-architecture、mvvm-architecture、api-design 等技能配合。
适用场景：领域规则复杂、需要长期演进、团队与部署节奏分化、读写模型明显不同的系统。
限制：资料未提供具体安装命令、平台支持、收费与价格信息；强调不要无对应痛点就叠加风格，避免贫血 DTO、为按钮建 use case、无 SLO 就上微服务、把事件总线当 RPC 等反模式。