sdd-full 3.1.0 → 4.0.0

package/skills/development-execution/sdd-add/SKILL.md

@@ -1,540 +0,0 @@
-【claude code调用标识：sdd-add】【trae调用标识：sdd-add+临时功能落地】【流程场景：3.小型功能迭代、4.Bug处理】
-
----
-name: sdd-add
-description: 个人开发临时新增功能全流程落地：需求澄清→优先级决策→成本估算→最小可行实现→自我测试→技术债务记录→文档同步→安全合并发布→监控→优化
----
-
-# 个人开发临时功能全流程落地
-
-## 概述
-
-本技能提供一套完整的**个人开发临时功能处理流程**，确保临时功能不打乱节奏、不埋技术债务，同时兼顾**快速交付**与**架构规范**。
-
-核心流程：
-- **需求处理阶段**：需求澄清 → 优先级决策 → 成本估算 → 版本控制准备
-- **开发实现阶段**：最小可行实现 → 多平台适配 → 自我测试 → 技术债务记录 → 文档同步
-- **发布维护阶段**：安全合并与发布 → 上线后监控 → 后续迭代优化
-
----
-
-## 何时使用
-
-- 有**临时、突发、高频小功能**需要快速上线
-- 个人开发项目，需要平衡**快速交付**与**技术债务管控**
-- 临时功能可能演变成正式功能，需要为未来留后路
-- 需要一套**标准化流程**处理临时需求，避免每次都从头思考
-
----
-
-## 第一部分：需求处理阶段
-
-### 1.1 需求澄清（避免模糊开发）
-
-**必须回答 5W1H**：
-- What：功能内容具体是什么？
-- Why：解决什么痛点？不做会怎么样？
-- Who：目标用户是谁？使用频率如何？
-- When：上线时间要求？紧急程度？
-- How：大致的实现方式是什么？
-- How much：价值收益如何？量化评估？
-
-**制定可验证验收标准**：
-每条标准必须具体、可测试，例如：
-- 批量上传 ≤ 5 张图，单张 ≤ 2MB
-- 响应时间 ≤ 500ms，成功率 ≥ 99%
-- 支持 3 种主流浏览器（Chrome、Safari、Edge）
-
-**价值量化评估**：
-使用简易评分表判断优先级：
-```
-优先级得分 = (紧急度 + 重要性 + 价值) / 成本
-```
-
-评分标准：
-- 紧急度：1（低）- 5（高，立即要）
-- 重要性：1（低）- 5（高，核心功能）
-- 价值：1（低）- 5（高，带来显著收益）
-- 成本：1（低，<1天）- 5（高，>1周）
-
-得分 > 3 优先处理，得分 < 2 考虑放弃或延后。
-
-**产出**：创建 `docs/temp-requirements/[功能名]-requirements.md`
-
----
-
-### 1.2 优先级决策（拒绝无差别处理）
-
-| 类型 | 需要采取的行动 | 时间要求 |
-|------|----------------|----------|
-| **P0 紧急修复** | 立即暂停非核心任务，启动修复流程 | 30分钟内响应，2小时内出临时方案 |
-| **P1 核心增强** | 评估成本，替换当前低价值任务 | 1天内完成决策，48小时内启动开发 |
-| **P2 体验优化** | 放入个人 Backlog，排到下一轮迭代 | 1周内规划，不影响当前核心任务 |
-| **P3 探索功能** | 仅记录想法，等待项目稳定期 | 无时间压力，按需启动 |
-
-**产出**：更新 `docs/temp-requirements/backlog.md`，记录优先级与计划
-
----
-
-### 1.3 成本估算（避免过度投入）
-
-**时间盒限制**：
-- P0/P1 级功能：≤ 8 小时
-- P2 级功能：≤ 4 小时
-- 超过时间盒必须重新评估，考虑拆分或延后
-
-**多平台适配成本**：
-- 原生开发：考虑不同机型、系统版本
-- Flutter：优先复用共享代码
-- Web：先适配主流浏览器
-
-**技术债务预估**：
-明确临时方案的后续优化成本，纳入迭代计划。
-
-**产出**：在需求文档中记录 `成本估算` 与 `时间盒`
-
----
-
-### 1.4 版本控制准备（避免代码混乱）
-
-**必须创建独立分支**：
-- 临时功能：`temp/[功能名]-[日期]`
-- 紧急修复：`hotfix/[问题]-[日期]`
-
-**分支隔离原则**：
-- 开发、测试、合并全流程在分支内完成
-- 不污染主分支
-- 提交规范：每次提交附清晰说明，便于后续追溯和回滚
-
-**产出**：
-- 创建并切换到对应分支
-- 更新 `docs/temp-requirements/[功能名]-requirements.md`，记录分支信息
-
----
-
-## 第二部分：开发实现阶段
-
-### 2.1 最小可行实现（拒绝过度设计）
-
-**垂直切片开发**：
-先完成核心流程，再逐步添加辅助功能。例如：先实现上传，再做裁剪。
-
-**临时方案优先**：
-- 复杂功能可用第三方库快速实现
-- 标注 `// TODO: 后续优化 [原因] [计划时间]`
-- 避免功能镀金，减少维护成本
-
-**代码简洁原则**：
-- 只写必要代码
-- 保持代码可读性
-- 不追求完美，追求可用
-
-**产出**：功能代码实现，标注临时方案
-
----
-
-### 2.2 多平台适配（确保一致性）
-
-| 平台 | 需要做的适配工作 | 效率技巧 |
-|------|------------------|----------|
-| **原生（iOS/Android）** | 适配不同屏幕、系统版本，处理权限申请 | 抽取核心逻辑为共享模块，减少重复开发 |
-| **Flutter** | 统一UI/UX，平台特有功能单独实现 | 利用Hot Reload快速调试，使用成熟插件 |
-| **Web** | 兼容主流浏览器，处理响应式布局 | 使用Tailwind CSS等工具减少样式适配时间 |
-
-**产出**：多平台适配代码
-
----
-
-### 2.3 自我测试（避免上线后翻车）
-
-**单元测试**：
-- 核心函数编写测试用例
-- 例如：Python 用 pytest，JavaScript 用 Jest
-
-**手动测试**：
-- 严格按验收标准执行
-- 记录测试步骤和结果
-
-**边界测试**：
-- 无效输入、网络异常、权限不足等场景
-
-**回归测试**：
-- 验证临时功能不影响原有核心功能
-
-**产出**：
-- 单元测试代码
-- `docs/temp-requirements/[功能名]-test-report.md`
-
----
-
-### 2.4 技术债务记录（避免隐形坑）
-
-**创建 `tech-debt.md` 文件**（如果不存在），记录：
-
-模板：
-```markdown
-# 技术债务清单
-
-## [日期] - [功能名]
-
-1. **功能**：[简要描述]
-2. **临时方案**：[使用了什么临时方案，为什么]
-3. **优化计划**：[计划在什么时间用什么方式优化]
-4. **原因**：[为什么选择临时方案而不是完美方案]
-5. **风险**：[临时方案可能带来的风险]
-```
-
-**示例**：
-```markdown
-# 技术债务清单
-
-## 2026-05-04 - 头像上传优化
-
-1. **功能**：用户头像上传与裁剪
-2. **临时方案**：使用第三方 image_cropper 库
-3. **优化计划**：2026年5月10日前替换为自研算法
-4. **原因**：快速实现功能，减少开发时间，赶上线节点
-5. **风险**：第三方库可能有兼容性问题，未来需要迁移成本
-```
-
-**产出**：更新 `docs/tech-debt.md`
-
----
-
-### 2.5 文档同步（方便后续维护）
-
-**更新 `README.md`**：
-- 添加临时功能说明
-- 使用方法和注意事项
-- 标注"临时功能，后续优化"
-
-**记录测试用例**：
-- 保存关键测试步骤
-- 便于后续回归测试
-
-**产出**：
-- 更新 `README.md`
-- 更新 `docs/temp-requirements/[功能名]-requirements.md`，补充实现细节
-
----
-
-## 第三部分：发布与维护阶段
-
-### 3.1 安全合并与发布
-
-**合并前检查清单**：
-1. [ ] 切换到主分支并拉取最新代码
-2. [ ] 合并临时分支，解决冲突
-3. [ ] 测试合并后代码，确保无问题
-4. [ ] 提交并推送
-5. [ ] 删除临时分支
-
-**灰度发布策略**（如果适用）：
-- 先小范围发布（10% 用户）
-- 监控指标正常后再全量发布
-
-**产出**：功能上线，分支清理完成
-
----
-
-### 3.2 上线后监控（及时发现问题）
-
-**核心指标监控**：
-- 响应时间
-- 错误率
-- 用户反馈
-- 业务数据
-
-**快速回滚准备**：
-- 准备回滚方案
-- 发现严重问题立即恢复到之前版本
-
-**产出**：`docs/temp-requirements/[功能名]-monitoring.md`，记录监控结果
-
----
-
-### 3.3 后续迭代优化（持续改进）
-
-**技术债务清理**：
-- 按计划重构临时方案
-- 提升代码质量
-
-**功能扩展**：
-- 根据用户反馈，决定是否增加更多功能
-
-**流程优化**：
-- 总结此次处理经验
-- 调整个人开发流程
-
-**产出**：
-- 优化后的代码
-- `docs/temp-requirements/[功能名]-retrospective.md`，总结经验教训
-
----
-
-## 最终目录结构
-
-```
-项目根/
-├── docs/
-│   ├── temp-requirements/          # 临时功能需求
-│   │   ├── backlog.md              # 临时功能待办
-│   │   ├── [功能名]-requirements.md
-│   │   ├── [功能名]-test-report.md
-│   │   ├── [功能名]-monitoring.md
-│   │   └ [功能名]-retrospective.md
-│   └── tech-debt.md                # 技术债务清单
-└── README.md                       # 更新，添加临时功能说明
-```
-
----
-
-## 快速检查清单
-
-### 需求阶段
-- [ ] 回答了 5W1H
-- [ ] 制定了可验证验收标准
-- [ ] 完成了价值量化评估
-- [ ] 确定了优先级
-- [ ] 设定了时间盒
-- [ ] 创建了独立分支
-
-### 开发阶段
-- [ ] 完成了最小可行实现
-- [ ] 标注了临时方案和 TODO
-- [ ] 完成了多平台适配
-- [ ] 编写了单元测试
-- [ ] 完成了手动测试和边界测试
-- [ ] 记录了技术债务
-- [ ] 更新了文档
-
-### 发布阶段
-- [ ] 通过了合并前检查
-- [ ] 功能正常上线
-- [ ] 删除了临时分支
-- [ ] 启动了监控
-- [ ] 准备了回滚方案
-
----
-
-## 常见"需要避免"的错误
-
-1. **无计划接收临时需求**：导致任务混乱，效率低下
-   - 解决：建立个人需求看板，严格按优先级处理
-
-2. **直接在主分支开发**：代码混乱，回滚困难
-   - 解决：强制使用 Git 分支，隔离临时功能
-
-3. **过度追求完美**：开发时间过长，延误核心任务
-   - 解决：设定时间盒，只做最小可行实现
-
-4. **忽略测试**：上线后发现问题，频繁修复
-   - 解决：建立个人测试流程，确保覆盖核心场景
-
-5. **不记录技术债务**：代码维护困难，后续开发效率低
-   - 解决：创建技术债务文档，明确优化计划
-
----
-
-## 核心逻辑总结
-
-临时功能处理的本质是**平衡灵活性与稳定性**，需要做到：
-
-1. **先评估再行动**：用价值-成本模型判断优先级，拒绝盲目开发
-2. **严格版本控制**：用 Git 分支隔离临时功能，确保主分支干净
-3. **最小可行实现**：聚焦核心价值，标注技术债务，后续迭代优化
-4. **全程文档记录**：需求、验收标准、测试用例、技术债务均需文档化
-5. **上线后监控与优化**：快速响应问题，持续改进功能和流程
-
----
-
-## 使用指南
-
-### 快速开始（30分钟快速处理）
-
-1. **第1-5分钟**：需求澄清，回答 5W1H，制定验收标准
-2. **第5-10分钟**：优先级决策，价值量化评估，设定时间盒
-3. **第10-15分钟**：版本控制准备，创建分支
-4. **第15-结束**：按流程开发、测试、记录、发布
-
-### 命令参考（假设使用 Git）
-
-```bash
-# 1. 创建分支
-git checkout -b temp/[功能名]-$(date +%Y%m%d)
-
-# 2. 开发提交
-git add .
-git commit -m "temp: [功能名] 最小可行实现"
-
-# 3. 测试完成后合并
-git checkout main
-git pull origin main
-git merge temp/[功能名]-[日期]
-# 解决冲突...
-git push origin main
-
-# 4. 删除分支
-git branch -d temp/[功能名]-[日期]
-git push origin --delete temp/[功能名]-[日期]
-```
-
----
-
-## 模板文件（可复制）
-
-### 临时功能需求模板
-
-```markdown
-# [功能名] - 临时功能需求
-
-## 1. 需求澄清
-
-### 5W1H
-- **What**：
-- **Why**：
-- **Who**：
-- **When**：
-- **How**：
-- **How much**：
-
-### 验收标准
-- [ ]
-- [ ]
-- [ ]
-
-### 价值量化评估
-- 紧急度：/5
-- 重要性：/5
-- 价值：/5
-- 成本：/5
-- 得分：
-
-### 优先级
-- P0 / P1 / P2 / P3
-
-### 时间盒
-- 预估时间：小时
-- 截止时间：
-
-## 2. 版本控制
-
-- 分支名：
-- 创建时间：
-
-## 3. 实现记录
-
-- 临时方案：
-- TODO 优化：
-- 第三方依赖：
-
-## 4. 测试结果
-
-- 单元测试：通过/失败
-- 手动测试：通过/失败
-- 边界测试：通过/失败
-- 回归测试：通过/失败
-
-## 5. 上线记录
-
-- 上线时间：
-- 监控状态：
-- 回滚准备：是/否
-```
-
-### 技术债务模板
-
-```markdown
-# 技术债务清单
-
-## [YYYY-MM-DD] - [功能名]
-
-1. **功能**：
-2. **临时方案**：
-3. **优化计划**：
-4. **原因**：
-5. **风险**：
-```
-
----
-
-## 与 sdd、ui-sdd 的配置建议
-
-### 三层架构定位
-
-| 技能 | 核心定位 | 层级 | 产出 |
-|------|---------|------|------|
-| **sdd** | 需求层·业务拆分 | 顶层 | docs/stories/、docs/ui/pages.md、docs/architecture/、docs/database/、docs/api/、specs/ |
-| **ui-sdd** | 架构层·UI交互 | 中层 | spec/ui/ 下完整 SDD（100%覆盖） |
-| **sdd-add** | 迭代层·快速迭代 | 底层 | docs/temp-requirements/ 下临时迭代 |
-
-### 完整流程配置
-
-#### 项目从零启动（需求→UI→实现）
-
-1. **先用 sdd**：拆 Epic→Feature→Story，写验收标准、做估算
-2. **再用 ui-sdd**：对 Story 中的 UI/交互需求，按「App全域盘点清单」勾出所有页面/组件/规则，建完整 SDD
-3. **交付开发**（或用 sdd-add 做快速实现）
-
-#### 正常迭代开发（日常新功能）
-
-1. **先用 sdd**：把新功能拆成 Story，写验收标准
-2. **再用 ui-sdd**：回「盘点清单」补勾，补建/更新 spec/ui/ 下的 SDD
-3. **最后用 sdd-add**：做快速实现，需求文档中必须**引用 sdd 的 Story 和 ui-sdd 的 SDD**
-
-#### 临时需求/紧急修复
-
-1. **直接用 sdd-add**：快速澄清、优先级、实现
-2. **如果涉及 UI/新增页面**：必须同步回 ui-sdd：补勾、补建 SDD
-3. **如果涉及 Story 拆分**：必须同步回 sdd：补 Story
-
-### 文档关联引用规范
-
-#### sdd Story 中引用 ui-sdd
-
-在 sdd 产出的 Story 文档中加入：
-
-```markdown
-## 关联文档
-
-- 对应UI交互SDD：spec/ui/pages/xxx-page.sdd.md
-- 复用组件SDD：spec/ui/common/ui-yyy.sdd.md
-- 相关弹窗SDD：spec/ui/dialog/zzz-dialog.sdd.md
-```
-
-#### ui-sdd SDD 中引用 sdd Story
-
-在 ui-sdd 产出的页面/组件SDD中加入：
-
-```markdown
-## 关联用户故事
-
-- 主故事：US-001（在 docs/stories/user_stories.md）
-- 相关故事：US-002、US-003
-```
-
-#### sdd-add 临时需求中引用前两者
-
-在 sdd-add 产出的临时需求文档中加入：
-
-```markdown
-## 关联文档
-
-- 关联Story：docs/stories/user_stories.md 中的 US-xxx
-- 关联UI-SDD：spec/ui/pages/yyy-page.sdd.md
-```
-
-### 高频场景决策表
-
-| 场景 | 第1步用 | 第2步用 | 第3步用 |
-|------|---------|---------|---------|
-| 新项目从零开始 | sdd（需求拆分） | ui-sdd（UI设计） | 开发 |
-| 新增完整Story | sdd（Story拆分） | ui-sdd（补SDD） | 开发 |
-| 临时小功能 | sdd-add（快速处理） | ui-sdd（可选，需UI） | 开发 |
-| 新增复杂Epic | sdd（Epic拆分） | ui-sdd（批量建SDD） | 分批开发 |
-| 临时小bug修复 | sdd-add | 无需 | 快速修复 |
-| 优化现有交互 | sdd（更新Story） | ui-sdd（更新SDD） | sdd-add（实现） |
-
-### 一句话原则
-
-**「sdd 定方向（做什么），ui-sdd 定样子（怎么做），sdd-add 填细节（快速补）；从上往下拆，从下往上补，互相引用不遗漏」**