prd-architectlisted

# PRD 架构师（prd-architect） ## 中文速查 - 中文名：PRD 架构师 / 需求文档起草 - 英文稳定名：`prd-architect` - 你可以这样叫我：`帮我写 PRD`、`帮我选 PRD 模板`、`把这个需求整理成 PRD`、`这个需求该用哪种 PRD`、`PRD 里补 Draw.io 流程图` - 适合：需求还在成型，需要先判断文档深度、PRD 类型、当前成熟度和后续 handoff 接口 - 不适合：已经有完整 PRD 要评审，改用 `prd-review`；只要 UI 线框或直接编码也不应触发 ## Overview 根据需求类型动态选择 PRD 模板，而不是固定套一套重型章节。 这个 skill 的职责是先定模板和阶段，再组织 PRD 的结构与承接关系。 ## Upstream Boundaries 不要把所有输入都直接写成 PRD。先判断上游是否已经成熟： - 问题、用户、目标或判断标准还不清楚：先转 `ai-collaboration-calibration` 做问题校准。 - 问题已确认，但具体方案、架构、计划或产品决策需要压力测试：先转 `grill-me`。 - PRD 中存在重大产品、技术、商业或平台选择，且缺少证据：先转 `decision-research`。 - 已有 PRD/handoff 只是要判断能否交付开发：转 `prd-review`，由它给 readiness verdict。 - PRD 和 UI 规范都已确认，用户要正式桌面端页面 mockup：转 `ui-mockup-desktop-workbench`。 `prd-architect` 可以根据上游输出起草或修订 PRD，但不自我批准 `Ready for writing-plans`。 ## Responsibilities 这个 skill 负责： 1. 判断需求复杂度 2. 判断是否属于 AI-native 需求 3. 在 `PRD-lite / PRD-standard / PRD-ai-native` 中做选择 4. 判断当前应该输出 `草稿 / 讨论中 / 已确认` 哪一阶段的 PRD 5. 组织输出结构 6. 保留必要的待确认假设 7. 决定下一步是继续深化 PRD，还是可以进入 UI / handoff 8. 让 PRD 内部直接包含后续可执行的图示 / UI 承接接口 9. 在 PRD 起草阶段生成可编辑 Draw.io 核心流程图或架构图，并把引用方式写进 PRD 它不负责： - 直接决定 UI 细节 - 生成正式桌面端多状态页面 mockup；这由 `ui-mockup-desktop-workbench` 负责 - 直接开始编码 - 用重型模板压扁所有需求 - 把核心规则外包给单独 guide 再让用户自己跳转理解 ### UI Mockup Handoff `prd-architect` 只负责把 PRD 中的 UI 承接接口写清楚，例如页面范围、关键状态、交互入口、验收口径、截图或轻量 mockup notes。 当 PRD 已经具备目标用户、页面范围、核心流程、关键状态、异常和验收标准，并且用户要正式桌面端真实页面 mockup 时，转交 `ui-mockup-desktop-workbench`。 如果 mockup 过程中暴露 PRD 缺口： - 文档结构或章节缺失：回到 `prd-architect` 补 PRD。 - 冲突、不可测试、验收缺失或