语言规则：本 skill 必须始终使用中文与用户交互。所有输出、提示、报告、文档均使用中文。
本 skill 旨在利用需求文档（可选结合 SDD 文档）驱动 AI 进行需求开发。通过需求分析 → 技术方案生成 → 人工校验 → 执行开发 → 人工修正 → 开发结果验证（按需）的流程，确保开发方案符合业务预期。
整个工作流程分为六个阶段：
REQ_ROOT，知识库上下文可选；支持本地 .md/.docx 文档；一旦创建 REQ_ROOT，必须同步创建 input_materials/ 并在 本需求标识.md 中维护输入资料清单）AI 自动 CR 与 测试 Case 验证 工具）核心理念：
sdd-builder 与 sdd-driven-dev 的衔接由用户人工决定，不做系统级强绑定references/company-frameworks/index.yaml，命中则优先加载公司说明，未命中再读 references/通用框架使用说明/REQ_ROOT 后必须创建 input_materials/ 统一归档用户提供的 PRD、接口文档等当用户说出以下任一关键词时，AI 应该识别并应用本 skill：
prompts/工具_feedback.md提交 AI 开发 workflow 反馈、上报 AI 开发流程问题、反馈这个开发 skill 的问题${KB_ROOT}/skill-feedback/YYYY-MM-DD_HH-mm-ss_feedback.md，无 KB_ROOT 时 ${REQ_ROOT}/feedback/YYYY-MM-DD_HH-mm-ss_feedback.mdprompts/工具_feedback.md，整理后写入本地文件，向用户展示路径与摘要prompts/工具_SDD缺口上报.md把缺口清单整理、上报缺口清单、整理SDD缺口${REQ_ROOT}/SDD缺口清单.md（有 KB_ROOT 时优先归档到 ${KB_ROOT}/sdd-gaps/，否则归档到 ${REQ_ROOT}/sdd-gaps/）prompts/工具_SDD缺口上报.md 执行归档prompts/工具_测试Bug分析总结上报.md分析测试提的 bug、测试提了 bug，帮我分析、总结测试 bug${REQ_ROOT}/测试Bug分析总结.md（有 KB_ROOT 时优先归档到 ${KB_ROOT}/bug-summaries/，否则归档到 ${REQ_ROOT}/bug-summaries/）prompts/工具_AI自动CR.md执行AI自动CR、帮我做AI自动CR、跑一下AI自动CR${REQ_ROOT}/SDD缺口清单.md，都必须立即读取 prompts/工具_SDD缺口上报.md 执行本地归档在任意阶段，若用户表达了以下类型的问题：
AI 必须：
这个问题看起来适合沉淀为 skill / 知识库反馈。是否需要我直接留档记录？prompts/工具_feedback.md 并执行本 skill 使用需求目录优先模型：
DEV_ROOT：当前 AI IDE 打开的业务工程（用于代码开发）REQ_ROOT：当前需求目录绝对路径（必需）KB_NAME：可选知识库工程名称KB_ROOT：可选知识库工程绝对路径KB_QUICK_REF：可选快速参考文档绝对路径路径约束：
REQ_ROOT 与可用上下文写入 本需求标识.mdsdd-driven-dev 的父目录）~/.cursor/skills/sdd-driven-dev/、.cursor/skills/sdd-driven-dev/prompts/阶段一：先确认 REQ_ROOT（必需），再按需确认知识库上下文（KB_NAME、KB_ROOT、KB_QUICK_REF，可选）。随后向用户索要本地 PRD 文档（.docx 或 .md）。一旦确定 REQ_ROOT，必须立即创建 ${REQ_ROOT}/input_materials/，写入 本需求标识.md。
阶段二：循环执行；优先使用 SDD 理解业务（强调但不强制），仍须进行代码探索；产出《需求分析报告》；凡不理解即暂停；结束前让人工确认改动点已全。
阶段三：全自动。技术方案须与改动点逐项对应。框架按需加载：若改动点涉及框架组件，先读 references/company-frameworks/index.yaml，扫描 trigger_keywords 是否命中，命中则优先加载公司说明，未命中则读取 references/通用框架使用说明/ 对应文档。禁止重复需求背景/需求理解等车轱辘话。
阶段四：人工驱动，主要介入点；对外文档生成后自动整理并归档 SDD缺口清单.md。
阶段五：执行开发（自动循环；同阶段三的框架加载规则；接口文档冲突时必须暂停；所有改动点、任务 T、验收标准 AC- 全部闭环后才生成开发报告）。
阶段六：开发结果验证（按需；先由用户选择工具，再执行 AI 自动 CR、测试 Case 验证 或两者组合，并统一生成验证报告与经验沉淀）。
用户触发流程
↓
[阶段一-01] 需求目录确认（必须先完成）
├─ 用户必须提供：REQ_ROOT（绝对路径，或确认默认创建位置）
├─ 可选提供：KB_NAME、KB_ROOT、KB_QUICK_REF（用于知识库增强）
└─ 记录为最高优先级上下文
↓
[阶段一] PRD 获取（无人工校准）
├─ 向用户索要本地 PRD 文档（.docx 或 .md）
├─ 方式 A：用户提供 PRD 路径 → AI 创建 REQ_ROOT 并归档
├─ 方式 B：用户自建 REQ_ROOT 并放入 PRD
├─ .md 直接读，.docx 转 Markdown + 图片分析
├─ 一旦目录确定，立即创建 input_materials/，记录 REQ_ROOT 为最高优先级上下文
└─ 写入 本需求标识.md
↓
[阶段二] 需求分析与代码探索（循环执行）
├─ PRD 逐句分析 + 代码探索，优先使用 SDD（不强制）
├─ 产出《需求分析报告》：改动点清单（含现状简述）
├─ 不理解或需确认 → 暂停向人工求助
└─ 人工确认改动点已全后进入阶段三
↓
[阶段三] 技术方案生成（自动执行）
├─ 框架按需加载：company-frameworks/index.yaml → 命中则加载公司说明 → 否则读通用框架说明
├─ 技术方案与改动点逐项对应
└─ 输出技术方案.md，完成后暂停
↓
[阶段四] 人工校验与技术方案迭代（人工驱动）← 主要介入点
├─ 展示技术方案 → 人工反馈 → 修正 → 循环直至确认
├─ 生成技术方案（对外）.md
├─ 自动整理 SDD缺口清单.md 并归档
└─ 再次确认是否开始开发（第二次确认）
↓
[阶段五] 执行开发（自动循环执行）
├─ 按技术方案逐改动点、逐任务推进
├─ 框架按需加载（同阶段三规则）
├─ 接口文档冲突时必须暂停人工确认
├─ 方案变更时必须回写技术方案并回到阶段四确认
└─ 所有改动点、T*、AC-* 全部闭环后生成开发报告.md
↓
[人工阶段] 人工修正与提交
├─ 切换业务分支、人工检查修正、git commit
└─ 确认可进入开发结果验证
↓
[阶段六] 开发结果验证（按需执行）
├─ 用户选择：AI 自动 CR / 测试 Case 验证 / 两者组合
├─ 生成 AI-CR报告.md / 测试Case验证报告.md
├─ 汇总生成 验证报告.md
└─ 经验沉淀（patterns / anti-patterns / regressions）
目标：将本地 PRD 文档转换为可用的 Markdown 形式，仅负责获取 PRD 信息，不做翻译与人工校准。
执行步骤：读取 prompts/01_阶段一_PRD获取.md。
目标：理解需求，区分「已实现」「待实现」「保持现状」，产出《需求分析报告》，列出所有改动点及现状简述。凡需确认即暂停；结束前须人工确认改动点已全。
执行步骤：读取 prompts/02_阶段二_需求分析与代码探索.md。
目标：根据需求分析报告 + 代码探索生成技术方案；有可用 SDD 时作为增强输入。技术方案与改动点逐项对应。框架按需加载（见上）。禁止车轱辘话。
执行步骤：读取 prompts/03_阶段三_技术方案生成.md 及 templates/技术方案模板.md。
目标：人工反馈 → 迭代优化技术方案 → 生成对外文档 → 整理并归档 SDD缺口清单 → 二次确认开始开发。
执行步骤：读取 prompts/04_阶段四_人工校验与技术方案迭代.md。
目标：按技术方案执行计划逐改动点、逐任务推进，持续维护 开发执行状态.md；方案变更时回写并回跳阶段四；所有 T / AC- 闭环后生成开发报告。
执行步骤：读取 prompts/05_阶段五_执行开发.md。
目标：人工修正完成后，按需执行 AI 自动 CR、测试 Case 验证 或两者组合，汇总验证报告，沉淀经验。
执行步骤：读取 prompts/06_阶段六_开发结果验证.md。
E-001、E-002...CODE（代码路径+行号+结论）、SDD（文档路径+章节+结论）、CMD（命令+输出摘要+结论）【推测】AC-xxx，再进入开发任务拆分阶段三和阶段四必须输出影响分析矩阵：调用链上下游、数据库与缓存、对外接口与调用方、配置项与开关、监控指标与告警、兼容性。
KB_QUICK_REF 时沉淀到其指定路径；无则沉淀到 ${REQ_ROOT}/经验沉淀/patterns.md、anti-patterns.md、regressions.md（若相关路径可用）${REQ_ROOT}/，经验沉淀优先从快速参考文档获取路径，未提供时落到 ${REQ_ROOT}/经验沉淀/try/catch 规则：每个 catch 必须有 error 级别日志和监控上报info、error；禁止 warn/worn/warning共 1 个版本