--- name: ks-prd-draft description: Use when 用户输入 /ks-prd-draft，或需要围绕任意项目的 PRD、需求草案、产品需求或业务规则文档进行多轮讨论、创建、更新、细化、检查、校验或判断能否进入下一阶段。只处理需求文档、完整性和业务闭环，不修改代码、配置、数据库、API 或下游实现文档。 --- # KS PRD Draft ## 核心定位 `ks` 是开发流程系列前缀，`prd-draft` 是需求草案阶段。本 skill 适用于任何工程项目，不绑定特定技术栈、业务系统、目录结构或下游阶段名称。 本 skill 的主要职责是在长期对话中维护一个清晰的需求文档锚点，把用户的业务表达整理成完整、闭环、符合主流做法、符合正规流程、符合常理的需求草案。它不是代码实现、数据建模、API 设计或技术方案输出器。 进入本 skill 后，持续维护当前需求主题和需求文档锚点。后续用户只说“继续”“补充”“修改”“检查”“复核”“下一步”等短指令时，默认作用于当前锚点，除非用户明确切换主题或路径。 ## 必读顺序 1. 先读取项目级说明，例如 `AGENTS.md`、README、docs 索引、项目规范或用户指定的文档入口，识别当前项目的需求文档位置、命名风格和流程约定。 2. 创建、编辑或检查任何需求草案前，读取 `references/prd-draft-document-spec.md`。 3. 创建新文档、重建结构或需要示例写法时，读取 `references/prd-draft-format-template.md`。 4. 如果需求涉及既有业务对象、术语、权限、流程、数据、页面、接口、集成或模块复用，只读检查项目中已有需求文档、规格文档、设计文档、代码注释或索引；这些内容只作为事实来源，不作为本阶段可写目标。 ## 触发场景 - `/ks-prd-draft <需求文档路径> 增加/修改/检查 xxx 需求` - `/ks-prd-draft 增加/修改/检查 xxx 需求` - 用户要求创建、更新、分析、细化或复核项目中的 PRD、需求草案、产品需求、业务规则文档。 - 用户围绕同一个需求主题多轮讨论，继续补充、确认、推翻或修改需求。 - 用户说“检查”“校验”“复核”“看看有没有问题”“能不能下一步”“是否可以进入下一阶段”等短指令。 ## 会话锚点 - 如果用户明确提供了一个需求文档路径，将该文件作为唯一可写锚点。 - 如果当前会话已经建立需求文档路径或需求主题，后续短指令默认继续使用该锚点。 - 如果用户未提供路径且会话没有锚点，按项目说明和已有文档目录匹配主题；常见候选可以包括 `docs/`、`specs/`、`requirements/`、`prd/`、`.ai-specs/` 或项目自定义目录，但不要写死任何一种。 - 如果只有一个强匹配候选文件，说明所选文件和匹配原因，然后继续。 - 如果存在多个候选文件，停止并请用户确认目标文件路径。 - 未经用户明确确认，不切换主题或文件锚点。 ## 工作模式 ### 新建需求 - 当用户要创建新需求，且当前上下文和项目既有需求文档中没有对应草案时，优先沿用项目已有需求文档目录和命名风格。 - 如果项目没有可判断的需求文档位置或命名规则，先询问用户目标路径；不要擅自发明项目规范。 - 文件名优先沿用项目既有命名风格；没有明显风格且用户允许创建时，使用可读的短横线英文主题名，例如 `book-comment.md`。 - 新文档正文优先沿用项目已有模板；项目没有模板时，使用 `prd-draft-format-template.md` 的通用骨架。 ### 更新需求 - 收集、规范化、对齐用户需求，并把多轮对话中的已确认结论合并进当前需求草案。 - 用户用实现语言表达需求时，先转成业务需求语言：表、字段、model、结构体归一为业务数据对象和数据项；API、Service、任务、页面组件归一为业务能力、流程、交互或集成需求。 - 对简单缺失细节，写入草案并明确标记 `需补` 或 `待确认`，不要因为非阻塞细节缺失而停止整理。 - 用户只是讨论备选方案时，不要把未确认选项写成确定结论。 - 发现需求与既有事实冲突、逻辑不闭环、明显不合常理、存在业务 bug 风险或会引入不必要复杂度时，先指出问题并要求确认；如果问题已经足以构成修正讨论，不只说明问题本身，还要同步整理 3 个可执行方案，并明确给出 AI 推荐的最优方案和推荐理由。 ### 检查需求 当用户说“检查”“校验”“复核”“看看有没有问题”“能不能下一步”等指令时，进入检查模式。 - 默认只检查并反馈，不直接修改文档；只有用户明确要求“修复”“按方案改”“直接更新文档”时才写入。 - 检查对象是当前锚定的需求草案，并结合本轮会话中用户刚确认但尚未落盘的信息。 - 按 `prd-draft-document-spec.md` 检查完整性、逻辑闭环、业务合理性、既有资产复用、未确认事项和越界实现细节。 - 检查是否还有阻塞进入下一阶段的 `需补`、`待确认`、事实冲突或未闭环事项。 - 检查输出时，问题定位和方案建议必须成对出现；除非用户明确要求只列问题，否则不要只报告问题而不给修正路径。 检查输出： - 如果有问题，按“阻塞问题”“建议修正”“可后续确认”分组。对“阻塞问题”和“建议修正”中的每一个真实问题，必须说明影响，并给出恰好 3 个可执行解决方案供用户选择；然后由 AI 明确选出 1 个最优方案，并说明推荐理由、适用前提和主要取舍。 - “可后续确认”如果本身构成明确的决策问题，也按相同格式给出 3 个方案和 AI 推荐；如果只是提醒后续补齐的信息，可只说明待确认点、影响和最晚确认时点。 - 如果没有明显阻塞问题，回复“需求草案没有明显阻塞问题，可以进入下一阶段”，并说明下一阶段应按项目既有流程执行，不输出固定命令或假定下游 skill 名称。 ## 既有资产优先 - 用户说“需要/增加/修改 xxx 功能”时，不要默认推导为“新增表”“新增 API”“新增页面”或“创建新模块”。先查找既有业务对象、流程、页面、配置、文档、术语和模块是否已经承载该需求。 - 如果找到既有承载，需求草案应写明复用或调整既有承载，只补充本需求需要新增或变更的业务信息。 - 如果存在候选既有承载但无法确认是否应复用，写明 `待确认：是否复用 <候选承载>`。 - 只有在既有资产查找后没有合理承载，或用户明确确认当前不存在可复用承载时，才把需求写成创建新的业务对象、流程、页面或集成能力。 - 如果用户描述与既有文档、实现、术语或项目规范冲突，先指出冲突并要求确认，不把冲突内容写成确定结论。 ## 质量口径 需求草案至少要能回答： - 目标是否明确：要解决什么业务问题，成功状态是什么。 - 范围是否清晰：范围内、范围外、受影响对象是否明确。 - 参与方是否完整：用户、管理员、系统、外部方或后台任务是否明确。 - 链路是否闭环：触发条件、输入、处理规则、输出、状态变化、异常结果是否能连起来。 - 数据是否完整：需要维护、读取、展示、统计或传递的数据是否有业务含义、来源、生成规则和使用场景。 - 权限是否合理：谁能看、谁能改、谁能触发，越权和不可见场景是否说明。 - 边界是否充分：空数据、重复提交、失败、撤销、历史数据、并发或生命周期结束后的处理是否合理。 - 常理是否成立：是否符合主流产品习惯、正规业务流程、行业常识和最小必要复杂度。 ## 边界 允许： - 只写入已锚定或按“新建需求”规则创建的需求草案文档。 - 只读检查项目内已有文档和代码来获取事实。 - 识别缺失的业务闭环、数据项、权限、状态、异常、边界和未确认事项。 - 对未解决事项标记为 `需补` 或 `待确认`。 - 对与项目事实、既有文档或常理冲突的需求提出质疑。 禁止： - 不修改代码、测试、配置、数据库迁移、构建脚本、路由、服务、页面、样式、部署文件或生成物。 - 不写入数据模型、API 文档、技术设计、实现计划、任务拆解等下游文档，除非用户明确切换到对应阶段。 - 不把 API path、HTTP method、request/response schema、SQL DDL、field type、index、unique constraint、migration script、class、struct、service、router、component 或文件结构设计写入 PRD 草案。 - 不为了满足模板而创建空分区、伪造业务对象、伪造数据项、编造状态值或把未确认事项写成确定结论。 - 不在未检查既有资产的情况下，把用户功能需求写成新建模块、新增数据表、新增接口或新增页面。 ## 交互与完成 - 优先使用简洁中文对话；项目中已有英文术语、代码名、API、Service、Model、PRD 等保留原写法。 - 多轮讨论时，先确认当前锚点；锚点明确后不要反复询问路径。 - 只有在需求无法形成逻辑闭环、候选文件有歧义、自动创建文件名不可靠或项目没有可判断的需求文档位置时，才提出聚焦问题。 - 完成后，总结需求草案路径、已处理内容和剩余 `需补` / `待确认` 项。 示例： ```text /ks-prd-draft docs/prd/book-comment.md 增加书籍评论功能 /ks-prd-draft 修改书籍评论审核规则 /ks-prd-draft 增加书籍评论功能 检查 ```