# Request To Prd > Use when converting an existing request需求文档 into a structured PRD through AI drafting, user revision, iterative completion, boundary tracking, and convergence checking. Requires a request需求文档 as the input source; do not use for writing a PRD from a blank slate. - Skill: `spaceyuan/request-to-prd` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add spaceyuan/request-to-prd` - Raw SKILL.md: https://api.skillmd.com/api/skills/spaceyuan/request-to-prd/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: spaceyuan (https://skillmd.com/u/spaceyuan) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/spaceyuan/request-to-prd --- # Request To PRD ## Purpose Use this skill to convert an existing request需求文档 into a structured PRD through co-creation between the user and AI. The PRD is not generated through long-form Q&A from scratch. The default collaboration mode is: - AI drafts first - User revises and adds business judgment - AI reasons, completes, and tracks gaps - User corrects scope and priority - AI continues improving the same PRD - The document converges into a final PRD ## Required Input / 前置输入 The user must provide a request需求文档 before PRD generation begins. The request document / request需求文档 is the initial input source for the PRD. It may be incomplete, informal, or fragmented, but it must contain at least one valid input signal / 有效输入信号 that can serve as the starting point for PRD creation. Valid input signals / 有效输入信号 include but are not limited to: - Business goal - User problem - Product idea - Feature request - Scenario description - Existing requirement notes - Stakeholder request The request document / request需求文档 does not need to include all of these signals. If it contains at least one of them, AI should first generate the PRD foundation / PRD 基础骨架 and mark missing information as pending confirmation / 待确认 or AI assumptions / AI 假设. If no request document / request需求文档 is provided, do not directly generate a formal PRD. Ask the user to provide the request需求文档, or offer to help them first organize their rough ideas into a request document. ## Core Principles / 核心原则 PRD is a structured product requirements document / 结构化产品需求文档. User stories / 用户故事 are an important way to express key scenarios / 关键场景, user goals / 用户目标, system behavior / 系统行为, and acceptance criteria / 验收标准, but they are not the only carrier of PRD content. The PRD should also include background, goals, users, roles, terms, scope, business process, rules, exceptions, dependencies, integration notes, modules, and convergence state. AI should prioritize writing and improving the PRD draft instead of asking many questions. Questions should only be raised when the missing information affects scope, product decisions, core flow, user-visible behavior, or acceptance criteria. ## Standard Workflow / 标准工作流 ### Step 1: Read The Request / 读取 Request 需求文档 Analyze the provided request需求文档 and extract: - Business background - User goals - Target users - Stakeholders or roles - Explicit requirements - Implicit requirements - Core scenarios - Business process clues - Constraints - Risks - Missing information Do not stop at this step for broad questioning. First build a useful PRD draft from available information. ### Step 2: Generate The PRD Foundation / 生成 PRD 基础骨架 Create the first PRD draft using the standard PRD structure. The first draft should include: - Structured PRD skeleton - Initial business summary - Initial scope boundary - Known information - AI-inferred information - Pending confirmations - Initial user stories or key scenarios - Initial module and requirement list - Initial convergence state This version is a co-editable foundation, not a final PRD. ### Step 3: User Revises And Adds Content / 用户补充与修改 The user may add, delete, rewrite, correct, or redirect any part of the PRD. Treat user edits as the highest-priority source of truth. When user edits conflict with AI assumptions, update the PRD according to user edits and adjust related sections, including scope, stories, rules, assumptions, open questions, and convergence state. ### Step 4: AI Reasons And Completes / AI 推理与补全 Based on the user's revised PRD, AI should continue improving the same document. Focus on completing: - Business logic - User-visible behavior - Page states - Prompts and copy if relevant - Global rules - Role and permission differences - Exceptions - Boundary cases - Dependencies - Assumptions - Acceptance criteria - Requirement list Do not expand the product scope arbitrarily. Any new content must be traceable to the request document, user edits, business flow, or an explicitly marked assumption. ### Step 5: Continue Iteration / 持续迭代 Repeat user revision and AI completion until the PRD converges. Each iteration should improve the same PRD. Do not regenerate a new structure unless the user asks for restructuring. Keep the document structure stable so the user can edit and compare versions easily. ### Step 6: Generate The Final PRD / 生成最终 PRD When the PRD reaches the convergence criteria, suggest that the document is ready for finalization. AI may recommend entering final PRD mode, but the final decision belongs to the user. ## Standard PRD Structure / 标准 PRD 结构 Use the standard PRD template / 标准 PRD 模板 in: `assets/standard-prd-template.md` Use this structure by default. Adapt only when the request context clearly requires a different structure. ## Information State Management Always distinguish between confirmed information, AI inference, and pending confirmation. Maintain these sections or equivalent labels inside the PRD: - 已确认信息 - AI 推断信息 - 待确认信息 - 已废弃假设 When the user confirms, modifies, or rejects an item, update its state immediately. ## Question Priority Rules / 问题优先级规则 Do not turn PRD creation into a long questionnaire. Only ask questions when the missing information affects one of the following: - Product scope / 产品范围 - Core business process / 核心业务流程 - Key user use cases / 用户核心用例 - User-visible behavior / 用户可见行为 - Role or permission decision / 角色或权限决策 - Acceptance criteria / 验收标准 - Multiple mutually exclusive product choices / 多个互斥产品方案 - Obvious business conflict / 明显业务冲突 For other uncertain details, write a reasonable assumption into the PRD and mark it as pending confirmation. Ask the fewest necessary questions per iteration. ## Boundary Mechanism / 边界机制 Every PRD must maintain an explicit boundary layer. The boundary layer should include: - In Scope / 范围内: what this PRD includes - Out of Scope / 范围外: what this PRD explicitly excludes - Pending Scope Decisions / 待裁定范围: items that may or may not belong to this PRD - Assumptions / 假设: assumptions currently used by the PRD - Dependencies / 依赖: external conditions required for delivery - Open Questions / 未决问题: unresolved items that may affect delivery or acceptance When adding new content, check whether it belongs to In Scope. If unsure, place it under Pending Scope Decisions instead of silently expanding the scope. ## Convergence Mechanism / 收敛机制 The PRD should not iterate endlessly. Use convergence criteria / 收敛标准 to determine whether it is ready for review / 可进入评审 or finalization / 可进入定稿. The PRD is close to convergence when: - The business process is understandable and mostly complete - Core requirements are covered in the module list or user stories - Scope boundary is clear - Key global rules are documented - Major exceptions and boundary cases are covered - Each core requirement has acceptance criteria or equivalent verification conditions - High-priority open questions / 高优先级未决问题 are resolved or explicitly downgraded to assumptions / 假设 - There are no obvious conflicts, duplicates, or scope drift / 范围漂移 - A new iteration does not introduce new core questions AI can recommend that the PRD is ready for finalization, but the user decides whether to finalize. ## Queryable Boundary And Convergence Status / 可查询的边界与收敛状态 The user may ask for PRD status at any time. Trigger this mode when the user asks things like: - 当前边界是什么 - 哪些内容在范围内 - 哪些内容不在范围内 - 现在收敛到什么程度 - 是否可以定稿 - 当前最大风险是什么 - 哪些问题还没解决 - 哪些故事或需求还不完整 When triggered, output the current PRD status panel. ## PRD Status Panel / PRD 状态面板 Use this format when reporting boundary or convergence state: ```markdown ## 当前 PRD 状态 版本阶段： 当前收敛等级： 是否建议进入评审或定稿： ## 边界状态 In Scope： Out of Scope： 待裁定范围： ## 收敛评分 范围覆盖度： 边界清晰度： 主流程完整度： 功能需求完整度： 用户故事完整度： 异常覆盖度： 验收完备度： 依赖明确度： ## 未决问题 1. 2. 3. ## 当前最大风险 ## AI 建议的下一步 ``` ## Status Scale / 状态等级 Use a 0 to 4 scale for convergence dimensions. ```txt 0 = 未识别 1 = 已识别 2 = 已补充 3 = 已确认 4 = 已收敛 ``` Overall convergence levels: ```txt 低：仍处于结构搭建阶段，主流程或范围尚不稳定 中：主流程基本成立，但需求、边界、验收仍需补充 高：核心内容基本完整，仅剩少量待确认问题 可定稿：范围、需求、规则、异常、验收均已清晰，用户可裁定最终输出 ``` ## User Story Guidance User stories are useful for key scenarios, but they are not the only PRD structure. Use user stories to describe: - User role - User goal - Trigger condition - Main flow - User-visible behavior - System response - Boundary constraints - Exceptions - Acceptance criteria Do not force every global rule, integration note, or module list item into a story if a structured PRD section communicates it more clearly. ## System Integration Guidance The system integration section should stay at the product requirement level. Include: - Integration object - Business trigger - Data interaction summary - Failure behavior - User-visible impact - Acceptance impact Avoid deep technical design details unless they directly affect product behavior, user experience, business rules, or acceptance criteria. ## PlantUML Diagram Examples / PlantUML 图例 PlantUML diagram examples / PlantUML 图例 are optional supporting assets. Use them only when the user explicitly asks for diagrams, flowcharts, state diagrams, sequence diagrams, or visual process modeling. Do not generate PlantUML diagrams by default. Reference examples in: `assets/plantuml-examples.md` ## Functional Module Template / 功能模块模板 When describing a single functional module / 单一功能模块, use the functional module template / 功能模块模板 in: `assets/functional-module-template.md` The template is a depth guide / 深度参考, not a mandatory full expansion / 强制完整展开. Do not fill every section for every module by default. AI should choose Light / 轻量, Standard / 标准, or Deep / 深度 description based on module complexity / 模块复杂度, business risk / 业务风险, and user requirements / 用户要求. For core modules, include Value Statement / 价值陈述, Preconditions / 前置条件, Happy Path / 正常操作流程, Exception Handling / 异常处理, and Acceptance Criteria / 验收标准. For lightweight modules, use a compressed version while preserving module goal / 模块目标, preconditions / 前置条件, core behavior / 核心行为, and acceptance criteria / 验收标准. ## AI Behavior Rules / AI 行为规则 - Start from the request document / request需求文档, not from a blank page. - Generate a PRD draft / PRD 草稿 before asking broad questions. - Keep the PRD structure stable / PRD 结构稳定 across iterations. - Treat user edits as the highest-priority source of truth / 事实来源. - Mark uncertainty / 不确定性 instead of hiding it. - Maintain boundary / 边界, assumptions / 假设, open questions / 未决问题, and convergence state / 收敛状态 continuously. - Ask only high-impact questions. - Do not silently expand scope / 范围. - Do not mix detailed technical design into the PRD unless it affects product behavior or acceptance. - Recommend finalization only when convergence criteria / 收敛标准 are met.