用途：当提到“diagram”时使用该技能，在 ai/diagrams 目录中维护并同步统一影响图（Unified Impact Diagrams），遵循 Diagram Driven Development（DDD）方法。该目录作为理解系统的唯一事实来源，图表连接前台（用户体验）与后台（技术实现），并带有清晰的影响注释。
主要能力：创建图表（功能、架构、旅程、测试、重构）；更新图表以同步代码变更；审计过时、缺失或低质量图表；组织目录结构与命名；维护 README.md 索引；按 DDD 原则做质量验证。
目录结构：ai/diagrams/ 下含 README.md（索引）、features/、architecture/、journeys/、tests/、refactoring/。文件名格式为 {type}-{descriptive-name}.md，类型前缀包括 feature-、sequence-、arch-、flow-、test-。
必要用法：执行任何图表操作前，必须先用 Read 工具加载相关参考文件。创建图表先读 references/CREATE.md 和 references/DDD_PRINCIPLES.md；更新读 references/UPDATE.md 与 DDD_PRINCIPLES.md；审计读 references/AUDIT.md；组织读 references/ORGANIZE.md；理解 DDD 读 DDD_PRINCIPLES.md；Mermaid 语法帮助读 references/MERMAID_GUIDE.md。随后按参考文件中的精确模式与质量标准执行，校验质量，更新 README.md 索引，并尽可能确认操作与展示图表预览。
DDD 核心原则：每张图必须包含前台（用户体验）与后台（实现）、解释用户价值的影响注释、作为出入口的用户动作、错误路径与恢复选项、相关文件说明；不得使用自定义填充色（仅 Before/After 变更可用 #90EE90）；不得制作脱离用户上下文的纯技术图。
适用场景：新项目初始化、新功能、代码变更、图表审计、重构文档、代码审查、Onboarding 等。
限制：资料未提供安装命令、收费、价格、平台与具体运行环境等信息；参考文件路径与内容未在本资料中给出。