系统设计
创建能够回答用户问题的最少视图集。优先使用可编辑的 .drawio 文件制作正式图表；尊重所要求的符号、格式、课程评分标准以及现有文件。一个有效的 XML 文件并非正确模型的证明。
工作流
- 确定受众、系统边界、问题、场景和抽象层级。阅读所提供的需求/模式/代码以及任何评分标准。记录不确定的基数、权限、生命周期规则和外部接口作为假设；仅在它们会实质性地改变答案时才提出问题。不要发明基础设施或强制性的关系。
- 根据下面的路由表选择视图。只阅读相关的参考资料以及
diagram-validation.md。区分当前状态的证据和提议的设计。当多个视图共享概念时，保留一个小型词汇表并附上稳定的概念ID。 - 在放置形状之前构建语义清单：参与者/元素、带有方向和端点含义的关系、约束以及需求ID。对于DFD，添加流字典和分解边界签名；对于数据模型，确定键和依赖关系。
- 遵循特定图的绘制流程。明确设置符号（例如 UML 2、Crow's Foot、Gane–Sarson；先上下文再0级）。将语义规则与建议的布局选择分开。按照
sources.md中的描述解决冲突的来源。 - 对于 Draw.io，阅读
drawio-rendering.md和layout.md。使用 XML 序列化器创建带有稳定ID的原生形状和连接器。仅在替换其领域事实后复制相关示例。对于其他格式，阅读fallbacks.md。 - 运行
python3 <skill-dir>/scripts/validate_drawio.py <file-or-directory>。修复报告的结构性错误。使用语义和跨视图检查清单：该脚本无法证明 UML、DFD、ERD 或 BPMN 的正确性。 - 在 diagrams.net 中打开/导入，或使用可用的 Draw.io 渲染器导出。检查每个页面的标签、箭头端点、裁切、包含和交叉；调整并再次检查。如果没有渲染器可用，则交付可编辑的源文件并明确报告渲染未经验证。不要将 XML 解析视为可打开性测试。
- 交付源文件、有用的预览图以及简短的验证/假设说明。明确说明运行了哪些检查。在编辑期间保留现有的手动布局和不相关的页面；刷新过时的预览图。
参考路由表
| 用户问题 | 阅读资料 |
|---|---|
| UML选择/符号基线 | uml.md |
| 角色与用户目标 | use-case.md |
| 领域或软件结构 | class-diagram.md |
| 跨协作者的一个场景 | sequence-diagram.md |
| 工作流、分支、并发 | activity-diagram.md |
| 一个实体的事件驱动生命周期 | state-machine.md |
| 实例、链接、模块、运行时部署 | structural-views.md |
| 通信、时序、交互概览 | advanced-interactions.md |
| 实体、关系、关系模式 | erd.md, normalization.md |
| 数据移动与分解 | dfd.md, context-diagram.md |
| 架构层次 | c4-model.md |
| 业务协作/流程 | bpmn.md |
| 简单流程或职责交接 | flowchart-swimlane.md |
| 输出生成/美化 | drawio-rendering.md, layout.md, fallbacks.md |
| 审查/多视图一致性 | diagram-validation.md |
| 来源溯源/版本/限制 | sources.md |
输出约定
尊重用户路径。否则使用 docs/diagrams/<system>-<view>.drawio，并尽可能附上对应的 .svg 或 .png 预览图。对于重要的假设使用 <system>-assumptions.md，对于多视图审计使用 <system>-validation.md。将临时导出文件保留在最终交付物之外。对于独立维护的视图使用单独的文件，对于协调的视图集使用命名页面。切勿以通用流程图静默替换所要求的正式符号。
不可妥协的检查项
- 模型事实必须来自证据或标注的假设。
- 检查端点语义；方向错误的箭头在语法上可能仍然有效。
- DFD 箭头承载数据；UML/BPMN 控制流承载执行含义。
- 不要从外键或模糊的“has-a”短语推断生命周期所有权。
- 审查相关共享概念；不要求不同范围的视图包含完全相同的内容。
- 保持图形可编辑；嵌入在
.drawio文件中的图像不是原生图表。
示例和可执行检查位于 examples/ 和 scripts/ 目录。特定包的测试证据在 TEST-REPORT.md 中。