Stratum 是一个面向软件架构建模与评估的智能体技能，基于 C4 模型方法论，用于结构化描述软件系统并生成 Structurizr DSL。它自我定位为“架构建模者”：决定要建模什么内容，而把图形渲染委托给 Canvas。
用途 适用于需要新建 C4 模型（包括从既有代码库中抽取）、评审或校验既有 C4 模型的一致性、生成或更新 Structurizr DSL、在 System Context / Container / Component / Code 各层做设计决策、设计 System Landscape / Dynamic / Deployment 补充图、在系统变更后做增量更新，以及基于自然语言简报做 LLM 辅助的架构发现。
不适用（需路由到其他技能）的情形包括：仅做图形渲染或样式 → Canvas；依赖图、循环引用或技术债分析 → Atlas；API 设计或 OpenAPI 规范 → Gateway；HLD/LLD 文档模板 → Scribe；基础设施供给（Terraform/Docker）→ Scaffold；建模前的变更影响分析 → Ripple。
主要能力与核心契约 只交付 C4 模型产物（Structurizr DSL、一致性报告、模型摘要），绝不输出实现代码。要求先阅读真实代码库再建模，不允许凭猜测或记忆建模。以 Structurizr DSL 工作区为唯一事实源，所有视图从单一模型派生，防止层间漂移。每个 C4 元素都必须标注技术栈、职责和一句描述性说明。每次导出都要做跨层一致性校验：L1 系统分解为 L2 容器、每个 L2 容器归属某个 L1 系统、每个 L3 组件属于某个 L2 容器。Container 到 Container 的关系必须标注明确的协议或技术（如 JSON/HTTPS、SQL/TCP、gRPC）。每个图视图都要有标题、图例和元素类型标签。多数团队 L1+L2 已足够，只有受众需要组件/代码级细节时才展开到 L3/L4。Container 必须按 C4 官方规范定义：须有独立运行时边界（进程或部署单元），JAR/DLL/程序集不是 Container，且不得把 C4 Container 与 Docker 容器混为一谈。
工作方式 流程为 DISCOVER → MODEL → VERIFY → EXPORT。DISCOVER 阶段从代码库与系统知识中抽取 C4 元素；MODEL 阶段用 Structurizr DSL 把元素组织成 C4 层级；VERIFY 阶段做跨层一致性检查与符号合规检查；EXPORT 阶段按请求格式输出已验证模型，以 Structurizr DSL 为主，Mermaid/PlantUML 为次。
内置配方（Recipe） 包括 New Model（model，默认，创建新的 C4 模型，先产出 L1–L2 作为基线）、Evaluate Existing（evaluate，评估既有架构，如 ATAM、SAAM）、Structurizr DSL（dsl，生成或更新 DSL，可考虑 workspace extends、archetypes、!adrs）、C4 Level Switch（c4，在 L1–L4 间切换粒度）、ADR Authoring（adr，用 Nygard/MADR 模板编写架构决策记录，含状态生命周期与索引）、Quality Attribute Scenarios（quality-attr，SEI 六要素场景、效用树、QAW 工作坊）、Tradeoff Analysis（tradeoff，ATAM 敏感点/权衡点/风险识别，可选 CBAM 成本收益扩展）。另有信号关键词到配方（Recipe）的映射，用于没有显式子命令的自然语言输入。
建模要点（资料中列出的实践约定） 使用隐含关系遵循 DRY 原则——在尽可能具体的层级定义关系，让 Structurizr 自动推导上级关系；多团队或企业场景使用 workspace extends 组合共享基础工作区；元素名易冲突的模型使用 !identifiers hierarchical 以点号引用（如 system1.api）；用 group 关键字在同一抽象层内做视觉分组（分组只用于视觉组织，不产生新的 C4 抽象层）；用 archetypes 定义可复用自定义类型（archtypes 可继承 archetypes）；用 !adrs 嵌入 ADR（支持 adrtools、MADR、log4brains 导入器），用 !docs 附加 Markdown/AsciiDoc 文档。在 configuration 块中设定 workspace 作用域（softwaresystem | landscape）以触发内置校验。
Structurizr 生态与工具集成 可利用官方 Structurizr MCP 服务器（mcp.structurizr.com/mcp）做 DSL 校验、解析、检查与 AI 辅助模型生成；文本 DSL 适合 LLM 消费。可将 MCP 兼容智能体连接到 https://mcp.structurizr.com/mcp。可考虑 LikeC4 作为互补的 C4 风格建模 DSL（当需要交互式、可嵌入的 React 图或原生 MCP/AI 智能体集成时），但资料指出 LikeC4 生态比 Structurizr 小、DSL 可持续性不太确定。
审计与数据参考 资料提到 IcePanel State of Software Architecture Report 2025（75 名受访者，57% 为架构师）的采用数据：Context（L1）图 81%、Container（L2）79%、Component（L3）41%，Dynamic 与 System Landscape 补充图各约 27–28%；主要挑战是团队间缺乏标准/一致性、难以找到合适的细节层级、文档难以保持最新。
限制与注意事项（资料明确列出） 不写实现代码；不做最终图形渲染；不得把 C4 Container 与 Docker 容器混淆；不得跳过跨层一致性检查；不得定义未标注技术栈的 Container 或 Component；不得展示外部系统的内部实现细节；不得把共享库（JAR、NuGet 包、npm 模块）建模为 Container；不得添加任意抽象子层（如“子组件”）；不得使用“业务逻辑”这类笼统标签或未解释的缩写；Structurizr DSL 中不得使用前向引用（DSL 按自上而下的命令式处理）；不得在多个 C4 层级重复定义关系。资料还提示：不要为新部署推荐 Structurizr 云服务（托管服务 2026 年 9 月 30 日 EOL，2026 年 7 月 1 日起只读，月度订阅取消），应改用 Structurizr Lite/本地部署/CLI（静态站点导出），并提到 Structurizr Lite 仓库已于 2026 年 2 月 4 日归档，转向合并后的 vNext 工具链；不要假设 Structurizr vNext UI 中可用 Graphviz 自动布局（vNext 集成渲染器已移除 Graphviz，改用 Dagre，Graphviz 仍可通过独立 CLI/JSON 管道调用）；不要把 Structurizr vNext 开源核心与过去的商业云服务混为一谈。
其他信息 资料提到 Stratum 与其他技能的协作模式：输入来自 User、Atlas、Lens、Ripple、Scaffold；输出到 Canvas、Scribe、Atlas。项目亲和度标注为 SaaS(H)、E-commerce(H)、Dashboard(M)、Game(L)、Marketing(L)。写作上建议面向 Opus 4.8 默认，遵循 P3、P5 等原则。
以上功能、命令、URL 与生态细节均来自所提供资料；资料未提供的具体安装方式、定价、平台支持与使用步骤，暂未提供。