sdd-full 4.8.0 → 4.8.2

package/skills/rules/project_rules.md

@@ -1,405 +1,78 @@
-项目规则 - SDD全流程开发技能体系（团队共享）
+# 项目规则 - SDD全流程开发技能体系（团队共享）
 
-一、项目概述
+## 一、项目概述
 
 本项目是一个完整的SDD（Software Design Document）全流程开发技能包，包含从需求分析到发布运维的全流程技能，支持Trae和Claude Code双调用机制。
 
-核心逻辑：以SDD全流程为唯一主线，Figma Make不脱离SDD规范，仅负责UI布局、视觉风格、全量App UI产出，融入ui-motion-interaction-standard技能规范动效交互、enterprise-spec（企业级全栈工程规范SDD）统一定制全流程标准，所有UI相关需求均来自SDD定义，流程各节点严格对应真实技能，不新增任何虚构技能、不遗漏核心技能。
-
-二、核心流程规范
-
-2.1 完整SDD+Figma Make闭环流程（含ui-motion-interaction-standard+enterprise-spec）
-
-# 阶段1：需求分析（SDD启动，对应需求分析类技能）
-market-research（市场调研） → competitive-brief（竞品分析） → brainstorming（头脑风暴）
-→ prd-write（生成PRD） → requirement-completion-officer（需求补全） → sdd（需求拆分，明确用户故事、前后端需求，作为全流程唯一真源头）
-→ sdd-full（全流程入口，确定流程方案） → enterprise-spec（企业级全栈工程规范SDD，同步输出全流程基础规范，指导后续各阶段）
-
-# 阶段2：设计规划（SDD主导，Figma Make准备，对应设计规划类技能）
-sdd（需求拆分输出UI、前后端相关需求，贴合enterprise-spec规范，SDD为唯一依据） → ui-sdd（UI交互SDD，输出交互/流程/动效规范，给Figma Make提供依据，遵循enterprise-spec）
-→ ui-motion-interaction-standard（UI动效交互标准，规范Figma Make动效设计，补充动效交互依据，符合enterprise-spec统一标准）
-→ ui-sdd-specialized（复杂UI场景规范，辅助Figma Make，遵循enterprise-spec） → function-sdd（单一功能SDD，补充UI、前后端功能依据，贴合enterprise-spec）
-→ writing-plans（制定计划，含Figma Make执行计划、各类全自动测试计划，遵循enterprise-spec流程规范，明确测试与SDD校验要求） → enterprise-spec（二次校准，确保设计规划全环节符合企业级全栈工程规范）
-
-# 阶段3：Figma Make执行（仅负责UI布局风格，不越权）
-基于 enterprise-spec + ui-sdd + ui-motion-interaction-standard + ui-sdd-specialized + function-sdd 输出的规范，生成：
-App桌面图标、闪屏页、全局Icon库、所有业务页面UI、弹窗/动效布局（动效符合ui-motion-interaction-standard标准，整体符合enterprise-spec规范，严格对齐SDD要求）
-
-# 阶段4：设计转开发+后端开发（衔接Figma Make与开发，同步推进前后端）
-# 前端开发分支
-design-to-code（Figma UI转前端代码，同步还原ui-motion-interaction-standard规范的动效，遵循enterprise-spec编码标准，对齐SDD） → flutter-apply-architecture-best-practices（Flutter架构适配，贴合enterprise-spec企业级架构规范）
-→ flutter-build-responsive-layout（响应式布局适配，符合enterprise-spec多端适配标准） → flutter-setup-declarative-routing（页面导航配置，遵循enterprise-spec路由规范）
-→ flutter-implement-json-serialization（数据模型转换，支撑UI渲染，符合enterprise-spec数据规范，对齐SDD数据定义）
-# 后端开发分支
-sdd-code（后端功能实现SDD拆分，按架构特性适配，定义代码规范，严格遵循SDD需求，作为后端开发唯一依据） → 后端代码实现（贴合enterprise-spec接口规范，对齐SDD接口定义）
-
-# 阶段5：开发执行+四类全自动测试流程（所有需求添加流程必走，SDD为唯一真源头）
-test-driven-development（TDD开发，遵循enterprise-spec开发规范，严格对齐SDD） → flutter-use-http-package（前端网络请求开发，对接后端接口，符合enterprise-spec接口规范，对齐SDD）
-→ flutter-fix-layout-issues（修复UI布局问题，含ui-motion-interaction-standard相关动效布局问题，修复后符合enterprise-spec，同步校验与SDD一致性） → systematic-debugging（调试，含UI、动效、前后端Bug，调试流程遵循enterprise-spec，确保与SDD一致）
-→ bug-reproduction-confirm（Bug验证，含各类Bug，验证标准贴合enterprise-spec，对齐SDD验收要求） → performance-optimize（UI+代码+动效+后端性能优化，贴合ui-motion-interaction-standard，符合enterprise-spec性能标准）
-→ flutter-errors（Flutter专项错误处理，含UI转码、动效实现错误，处理方案遵循enterprise-spec，确保与SDD一致）
-
-# 阶段6：质量保障（衔接全自动测试与SDD校验）
-flutter-test（补充各类全自动测试未覆盖场景，确保测试全面性，遵循enterprise-spec测试标准，同步校验与SDD一致性） → bdd-acceptance（结合全自动测试结果，完成UI交互+动效+用户故事验收，贴合enterprise-spec验收规范，对齐SDD） → security-audit（后端安全审计，符合enterprise-spec安全标准，对齐SDD安全要求）
-→ quality-gate（质量门禁，校验全自动测试通过率、UI还原度、动效合规性、SDD一致性，符合ui-motion-interaction-standard和enterprise-spec全流程规范，不合格则返回开发阶段复改+重新走Bug修复+前置检查+测试流程）
-
-# 阶段7：发布运维（全程以SDD为唯一真源头）
-release-flow（发布流程管理，同步归档全自动测试报告、SDD校验报告，负责版本规划、风险评估、发布验证、复盘总结，确保发布顺利，含UI、动效、前后端相关版本管理，遵循enterprise-spec发布规范，确保发布版本与SDD一致）
-→ finishing-a-development-branch（开发分支完成，负责代码合并、分支清理，同步留存全自动测试相关文档、SDD文档，规范分支管理流程，含所有代码分支管理，符合enterprise-spec分支管理标准，确保分支代码与SDD一致）
-
-2.2 四类全自动测试流程（所有需求添加流程必走，按场景执行）
-
-序号
-
-测试类型
-
-技能支撑
-
-测试内容
-
-触发时机
-
-1
-
-前端UI全量测试
-
-flutter-test
-
-Widget测试、E2E测试、UI布局校验、动效验证（贴合ui-motion-interaction-standard）
-
-前端开发完成后
-
-2
-
-用户故事流程测试
-
-bdd-acceptance
-
-基于SDD定义的用户故事验证功能是否符合业务预期
-
-功能开发完成后
-
-3
-
-后端全量测试
-
-security-audit、flutter-test
-
-接口校验、数据处理、安全审计（符合enterprise-spec）
-
-后端开发完成后
-
-4
-
-Bug修复流程
-
-bug-reproduction-confirm、systematic-debugging
-
-前置检查、Bug复现、修复验证
-
-测试不通过时
-
-2.3 Bug修复流程（含前置检查）
-
-测试不通过 → 【Bug修复前置检查】
-    → env-check（环境检测，校验开发/测试环境配置、依赖是否正常，排查环境类Bug诱因）
-    → 包兼容性检查（校验前后端包版本、依赖包兼容性，排查兼容性类Bug诱因）
-    → bug-reproduction-confirm（结合前置检查结果复现Bug，定位根因）
-    → systematic-debugging（Bug修复，修复后同步校验环境及包兼容性）
-    → 选择对应测试流程（UI/用户故事/后端测试）重新验证
-测试通过 → 进入SDD校验环节
-
-2.4 SDD校验环节（所有代码流程最后必走）
-
-校验内容：
-1. 前端代码与SDD一致性
-2. 后端代码与SDD一致性
-3. UI实现与SDD一致性
-4. 动效效果与SDD一致性
-
-若不一致 → 返回对应开发/设计环节修改 → 重新执行测试流程 → 再次SDD校验
-若一致 → verification-before-completion（完成前验证，结合四类全自动测试报告+SDD校验结果，含UI还原度、动效合规性、测试通过率、SDD一致性校验，整体符合enterprise-spec验收规范）→ 进入质量门禁
-
-三、功能添加流程（按分类细分，所有功能添加必走，无缝衔接主流程）
-
-核心原则：无论何种分类的功能添加，均以SDD为唯一真源头，所有环节、所有修改均需对齐SDD，enterprise-spec全程提供规范指导，不偏离主流程核心逻辑。
-
-3.1 功能分类定义（3大类，覆盖常见场景）
-
-1.  基础功能（核心必备类）：App基础运行所需功能（如登录、注册、基础页面导航），无复杂UI/动效，前后端逻辑简单
-2.  业务功能（核心业务类）：承载核心业务场景的功能（如交易、数据统计、业务流程审批），含常规UI/动效，前后端逻辑复杂
-3.  优化类功能（迭代升级类）：对现有功能的迭代优化、体验提升（如UI样式优化、性能优化、交互优化），无需完整走全流程，聚焦优化点
-
-3.2 基础功能添加流程（专属简化流程，核心不遗漏）
-
-1.  需求启动与SDD拆分（衔接主流程阶段1，需求分析类技能）
-    brainstorming（明确基础功能核心诉求） → requirement-completion-officer（需求补全，明确验收标准）
-    → sdd（拆分简单前后端、UI需求，输出专属SDD） → sdd-full（选择基础功能流程）
-
-2.  功能设计规划（简化，衔接主流程阶段2，设计规划类技能）
-    ui-sdd（基础UI交互规范） → function-sdd（细化实现标准） → writing-plans（简易计划） → enterprise-spec（输出简化规范）
-
-3.  UI实现（简化，衔接主流程阶段3，设计规划类技能）
-    design-to-code（Figma UI转前端代码） → 基于 enterprise-spec + ui-sdd + function-sdd，生成简易UI、基础弹窗（无复杂动效，对齐SDD）
-
-4.  前后端开发（简化，衔接主流程阶段4，Flutter专项/设计规划类技能）
-    # 前端：flutter-build-responsive-layout → flutter-use-http-package（贴合SDD）
-    # 后端：sdd-code（拆分） → 基础接口、数据处理开发（对齐SDD）
-
-5.  开发执行与测试（简化，衔接主流程阶段5，开发执行类技能）
-    systematic-debugging → bug-reproduction-confirm
-    # 简化测试：前端UI简易测试（flutter-test）、后端基础测试（security-audit）、Bug修复流程（含env-check前置检查）
-
-6.  SDD校验（必走，开发执行类技能）：校验前后端代码、UI与SDD一致 → verification-before-completion
-
-7.  质量门禁与发布（简化，衔接主流程阶段6、7，质量保障/发布运维类技能）
-    quality-gate → release-flow（归档文档） → finishing-a-development-branch（分支清理） → claudeception（经验沉淀）
-
-3.3 业务功能添加流程（完整流程，贴合主流程）
-
-1.  需求启动与SDD拆分（衔接主流程阶段1，需求分析类技能）
-    market-research → competitive-brief → brainstorming → prd-write → requirement-completion-officer
-    → sdd（拆分详细需求，输出专属SDD） → sdd-full（选择业务功能流程）
-
-2.  功能设计规划（衔接主流程阶段2，设计规划类技能）
-    ui-sdd → ui-motion-interaction-standard → ui-sdd-specialized（按需） → function-sdd
-    → writing-plans（详细计划） → enterprise-spec（完整规范，二次校准）
-
-3.  UI实现（衔接主流程阶段3，设计规划类技能）
-    design-to-code（Figma UI转前端代码，还原动效） → 基于 enterprise-spec + 各类UI规范，生成完整业务UI、复杂动效（对齐SDD及规范）
-
-4.  前后端开发（衔接主流程阶段4，Flutter专项/设计规划类技能）
-    # 前端：flutter-apply-architecture-best-practices → flutter-build-responsive-layout → flutter-setup-declarative-routing → flutter-implement-json-serialization → flutter-use-http-package
-    # 后端：sdd-code（详细拆分） → 业务接口、复杂数据处理开发（贴合SDD）
-
-5.  开发执行与测试（衔接主流程阶段5，开发执行类技能）
-    test-driven-development → flutter-fix-layout-issues → systematic-debugging → bug-reproduction-confirm → performance-optimize → flutter-errors
-    # 完整四类全自动测试（按场景执行，含Bug修复前置检查env-check）
-
-6.  SDD校验（必走，开发执行类技能）：全面校验前后端、UI、动效与SDD一致 → verification-before-completion
-
-7.  质量门禁与发布（衔接主流程阶段6、7，质量保障/发布运维类技能）
-    flutter-test → bdd-acceptance → security-audit → quality-gate → release-flow（归档报告） → finishing-a-development-branch → claudeception（经验沉淀）
-
-3.4 优化类功能添加流程（聚焦优化点，简化非必要环节）
-
-1.  需求启动与SDD更新（衔接主流程阶段1，需求分析类技能）
-    brainstorming（明确优化点） → requirement-completion-officer（补全需求）
-    → sdd（更新原有SDD，输出优化专属SDD） → sdd-full（选择优化流程）
-
-2.  优化设计规划（简化，衔接主流程阶段2，设计规划类技能）
-    ui-sdd（按需）/ui-motion-interaction-standard（按需） → function-sdd（细化优化标准） → writing-plans（优化计划） → enterprise-spec（优化规范）
-
-3.  优化实现（衔接主流程阶段3、4，设计规划/Flutter专项类技能）
-    # UI优化（按需）：design-to-code（仅修改优化涉及部分，贴合SDD）
-    # 前后端优化：针对性修改代码，严格对齐SDD及enterprise-spec
-
-4.  开发执行与测试（聚焦优化点，衔接主流程阶段5，开发执行类技能）
-    systematic-debugging → performance-optimize
-    # 针对性测试：优化点UI/动效测试、功能测试，Bug修复流程（含env-check前置检查）
-
-5.  SDD校验（必走，开发执行类技能）：校验修改部分与SDD一致，不破坏原有功能 → verification-before-completion
-
-6.  质量门禁与发布（简化，衔接主流程阶段6、7，质量保障/发布运维类技能）
-    quality-gate → release-flow（归档SDD更新文档） → finishing-a-development-branch → claudeception（经验沉淀）
-
-3.5 流程闭环总结
-
-# 正常闭环
-各类功能添加均遵循：需求分析类技能（SDD拆分/更新） → 设计规划类技能（对应分类专属设计规划） → Flutter专项类技能（针对性实现） → 开发执行类技能（适配分类的全自动测试，含Bug修复前置检查env-check） → 测试通过 → verification-before-completion → 质量保障类技能（质量门禁） → 发布运维类技能（发布） → claudeception（经验沉淀）
-
-# 异常闭环
-测试不通过 / 质量门禁不合格 → Bug修复前置检查（env-check+包兼容性检查，专项工具类技能） → systematic-debugging（Bug修复，开发执行类技能） → 重新测试 → SDD校验 → 直至通过后进入发布环节
-
-四、流程场景参数
-
-场景编号
-
-流程场景
-
-说明
-
-适用技能
-
-1
-
-完整3阶段SDD流程
-
-大型项目，需要完整的SDD全流程
-
-sdd-full, enterprise-spec, ui-sdd, sdd-code
-
-2
-
-从零开始新项目
-
-新项目立项，需要创意、调研、PRD
-
-brainstorming, market-research, competitive-brief, prd-write, sdd-full
-
-3
-
-小型功能迭代
-
-快速迭代，小功能开发
-
-sdd-add, requirement-completion-officer
-
-4
-
-Bug处理
-
-Bug修复，调试问题
-
-bug-reproduction-confirm, systematic-debugging, env-check
-
-5
-
-代码发布
-
-版本发布，质量检查
-
-quality-gate, release-flow, finishing-a-development-branch
-
-五、技能使用规范
-
-5.1 技能分类与职责
-
-分类
-
-技能
-
-职责描述
-
-适用阶段
-
-需求分析
-
-brainstorming, market-research, competitive-brief, prd-write, requirement-completion-officer, sdd, sdd-full
-
-需求收集、分析、拆分
-
-阶段1
-
-设计规划
-
-ui-sdd, ui-sdd-specialized, ui-motion-interaction-standard, function-sdd, sdd-code, writing-plans, enterprise-spec, design-to-code
-
-设计方案制定、动效规范
-
-阶段2
-
-开发执行
-
-sdd-add, test-driven-development, systematic-debugging, verification-before-completion, bug-reproduction-confirm, performance-optimize, flutter-errors
-
-代码实现、调试
-
-阶段5
-
-Flutter专项
-
-flutter-apply-architecture-best-practices, flutter-build-responsive-layout, flutter-setup-declarative-routing, flutter-implement-json-serialization, flutter-use-http-package, flutter-fix-layout-issues
-
-Flutter开发支持
-
-阶段4-5
-
-质量保障
-
-quality-gate, security-audit, bdd-acceptance, flutter-test
-
-质量把关、测试验收
-
-阶段6
-
-发布运维
-
-finishing-a-development-branch, release-flow
-
-发布管理
-
-阶段7
-
-知识沉淀
-
-claudeception, mempalace-auto-saver
-
-经验积累
-
-发布后
-
-专项工具
-
-requesting-code-review, receiving-code-review, env-check, ios-full-auto-debug
-
-辅助工具
-
-全流程
-
-5.2 强制使用技能
-
-- ✅ 所有发布前必须通过 quality-gate
-
-- ✅ 所有需求必须经过 sdd/sdd-full 拆分
-
-- ✅ 所有代码流程最后必走SDD校验，保证代码与SDD一致
-
-- ✅ 所有需求添加流程必走四类全自动测试
-
-- ✅ Bug修复必须经过前置检查（env-check+包兼容性检查）
-
-- ✅ 所有性能问题必须经过 performance-optimize
-
-- ✅ 发布后必须进行 claudeception 经验沉淀
-
-- ✅ UI动效必须符合 ui-motion-interaction-standard 标准
-
-- ✅ 全流程必须遵循 enterprise-spec 企业级规范
-
-5.3 技能调用优先级
-
-1. 高优先级（必须调用）：sdd/sdd-full, enterprise-spec, quality-gate, claudeception
-
-2. 中优先级（按场景调用）：ui-sdd, sdd-code, design-to-code, flutter-test, bdd-acceptance
-
-3. 低优先级（按需调用）：其余技能根据实际需求选择
-
-六、文档规范
-
-6.1 SDD模板规范
-
+## 二、核心流程规范
+
+### 2.1 新项目开发流程
+```
+需求收集 → 头脑风暴 → 市场调研 → PRD编写 → SDD拆分 → UI设计 → 代码设计 → 测试设计 → 开发 → 测试 → 质量检查 → 发布 → 复盘
+```
+
+### 2.2 Bug修复流程
+
+Bug修复流程为选项类型，根据Bug类型选择对应子流程：
+
+```
+1. 简单Bug修复 - 直接修复 → 验证 → 质量检查 → 经验沉淀
+2. 复杂Bug系统调试 - 复现确认 → 系统化调试 → 验证 → 质量检查 → 经验沉淀
+3. 性能问题修复 - 性能优化 → 验证 → 质量检查 → 经验沉淀
+4. 安全漏洞修复 - 安全审计 → 复现确认 → 系统化调试 → 验证 → 质量检查 → 安全复核 → 经验沉淀
+5. 回归Bug修复 - 复现确认 → 系统化调试 → 补充回归用例 → 修复 → 验证 → 质量检查 → 经验沉淀
+6. Flutter iOS真机调试 - 环境检查 → 复现确认 → Flutter专项调试 → 定位修复 → 真机验证 → 验证 → 质量检查 → 经验沉淀
+```
+
+### 2.3 小型功能迭代流程
+```
+需求澄清 → SDD快速拆分 → 开发 → 验证 → 质量检查 → 发布
+```
+
+## 三、技能使用规范
+
+### 3.1 技能分类与职责
+| 分类 | 技能 | 职责描述 |
+|------|------|---------|
+| 需求分析 | brainstorming, market-research, competitive-brief, prd-write, requirement-completion-officer, sdd, sdd-full | 需求收集、分析、拆分 |
+| 设计规划 | ui-sdd, ui-sdd-specialized, sdd-code, function-sdd, sdd-test, sdd-deploy, sdd-ops, writing-plans, ai-coding-rules, design-to-code, enterprise-spec, flutter-map, flutter-av | 设计方案制定 |
+| 开发执行 | sdd-add, test-driven-development, systematic-debugging, verification-before-completion, bug-reproduction-confirm, performance-optimize, flutter-errors | 代码实现 |
+| 质量保障 | quality-gate, security-audit, bdd-acceptance, flutter-test | 质量把关 |
+| 发布运维 | finishing-a-development-branch, release-flow | 发布管理 |
+| 知识沉淀 | claudeception, mempalace-auto-saver | 经验积累 |
+| 专项工具 | using-superpowers, requesting-code-review, receiving-code-review, env-check | 辅助工具 |
+
+### 3.2 强制使用技能
+- ✅ **所有发布前必须通过 quality-gate**
+- ✅ **所有需求必须经过 sdd/sdd-full 拆分**
+- ✅ **所有Bug修复根据类型选择对应流程：简单Bug直接修复，复杂Bug走bug-reproduction-confirm → systematic-debugging，性能问题走performance-optimize，安全漏洞走security-audit，回归Bug需补充Test-SDD，Flutter iOS真机调试走env-check → flutter-errors**
+- ✅ **所有性能问题必须经过 performance-optimize**
+- ✅ **发布后必须进行 claudeception 经验沉淀**
+
+## 四、文档规范
+
+### 4.1 SDD模板规范
 项目使用11种标准化SDD模板：
-
-1. Base-SDD - 全局通用基线规范
-
-2. Brain-SDD - 头脑风暴文档
-
-3. Competitor-SDD - 竞品分析文档
-
-4. PRD-SDD - 产品需求文档
-
-5. UI-SDD - UI设计文档
-
-6. Code-SDD - 代码实现文档
-
-7. API-SDD - 接口设计文档
-
-8. Env-SDD - 环境配置文档
-
-9. Test-SDD - 测试设计文档
-
-10. Performance-SDD - 性能优化文档
-
-11. BugReproduction-SDD - Bug复现确认文档
-
-6.2 文档命名规范
-
+1. **Base-SDD** - 全局通用基线规范
+2. **Brain-SDD** - 头脑风暴文档
+3. **Competitor-SDD** - 竞品分析文档
+4. **PRD-SDD** - 产品需求文档
+5. **UI-SDD** - UI设计文档
+6. **Code-SDD** - 代码实现文档
+7. **API-SDD** - 接口设计文档
+8. **Env-SDD** - 环境配置文档
+9. **Test-SDD** - 测试设计文档
+10. **Performance-SDD** - 性能优化文档
+11. **BugReproduction-SDD** - Bug复现确认文档
+
+### 4.2 文档命名规范
+```
 {项目名称}-{模板名称}-{版本}.md
 示例：个人备忘录APP-Base-SDD-v1.0.md
+```
 
-6.3 文档归档规范（全局统一约定）
-
+### 4.3 文档归档规范（全局统一约定）
+```
 项目根目录/
 ├── brainstorm.md             # 原始需求
 ├── docs/
@@ -430,190 +103,106 @@ requesting-code-review, receiving-code-review, env-check, ios-full-auto-debug
     │   ├── security/
     │   └── data/
     └── refactor-plans/       # 重构计划
+```
 
-6.4 产出目录一致性说明
-
-技能
-
-UI产出
-
-技术债务产出
-
-sdd
-
-docs/ui/pages.md
-
-—
-
-sdd-full
-
-docs/ui/design.md + specs/ui/
-
-docs/tech-debt/
-
-ui-sdd
-
-specs/ui/ + docs/ui/
-
-—
-
-sdd-add
-
-—
-
-docs/tech-debt/（统一目录格式）
-
-sdd-code
+### 4.4 产出目录一致性说明
+| 技能 | UI产出 | 技术债务产出 |
+|------|--------|-------------|
+| `sdd` | `docs/ui/pages.md` | — |
+| `sdd-full` | `docs/ui/design.md` + `specs/ui/` | `docs/tech-debt/` |
+| `ui-sdd` | `specs/ui/` + `docs/ui/` | — |
+| `sdd-add` | — | `docs/tech-debt/`（统一目录格式） |
+| `sdd-code` | — | `docs/tech-debt/` |
 
-—
-
-docs/tech-debt/
-
-design-to-code
-
-docs/ui/ + 前端代码
-
-—
-
-七、质量标准
-
-7.1 代码质量标准
+## 五、质量标准
 
+### 5.1 代码质量标准
 - 单元测试覆盖率 ≥ 80%
-
 - 代码审查必须通过
-
 - 无 P0/P1 级别 Bug
 
-- 符合 enterprise-spec 编码标准
-
-7.2 文档质量标准
-
+### 5.2 文档质量标准
 - 所有SDD模板必须完整填写
-
 - 文档版本管理规范
-
 - 文档与代码同步更新
 
-- 动效符合 ui-motion-interaction-standard
-
-7.3 发布标准
-
+### 5.3 发布标准
 - 所有测试用例通过
-
 - quality-gate 检查通过
-
 - security-audit 无高危漏洞
 
-- SDD校验通过（代码与SDD一致）
-
-八、协作规范
-
-8.1 分支管理
-
-- main - 主分支，稳定版本
-
-- develop - 开发分支
-
-- feature/* - 功能分支
-
-- bugfix/* - Bug修复分支
-
-- release/* - 发布分支
+## 六、协作规范
 
-8.2 代码审查流程
+### 6.1 分支管理
+- `main` - 主分支，稳定版本
+- `develop` - 开发分支
+- `feature/*` - 功能分支
+- `bugfix/*` - Bug修复分支
+- `release/*` - 发布分支
 
+### 6.2 代码审查流程
 1. 功能开发完成后提交 PR
-
 2. 触发 requesting-code-review
-
 3. 审查通过后触发 receiving-code-review
-
 4. 合并到 develop 分支
 
-8.3 沟通规范
-
+### 6.3 沟通规范
 - 使用明确的技能触发关键词
-
 - 及时更新状态
-
 - 遇到问题及时反馈
 
-九、调用机制规范
-
-9.1 Trae调用格式
+## 七、调用机制规范
 
+### 7.1 Trae调用格式
+```
 trae调用 模板名称 项目名称=XXX 阶段=XXX 流程场景=XXX
+```
 
-9.2 Claude Code调用格式
-
+### 7.2 Claude Code调用格式
+```
 调用 技能名称 参数
-
-9.3 快捷调用示例
-
-场景
-
-调用示例
-
-小型功能迭代
-
-调用 sdd-add 功能名称=用户登录 流程场景=小型功能迭代
-
-Bug修复
-
-调用 bug-reproduction-confirm Bug描述=登录失败
-
-质量检查
-
-调用 quality-gate 项目名称=电商平台
-
-发布流程
-
-调用 release-flow 版本号=v1.0.0
-
-十、工具与环境
-
-10.1 推荐工具
-
-- Figma - UI设计
-
-- GitHub - 代码托管
-
-- Trae - 技能调用
-
-- Claude Code - AI协作
-
-10.2 环境要求
-
+```
+
+### 7.3 流程场景参数
+| 参数值 | 说明 |
+|--------|------|
+| 完整3阶段SDD流程 | 大型项目完整流程 |
+| 从零开始新项目 | 新项目立项 |
+| 小型功能迭代 | 快速迭代 |
+| Bug处理 | Bug修复 |
+| 代码发布 | 版本发布 |
+
+## 八、工具与环境
+
+### 8.1 推荐工具
+- **Figma** - UI设计
+- **GitHub** - 代码托管
+- **Trae** - 技能调用
+- **Claude Code** - AI协作
+
+### 8.2 环境要求
 - Node.js ≥ 18.x
-
 - npm ≥ 9.x
+- sdd-full ≥ 2.2.0
 
-- sdd-full ≥ 4.7.0
-
-十一、版本管理
-
-11.1 版本命名规范
+## 九、版本管理
 
+### 9.1 版本命名规范
+```
 v{主版本}.{次版本}.{修订版本}
-示例：v4.7.0
-
-11.2 版本发布流程
+示例：v2.2.0
+```
 
+### 9.2 版本发布流程
 1. 完成功能开发与测试
-
 2. 更新版本号
-
 3. 通过 quality-gate
-
 4. 执行 release-flow
-
 5. 发布到 npm
 
-版本: v3.0
-
-更新时间: 2026-05-08
-
-适用项目: sdd-full-npm
+---
 
-团队: SDD开发团队
+**版本**: v1.0  
+**更新时间**: 2026-05-06  
+**适用项目**: sdd-full-npm  
+**团队**: SDD开发团队