migoxlab System Design From PRD
将 PRD 转化为一份后端工程可评审、可拆解、可实施的系统设计文档。
这个 Skill 的目标是约束 Agent 以稳定、审慎、可追溯的方式完成设计推导。
使用场景
当用户提出以下需求时使用本 Skill：
- 根据 PRD 生成后端系统设计文档
- 将产品需求转成技术方案、接口设计、数据库设计
- 为一个功能编写后端设计文档或架构评审文档
核心原则
1. 先澄清，再设计
如果 PRD 缺失关键条件，先提出少量高影响问题, 并主动询问用户
优先澄清：
- 核心用户和使用场景
- MVP 范围和非目标
- 数据模型和生命周期
- 一致性要求
- 性能、并发、容量目标
- 外部系统依赖
- 兼容性要求
- 有歧义的业务逻辑
如果问题不会阻塞整体设计，可以继续设计，但必须在文档中标记为假设或开放问题。
2. 不编造产品事实
只能基于 PRD、用户补充信息、提问后的用户回答、现有代码库和已有文档进行设计，不要自行补全关键产品事实。
如果信息不足，必须显式写入：
- 假设
- 开放问题
- 需要产品确认的点
- 需要技术负责人确认的点
不要为了让文档看起来完整而虚构业务规则、数据字段、权限策略或性能目标。
3. 遵循现有工程上下文
一定要优先遵循当前会话上下文中已明确的需求和讨论结果
如果存在已有代码库、接口规范、数据库 schema、技术栈或团队约定，应优先遵循。
认证沿用现有 SSO，本文不新增登录/鉴权 API；如需求中涉及角色、资源权限、数据权限，必须单独设计
不要轻易引入新技术、新服务、新中间件或新架构模式。
引入任何重要技术组件时，必须说明：
- 为什么需要
- 替代方案是什么
- 不引入会有什么问题
- 运维、成本、复杂度影响是什么
4. 面向评审，而不是面向展示
输出文档应帮助工程师、Tech Lead、产品和测试发现问题。
好的设计文档应该暴露风险，而不是掩盖不确定性。
输出格式
默认使用 Markdown 格式输出。 注意：为了更清晰的表述设计意图，请尽量使用 Mermaid 语法生成相应的架构图、时序图或状态图等图表。
API 接口设计规范
【可选软依赖说明】：
为了保证各 Skill 能够独立复制和运行，本规范采用软依赖模式。在输出 API 设计时，请尝试读取同级目录下的 ../api-design-guidelines/SKILL.md 文件：
- 如果该文件存在：请务必严格遵循其中的 RESTful 规范（包括资源命名、HTTP 动词、状态码、分页格式等），并使用该技能中定义的API 文档输出模板来呈现接口。
- 如果该文件不存在：请使用你所知的通用 RESTful 标准进行设计，并以清晰易读的结构化文本或表格输出接口详情。
Mermaid 图使用规范
使用 Mermaid 时优先使用：
- flowchart TD 表示模块关系
- sequenceDiagram 表示调用链路
- stateDiagram-v2 表示状态流转
- erDiagram 表示实体关系
禁止事项
- 不要凭空创造 PRD 没有的业务规则
- 不要引入新中间件除非说明理由
- 不要把开放问题伪装成确定结论
- 不要只给概念图而缺少接口、数据和流程落地
- 不要输出只有展示价值、无法评审的方案