docs: refine PRD draft layering rules

SKILL.md

@@ -31,20 +31,38 @@ description: Use when 用户输入 /ks-prd-draft，或需要围绕任意项目
 ## 会话锚点
 
 - 如果用户明确提供了一个需求文档路径，将该文件作为唯一可写锚点。
+- 如果用户明确提供的是需求主题目录，先定位目录下唯一主草案：优先使用已有 `*-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/`。
+
 ## 工作模式
 
 ### 新建需求
 
 - 当用户要创建新需求，且当前上下文和项目既有需求文档中没有对应草案时，优先沿用项目已有需求文档目录和命名风格。
 - 如果项目没有可判断的需求文档位置或命名规则，先询问用户目标路径；不要擅自发明项目规范。
-- 文件名优先沿用项目既有命名风格；没有明显风格且用户允许创建时，使用可读的短横线英文主题名，例如 `book-comment.md`。
-- 新文档正文优先沿用项目已有模板；项目没有模板时，使用 `prd-draft-format-template.md` 的通用骨架。
+- 如果项目已有 `.ai-transition/prd-draft` 过渡区，且用户没有指定更具体的项目规范，按文档规范中的草案包结构创建或定位 `<topic-slug>-prd.md`。
+- 文件名优先沿用项目既有命名风格；没有明显风格且用户允许创建时，使用可读的短横线英文主题名，例如 `<topic-name>.md`。
+- 新文档正文优先沿用项目已有模板；项目没有模板时，按文档类型使用 `prd-draft-format-template.md` 的整篇文档模板或通用骨架。
 
 ### 更新需求
 
@@ -52,6 +70,7 @@ description: Use when 用户输入 /ks-prd-draft，或需要围绕任意项目
 - 用户用实现语言表达需求时，先转成业务需求语言：表、字段、model、结构体归一为业务数据对象和数据项；API、Service、任务、页面组件归一为业务能力、流程、交互或集成需求。
 - 对简单缺失细节，写入草案并明确标记 `需补` 或 `待确认`，不要因为非阻塞细节缺失而停止整理。
 - 用户只是讨论备选方案时，不要把未确认选项写成确定结论。
+- 同一轮编辑、同一次未提交 diff 或同一轮对话推演中，临时方案被提出后又被否定时，不把它写成“不要”“不支持”“取消”等否定事实；直接移除临时方案，只保留最终确认需求。只有该方案已经出现在已提交、已确认、已评审或已对外同步的基线版本中，或需要防止需求外溢时，才写入变更说明、范围外或决策记录。
 - 发现需求与既有事实冲突、逻辑不闭环、明显不合常理、存在业务 bug 风险或会引入不必要复杂度时，先指出问题并要求确认；如果问题已经足以构成修正讨论，不只说明问题本身，还要同步整理 3 个可执行方案，并明确给出 AI 推荐的最优方案和推荐理由。
 
 ### 检查需求
@@ -60,7 +79,7 @@ description: Use when 用户输入 /ks-prd-draft，或需要围绕任意项目
 
 - 默认只检查并反馈，不直接修改文档；只有用户明确要求“修复”“按方案改”“直接更新文档”时才写入。
 - 检查对象是当前锚定的需求草案，并结合本轮会话中用户刚确认但尚未落盘的信息。
-- 按 `prd-draft-document-spec.md` 检查完整性、逻辑闭环、业务合理性、既有资产复用、未确认事项和越界实现细节。
+- 按 `prd-draft-document-spec.md` 检查完整性、逻辑闭环、业务合理性、既有资产复用、文档引用路径、未确认事项和越界实现细节。
 - 检查是否还有阻塞进入下一阶段的 `需补`、`待确认`、事实冲突或未闭环事项。
 - 检查输出时，问题定位和方案建议必须成对出现；除非用户明确要求只列问题，否则不要只报告问题而不给修正路径。
 
@@ -89,6 +108,8 @@ description: Use when 用户输入 /ks-prd-draft，或需要围绕任意项目
 - 数据是否完整：需要维护、读取、展示、统计或传递的数据是否有业务含义、来源、生成规则和使用场景。
 - 权限是否合理：谁能看、谁能改、谁能触发，越权和不可见场景是否说明。
 - 边界是否充分：空数据、重复提交、失败、撤销、历史数据、并发或生命周期结束后的处理是否合理。
+- 引用是否可迁移：关联文档是否使用相对当前文档的路径或语义引用，是否避免用户机器绝对路径和项目根目录绑定路径。
+- 分层是否清楚：业务逻辑方案是否写成主草案规则，技术实现方案是否只作为参考、决策背景或业务约束来源。
 - 常理是否成立：是否符合主流产品习惯、正规业务流程、行业常识和最小必要复杂度。
 
 ## 边界
@@ -108,6 +129,7 @@ description: Use when 用户输入 /ks-prd-draft，或需要围绕任意项目
 - 不把 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 的确定需求；只能转译为业务约束或放入参考材料、决策记录。
 
 ## 交互与完成
 
@@ -119,8 +141,8 @@ description: Use when 用户输入 /ks-prd-draft，或需要围绕任意项目
 示例：
 
 ```text
-/ks-prd-draft docs/prd/book-comment.md 增加书籍评论功能
-/ks-prd-draft 修改书籍评论审核规则
-/ks-prd-draft 增加书籍评论功能
+/ks-prd-draft docs/prd/<topic-name>.md 增加 <主题> 需求
+/ks-prd-draft 修改 <主题> 规则
+/ks-prd-draft 增加 <主题> 需求
 检查
 ```