$ loading_
为软件架构图提供设计与审查建议，提升文档中的图示清晰度与规范性
复制安装指令，让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "diagram-design" 技能： 1. 下载 https://raw.githubusercontent.com/microsoft/devsquad-copilot/main/.github/plugins/devsquad/skills/diagram-design/SKILL.md 2. 保存为 ~/.claude/skills/diagram-design/SKILL.md 3. 装好后重载技能，告诉我可以用了
请审查这段 Mermaid 系统架构图定义，指出可读性、命名、层级划分和连线表达的问题，并给出改进后的 Mermaid 版本，适用于 GitHub Markdown 渲染。
得到一份问题清单、优化建议，以及可直接替换的 Mermaid 图代码。
我需要在技术文档中展示一个包含多个系统边界、数据流和部署节点的架构图。请比较 Mermaid 与 Draw.io 的适用场景，并建议我该用哪种工具及原因。
得到基于复杂度、维护性、协作方式和渲染平台的工具选型建议。
请根据以下接口交互说明，生成一个清晰的 Mermaid 时序图，并确保参与者命名一致、步骤顺序明确、异常流程可读，适合放在 Azure DevOps Wiki 中。
得到结构清晰、平台兼容的 Mermaid 时序图及必要的表达优化说明。
A diagram exists to help someone understand something. Before creating one, ask: who is the audience and what question does this diagram answer?
Zoom, don't cram. Each diagram should answer one question at one level of abstraction. Use separate diagrams for context, containers, components, and code, like zooming into a map.
Keep it simple. When a diagram feels cluttered, split it. Avoid crossing arrows, limit to ~15 elements, and prefer clarity over completeness.
Every element must be meaningful. Each box needs a name and a responsibility (one sentence). Add technology labels only for technical audiences. If you cannot describe what an element does, remove it.
Diagrams complement text. Add a short paragraph for context the visual cannot convey (why, constraints, what is not shown). Do not repeat in text what the diagram already shows.
Apply before considering a diagram done:
Shapes help distinguish element types at a glance (rectangle for services, cylinder for data stores, person for actors, cloud for external systems). Pick a consistent mapping and apply it throughout the project.
Colors add information but should not be the only differentiator (~8% of males have color vision deficiency). Pair color with shape, pattern, or label so diagrams remain readable in grayscale. Limit to 4-5 colors, avoid red/green as sole distinguishing pair, and document the mapping in the legend.
Icons (Draw.io) add recognition but must complement text labels, not replace them. Use official service icon sets and do not mix providers. Read references/drawio-guide.md for creation and export workflow.
| Factor | Mermaid | Draw.io |
|---|---|---|
| Complexity | Simple to medium (< 15 elements) | Medium to complex, or spatial layout matters |
| Icons | No native support | Rich icon libraries (cloud providers, UML) |
| Version control | Text-based diff in markdown | Binary .drawio (XML, harder to review) |
| Rendering | Inline in GitHub/Azure DevOps | Exported as .drawio.png, referenced as image |
Start with Mermaid. Switch to Draw.io when the diagram needs spatial freedom, icons, or more than ~15 elements.
<br/> inside labels and node text. Mermaid does not interpret \n as a line break; it renders as literal text.| What you want to show | Mermaid type |
|---|---|
| System context, containers, components | C4Context, C4Container, C4Component |
| Request/response flow between services | sequenceDiagram |
| Process or data flow | flowchart LR or flowchart TD |
| State transitions | stateDiagram-v2 |
| Entity relationships | erDiagram |
| Class structure | classDiagram |
Use LR (left-to-right) for flows and pipelines; TD (top-down) for hierarchies.
Detect from the git remote (git config --get remote.origin.url):
github.com): use code block with ```mermaid and ```…
基于代码差异生成规范化 Git 提交信息，并支持按逻辑分组提交
将 Markdown 文档发布为支持 Mermaid 的公开分享链接