reaperhero 架构图
概述
当用户需要的是架构图，而不是纯文字说明时，使用这个 skill。默认交付物是一组双图：一张物理架构图，一张部署架构图。
输出约定
除非用户明确排除，否则始终同时提供：
- 一张
物理架构图 - 一张
部署架构图
每张图都应当能够独立阅读，命名保持一致，结构清晰。如果输入资料不完整，应做最小且合理的假设，并明确标注这些假设，同时保持两张图内部一致。
推荐格式
- 文字版架构图默认优先使用 Mermaid
- 除非结构明显更适合纵向排布，否则使用
flowchart LR - 节点标签中如果有空格或标点，使用带引号的写法
- 节点文字应尽量简短，保证可读性
- 需要时按区域、主机、集群、环境或网络边界分组
- 明确表示流量方向和关键依赖关系
如果用户要求输出图片文件，先草拟 Mermaid 结构，再生成图片。最终输出前要检查每个标签是否放得进节点、是否正常换行、是否存在重叠。
图片输出规则
当任务需要输出图片文件时，除非用户明确指定其他要求，否则遵循以下默认规则：
- 优先使用
PNG - 图片默认保存到
/Users/edy/Downloads/AI/images - 保存前如果目录不存在，先创建目录
- 文件名使用有语义的英文名，必要时附加日期或时间戳避免覆盖
- 在回复中始终返回图片的绝对路径
- 图片中不要加入来源说明或参考资料备注
对于带框和文字的架构图：
- 所有文字都必须在框内
- 默认开启自动换行
- 避免文字重叠、截断、过密、压线或超出画布
在输出任何已经排版完成的图片前，必须先自检。如果发现文字过密、重叠、越界或难以辨认，先调整字号、行高、卡片高度、间距或画布尺寸，再输出最终结果。
图的职责
物理架构图
这张图用于表现系统由什么组成，以及这些组件“位于哪里”。
应优先包含这些与物理或基础设施相关的元素：
- 用户、客户端或边缘入口
- CDN、WAF、负载均衡、网关或 Ingress
- VPC、子网、可用区、机房、办公室、机架、主机、虚拟机或裸金属分组
- Kubernetes 集群、节点或服务器组
- 数据库、缓存、消息队列、对象存储和第三方依赖
- 关键网络链路与安全边界
重点是拓扑和位置关系，不要在这张图里堆太多发布流程细节。
部署架构图
这张图用于表现软件是如何部署、组织和运行的。
应优先包含这些与部署相关的元素：
- 环境，如开发、测试、预发、生产
- 区域、集群、命名空间、节点池或宿主机
- 可部署单元，如服务、Pod、容器、Job 或 Sidecar
- 部署控制器、CI/CD 路径、镜像仓库、配置源或密钥源
- 对运行时真正重要的服务间调用关系
- 当高可用或扩缩容会影响部署理解时，也应表示出来
重点是运行时落位和发布结构。除非某些物理细节会影响部署理解，否则不要机械重复物理图里的全部内容。
工作流
1. 提取架构名词
优先识别：
- 流量入口
- 核心服务
- 数据存储
- 基础设施边界
- 环境
- 部署目标
- 外部系统
在画图前先统一命名。同一个组件尽量只保留一个标准名称。
2. 区分物理视角与部署视角
对每个元素都先判断：
- 它更偏向“系统位于哪里”或“跨越了什么网络边界”
- 还是更偏向“软件如何被打包、部署、扩缩容和发布”
只有在确实有助于理解时，才让同一个概念同时出现在两张图里。
3. 降低杂乱度
- 如果多个节点在当前抽象层级上是等价的，可以合并
- 省略对当前目标没有帮助的实现细节
- 一条清晰的连线优先于多条冗余连线
- 每张图只保留最小但真实的系统切片
4. 标注假设
当信息不足时，在图后补一个简短的 假设说明 列表。保持短小、具体、可核对。
质量标准
在最终输出前，检查以下内容：
- 两张图都已提供
- 两张图中的命名保持一致
- 箭头方向清晰
- 需要强调的网络边界或环境边界已体现
- 关键数据存储和外部依赖没有脱离上下文悬空出现
- 部署图体现了可部署单元，而不是简单复制物理图的盒子
- 物理图体现了拓扑，而不是只列服务名
提示词示例
使用 $architecture-diagrams 绘制当前系统，并同时输出物理架构图和部署架构图。使用 $architecture-diagrams，基于这份服务清单和部署说明输出两张架构图。使用 $architecture-diagrams，把这份 README 转成物理架构图和部署架构图。
资源
- 当系统规模较大、输入较混乱或抽象层级不清晰时，读取 references/diagram-rules.md