需要 Mermaid classDiagram…

适用于用户明确要 Mermaid 类图、复杂多实体关系/ER 风格建模，或需复用/检查 CloudBase 已发布数据模型的场景。

适用场景

解决思路

1. 默认不要用本技能：大多数 MySQL 数据库任务改用 `relational-database-mcp-cloudbase` 直接写 SQL；若涉及 PostgreSQL、CloudBase PG、PG mode、`app.rdb()`、`queryPgDatabase`、`managePgDatabase` 或 RLS，改用 `postgresql-development-cloudbase`。
2. 仅当图表驱动建模确实增加价值时，才使用本技能。
3. 当用户明确要 Mermaid `classDiagram` 建模时，使用本技能。
4. 当任务需要复杂多实体关系设计、可视化 ER 风格输出，或生成数据结构而非直接 SQL 时，使用本技能。
5. 当需要通过专用建模工具创建 CloudBase 数据模型，或在规划后续变更前检查已有模型时，使用本技能。
6. 若请求提到 data model、ER diagram、Mermaid、relationship graph 或 enterprise schema design，在写代码前先阅读本技能。
7. 若用户想复用或更新已有发布模型，先阅读本技能。
8. 若要做直接 MySQL SQL 创建或 schema 变更，同时阅读 `../relational-database-mcp-cloudbase/SKILL.md`。
9. 若要做 PostgreSQL / CloudBase PG schema 工作，同时阅读 `../postgresql-development-cloudbase/SKILL.md`。
10. 若在 schema 工作前做更大范围功能规划，同时阅读 `../spec-workflow/SKILL.md`。
11. Sibling CloudBase 技能位于本技能旁边；使用本地相对路径，如 `../auth-tool-cloudbase/SKILL.md`。
12. 如果引用的 sibling 技能文件在当前环境缺失，要求用户安装完整 CloudBase 插件（或缺失技能）；不要把远程 skill 或 protocol markdown 通过 HTTP 抓取进 agent 上下文。
13. 澄清实体集合：从请求中抽取业务实体、归属关系和关系基数。
14. 除非用户明确要求更多，优先保持 3-5 个核心实体。
15. 先建模再生成：先起草 Mermaid `classDiagram` 内容。
16. 在调用建模工具前，先校验名称、字段类型和关系。
17. 读取/列出已有模型：使用 `manageDataModel(action="list"|"get"|"docs")`。
18. 创建新模型：使用 `modifyDataModel`（兼容名称；仅创建）。
19. 谨慎发布：优先以未发布或草稿式意图创建。
20. 只有在检查字段名、必填约束和关系方向后，再发布模型。
21. Mermaid 命名：类名用 PascalCase。
22. Mermaid 命名：字段名用 camelCase。
23. 将中文业务描述转换为清晰英文标识符。
24. 必要时保持枚举值可读。
25. 类型映射：text -> `string`。
26. 类型映射：number -> `number`。
27. 类型映射：boolean -> `boolean`。
28. 类型映射：enum -> `x-enum`。
29. 类型映射：email -> `email`。
30. 类型映射：phone -> `phone`。
31. 类型映射：URL -> `url`。
32. 类型映射：image -> `x-image`。
33. 类型映射：file -> `x-file`。
34. 类型映射：rich text -> `x-rtf`。
35. 类型映射：date -> `date`。
36. 类型映射：datetime -> `datetime`。
37. 类型映射：region -> `x-area-code`。
38. 类型映射：location -> `x-location`。
39. 类型映射：array -> `string[]` 或其他明确数组类型。
40. 仅对用户明确标记为必填的字段使用 `required()`。
41. 仅对明确唯一性需求使用 `unique()`。
42. 对面向人的标签字段使用 `display_field()`。
43. 给重要字段添加简洁的 `<<description>>` 注释。
44. 关系标签要绑定实际字段名，而不是模糊业务描述。
45. 按最小示例组织 Mermaid 模型：`class User` 含 `username: string`、`email: email`、`display_field() "username"`、`required() ["username", "email"]`、`unique() ["username", "email"]`；`class Order` 含 `orderNo: string`、`totalAmount: number`、`userId: string`、`display_field() "orderNo"`、`unique() ["orderNo"]`；关系写作 `Order "n" --> "1" User : userId`；用 `note for` 标注中文名。
46. 读取已有模型时，在创建相关模型、检查命名一致性或评估已有模型定义之前使用。
47. 创建模型时，向 `modifyDataModel` 传入完整的 `mermaidDiagram`。
48. 创建模型时，使用 `action="create"` 表示创建新模型。
49. 创建模型时，做出有意识的发布决策。
50. 创建模型时，明确当前工具不支持更新已有模型结构。
51. 最佳实践：除非用户明显受益于模型优先设计，否则优先直接 SQL。
52. 保持首版模型小而可审查。
53. 将业务实体与仅实现用的辅助字段分开。
54. 发布前校验关系方向和归属关系。
55. 建模后，如需实际 MySQL SQL/表工作，交给 `relational-database-mcp-cloudbase`；如需 PostgreSQL / CloudBase PG 表，交给 `postgresql-development-cloudbase`。
56. 最小检查清单：确认确实需要 Mermaid 建模。
57. 最小检查清单：先列出核心实体和关系。
58. 最小检查清单：决定是新建模型还是更新模型。
59. 最小检查清单：除非用户明确要大型企业 schema，保持初始模型小。

适用边界 · 注意事项

• 不要用于简单 `CREATE TABLE`、`ALTER TABLE`、CRUD，或只需一两条 SQL、schema 小且清晰、用户未要求可视化模型的任务。
• 不要用于文档数据库 collection 设计、仅前端数据形状讨论且无建模需求，或把 SQL 表设计与 NoSQL 集合设计混在同一模型。
• 新环境、PostgreSQL / CloudBase PG / PG mode / `app.rdb()` / `queryPgDatabase` / `managePgDatabase` / RLS 场景改用 `postgresql-development`；不要未确定实体边界和归属关系就生成图，也不要未校验字段和关系就发布新模型。