ks-prd-draft/SKILL.md

name, description

name	description
ks-prd-draft	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、需求草案、产品需求、业务规则文档。
• 用户围绕同一个需求主题多轮讨论，继续补充、确认、推翻或修改需求。
• 用户说“检查”“校验”“复核”“看看有没有问题”“能不能下一步”“是否可以进入下一阶段”等短指令。

会话锚点

• 如果用户明确提供了一个需求文档路径，将该文件作为唯一可写锚点。
• 如果用户明确提供的是需求主题目录，先定位目录下唯一主草案：优先使用已有 *-prd.md；没有时再按项目既有约定使用 prd.md；新建草案包时使用 <topic-slug>-prd.md。
• 如果当前会话已经建立需求文档路径或需求主题，后续短指令默认继续使用该锚点。
• 如果用户未提供路径且会话没有锚点，按项目说明和已有文档目录匹配主题；常见候选可以包括 docs/、specs/、requirements/、prd/、.ai-specs/ 或项目自定义目录，但不要写死任何一种。
• 如果只有一个强匹配候选文件，说明所选文件和匹配原因，然后继续。
• 如果存在多个候选文件，停止并请用户确认目标文件路径。
• 未经用户明确确认，不切换主题或文件锚点。

文档组织原则

• 具体文档结构、草案包目录、引用路径和模板选择以 references/prd-draft-document-spec.md 为准；创建或重建正文时再读取 references/prd-draft-format-template.md。
• 主草案始终是唯一需求口径，写业务目标、范围、流程、业务规则、数据含义、权限、边界、异常和待确认项。
• decisions.md 只记录确认结论、冲突、取舍、待确认事项和覆盖记录；references/ 只存放外部协议、客户材料、性能建议、接口草稿或来源摘录等参考材料。
• 关联文档必须使用相对当前文档的可迁移路径；不要把用户机器绝对路径写入 PRD 正文。
• 项目已有同类文档风格时优先沿用；没有项目风格时，再按模板选择流程文档、要求文档或通用骨架。

方案分层判定

• 当用户讨论“方案”“逻辑方案”“性能方案”“优化方案”时，先判断内容是在定义业务判定，还是在指定实现手段。
• 业务逻辑方案必须进入主草案：触发条件、开始和结束边界、有效和失效口径、状态流转、分支异常、成功失败结果、验收口径。例如“同一连接轮次如何开始、结束、失效”属于业务判定，不应留给下游自由解释。
• 技术实现方案不得写成主草案的确定需求：具体中间件、缓存、队列、索引、部署形态、服务内存状态、任务调度、代码结构等只可作为 references/ 参考来源或 decisions.md 决策背景。
• 主草案可以引用参考材料，但正文必须写成业务目标和约束，例如响应时限、高峰期可用性、一致性、重复提交处理、异常恢复结果；不要写“使用某技术实现”。
• 如果一个方案同时包含业务判定和实现手段，拆开处理：业务判定进入主草案，取舍背景进入 decisions.md，实现建议摘要进入 references/。

工作模式

新建需求

• 当用户要创建新需求，且当前上下文和项目既有需求文档中没有对应草案时，优先沿用项目已有需求文档目录和命名风格。
• 如果项目没有可判断的需求文档位置或命名规则，先询问用户目标路径；不要擅自发明项目规范。
• 如果项目已有 .ai-transition/prd-draft 过渡区，且用户没有指定更具体的项目规范，按文档规范中的草案包结构创建或定位 <topic-slug>-prd.md。
• 文件名优先沿用项目既有命名风格；没有明显风格且用户允许创建时，使用可读的短横线英文主题名，例如 <topic-name>.md。
• 新文档正文优先沿用项目已有模板；项目没有模板时，按文档类型使用 prd-draft-format-template.md 的整篇文档模板或通用骨架。

更新需求

• 收集、规范化、对齐用户需求，并把多轮对话中的已确认结论合并进当前需求草案。
• 用户用实现语言表达需求时，先转成业务需求语言：表、字段、model、结构体归一为业务数据对象和数据项；API、Service、任务、页面组件归一为业务能力、流程、交互或集成需求。
• 对简单缺失细节，写入草案并明确标记 需补 或 待确认，不要因为非阻塞细节缺失而停止整理。
• 用户只是讨论备选方案时，不要把未确认选项写成确定结论。
• 同一轮编辑、同一次未提交 diff 或同一轮对话推演中，临时方案被提出后又被否定时，不把它写成“不要”“不支持”“取消”等否定事实；直接移除临时方案，只保留最终确认需求。只有该方案已经出现在已提交、已确认、已评审或已对外同步的基线版本中，或需要防止需求外溢时，才写入变更说明、范围外或决策记录。
• 发现需求与既有事实冲突、逻辑不闭环、明显不合常理、存在业务 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 草案。
• 不为了满足模板而创建空分区、伪造业务对象、伪造数据项、编造状态值或把未确认事项写成确定结论。
• 不在未检查既有资产的情况下，把用户功能需求写成新建模块、新增数据表、新增接口或新增页面。
• 不把 Redis、MQ、缓存、索引、分库分表、异步任务等性能或实现方案写成 PRD 的确定需求；只能转译为业务约束或放入参考材料、决策记录。

交互与完成

• 优先使用简洁中文对话；项目中已有英文术语、代码名、API、Service、Model、PRD 等保留原写法。
• 多轮讨论时，先确认当前锚点；锚点明确后不要反复询问路径。
• 只有在需求无法形成逻辑闭环、候选文件有歧义、自动创建文件名不可靠或项目没有可判断的需求文档位置时，才提出聚焦问题。
• 完成后，总结需求草案路径、已处理内容和剩余 需补 / 待确认 项。

示例：

/ks-prd-draft docs/prd/<topic-name>.md 增加 <主题> 需求
/ks-prd-draft 修改 <主题> 规则
/ks-prd-draft 增加 <主题> 需求
检查