prd-architectlisted

# PRD 架构师（prd-architect） ## 中文速查 - 中文名��PRD 架构师 / 需求文档起草 - 英文稳定名：`prd-architect` - 你可以这样叫我：`帮我写 PRD`、`帮我选 PRD 模板`、`把这个需求整理成 PRD`、`这个需求该用哪种 PRD`、`PRD 里补 Draw.io 流程图` - 适合：需求还在成型，需要判断 PRD 类型、当前成熟度、模板资产和后续 UI / handoff 承�� - 不适合：已有完整 PRD 要评审时改用 `prd-review`；只要正式 UI mockup 时改用 `ui-mockup-desktop-workbench`；直接编码不触发 ## Overview 这个 Skill 负责把产品想法组织成结构匹配的 PRD。它不是固定展开重型模板，而是： 1. 先判断上游输入是否足够成熟。 2. 再选择 `PRD-lite / PRD-standard / PRD-ai-native` 其中��个模板资产。 3. 只加载本轮需要的附加资产；页面型 PRD 自动激活 mockup handoff 和 UI 证据链。 4. 写出与当前阶段一致的 PRD，并区分本地草��内容和可发布正文。 5. 生成文件时尽量运行 PRD shape 自检，避免把初版 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 模板资产。 4. 按需加载 mockup、Draw.io 或 handoff 资产。 5. 组织 PRD 正文、待确认项和下一步建议。 6. 在生成到文件时运行可用的确定性检查。 7. 当 PRD 包含用户可见界面时，编排 `ui-mockup-desktop-workbench`，在同一交付中完成 HTML、关键截图和正文回填。 它不负责： - 直接决定 UI 视觉细节。 - 把 standalone HTML 当成生产代码；正式视觉实现由 `ui-mockup-desktop-workbench` 负责，但本 Skill 负责触发、收口和验收这条交付链。 - 直接开始编码。 - 把核心规则外包给单独 guide 再让用户自己跳转理解。 - 在用户只要“初版 PRD”时展开接口字段、TypeScript、JSON schema、adapter 或 metadata 结构。