sdd-full 3.1.0 → 4.0.0

package/skills/sdd-framework/Env-SDD-template.md

@@ -1,29 +0,0 @@
-# Env-SDD：[项目名称]环境配置
-
-## 一、环境列表
-| 环境 | URL | 用途 |
-|------|-----|------|
-| [ ] | | |
-
-## 二、权限配置
-- [ ] 
-
-## 三、SDK配置
-- [ ] 
-
-## 四、APIKey管理
-- [ ] 
-
-## 五、原生工程配置
-- [ ] 
-
-## 六、隐私配置
-- [ ] 
-
-## 七、敏感信息管理（不提交代码库）
-- [ ] 
-
----
-
-**模板版本**: v4.1  
-**适用技能**: sdd-deploy, sdd-ops

package/skills/sdd-framework/PRD-SDD-template.md

@@ -1,35 +0,0 @@
-# PRD-SDD：[项目名称]产品需求文档
-
-## 一、需求背景
-- [ ] 来源：
-- [ ] 目的：
-- [ ] 优先级：
-
-## 二、用户角色定义
-| 角色 | 描述 | 需求关注点 |
-|------|------|-----------|
-| [ ] | | |
-
-## 三、用户旅程梳理
-- [ ] 
-
-## 四、功能范围界定
-- [ ] 包含：
-- [ ] 不包含：
-
-## 五、需求补全清单
-- [ ] 
-
-## 六、主干流程
-- [ ] 
-
-## 七、架构&模块拆分（附录）
-- [ ] 
-
-## 八、验收标准
-- [ ] 
-
----
-
-**模板版本**: v4.1  
-**适用技能**: prd-write, requirement-completion-officer

package/skills/sdd-framework/SKILL.md

@@ -1,82 +0,0 @@
-【claude code调用标识：sdd-framework】【trae调用标识：sdd-framework+SDD融合框架】【流程场景：1.完整3阶段SDD流程、2.从零开始新项目】
-
----
-name: sdd-framework
-description: SDD融合框架 - 9份标准化SDD模板，覆盖从全局基线到测试的全流程
----
-
-# SDD融合框架
-
-## 概述
-
-本框架提供9份标准化SDD模板，将头脑风暴、竞品分析、PRD、UI设计、代码实现、API设计、环境配置、测试设计等环节纳入文档化管理，形成纯文档闭环。
-
-## 9份SDD模板
-
-| 模板名称 | 核心内容 | 适用技能 |
-|---------|---------|---------|
-| **Base-SDD** | 全局通用基线规范 | sdd, sdd-full |
-| **Brain-SDD** | 头脑风暴文档 | brainstorming |
-| **Competitor-SDD** | 竞品分析文档 | competitive-brief, market-research |
-| **PRD-SDD** | 产品需求文档 | prd-write, requirement-completion-officer |
-| **UI-SDD** | UI设计文档 | ui-sdd |
-| **Code-SDD** | 代码实现文档 | sdd-code, test-driven-development |
-| **API-SDD** | 接口设计文档 | sdd（接口拆分） |
-| **Env-SDD** | 环境配置文档 | sdd-deploy, sdd-ops |
-| **Test-SDD** | 测试设计文档 | sdd-test, test-driven-development |
-
-## 强制顺序流水线
-
-```
-Base-SDD → Brain-SDD → Competitor-SDD → PRD-SDD → Figma设计 → UI-SDD → Code-SDD → API-SDD → Env-SDD → Test-SDD → TDD开发 → 分层测试 → Bug闭环 → quality-gate → sdd-deploy → release-flow → claudeception
-```
-
-## 使用指南
-
-### 新项目完整流程
-1. 首先创建Base-SDD定义全局基线
-2. Brain-SDD进行头脑风暴
-3. Competitor-SDD进行竞品分析
-4. PRD-SDD编写产品需求
-5. Figma设计UI
-6. 依次创建UI-SDD、Code-SDD、API-SDD、Env-SDD、Test-SDD
-7. TDD开发、测试、发布
-
-### Bug修复流程
-1. systematic-debugging分析问题
-2. 更新Test-SDD添加回归用例
-3. sdd-add修复代码
-4. verification-before-completion验证
-5. quality-gate检查
-6. claudeception沉淀经验
-
-### 精简流程（小功能）
-满足任意2条可使用精简流程：
-- 开发周期≤1天，代码量≤500行
-- 不涉及新接口、新UI组件
-- 无复杂交互，不影响全局流程
-
-## 模板版本管理
-
-所有模板采用版本化管理，通过`template-version.lock`文件记录版本信息，每个项目绑定固定版本，避免版本混乱。
-
-## Figma接入规范
-
-- Figma链接失效时启用PDF/PNG备用文件
-- 关键截图需标注核心尺寸
-- UI-SDD中必须同时包含链接和备用文件
-
-## AI协作规范
-
-| 阶段 | AI职责 | 人工校验要求 |
-|------|--------|-------------|
-| Brain-SDD | 发散想法、评估风险 | 确认想法合理性 |
-| Competitor-SDD | 收集竞品信息、对比差异 | 确认分析准确性 |
-| PRD-SDD | 补全需求、梳理用户旅程 | 必须人工二次确认 |
-| Code-SDD | 编写测试用例、排查Bug | 确认代码规范 |
-| 所有阶段 | 协助整理归档 | 校验完整性 |
-
----
-
-**模板版本**: v4.1  
-**适用场景**: 个人+AI开发模式的完整文档化流程

package/skills/sdd-framework/Test-SDD-template.md

@@ -1,26 +0,0 @@
-# Test-SDD：[测试模块名称]
-
-## 一、测试策略
-- [ ] 
-
-## 二、测试用例
-| 用例ID | 测试场景 | 预期结果 |
-|--------|---------|---------|
-| [ ] | | |
-
-## 三、测试数据
-- [ ] 
-
-## 四、测试覆盖率目标
-- [ ] 
-
-## 五、性能测试指标
-- [ ] 
-
-## 六、安全测试要点
-- [ ] 
-
----
-
-**模板版本**: v4.1  
-**适用技能**: sdd-test, test-driven-development

package/skills/sdd-framework/UI-SDD-template.md

@@ -1,31 +0,0 @@
-# UI-SDD：[页面/组件名称]
-
-## 一、页面/组件概述
-- [ ] 
-
-## 二、Figma链接
-- [ ] 设计稿：
-- [ ] 备用方案（PDF/PNG）：
-- [ ] 关键截图：
-
-## 三、页面结构
-- [ ] 
-
-## 四、组件清单
-| 组件名称 | 功能描述 | 状态 |
-|---------|---------|------|
-| [ ] | | |
-
-## 五、交互流程
-- [ ] 
-
-## 六、状态设计
-- [ ] 
-
-## 七、设计规范（对齐Base-SDD）
-- [ ] 
-
----
-
-**模板版本**: v4.1  
-**适用技能**: ui-sdd

package/skills/sdd-framework/figma-spec.md

@@ -1,27 +0,0 @@
-# Figma接入规范
-
-## 一、Figma源文件管理
-- 云端托管：统一存储到团队Figma空间
-- 文件命名：[项目名]-[模块名].fig
-- 版本管理：使用Figma版本历史功能
-
-## 二、UI-SDD嵌入要求
-- 必须包含Figma设计稿链接
-- 关键页面/组件需附截图，标注核心尺寸（按钮大小、间距）
-- UI-SDD中必须同时包含链接和备用文件（PDF/PNG）
-
-## 三、设计规范同步
-- Figma组件库版本与Base-SDD保持一致
-- 颜色/字体/间距规范从Base-SDD导入
-- 设计变更需同步更新UI-SDD
-
-## 四、协作流程
-- 设计完成 → 评审 → 导出标注 → 更新UI-SDD → 开发
-
-## 五、备用方案
-- Figma链接失效时启用PDF/PNG备用文件
-- 截图需保持清晰，标注必要的尺寸信息
-
----
-
-**适用技能**: ui-sdd

package/skills/sdd-framework/flow-charts.md

@@ -1,99 +0,0 @@
-# SDD融合流程图汇总
-
-## 一、新项目完整流程
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│ 阶段0：全局基线                                               │
-├─────────────────────────────────────────────────────────────────┤
-│ Base-SDD         → 全局UI交互基线、弹窗/浮层规范、通用编码规范    │
-└─────────────────────────────────────────────────────────────────┘
-                              ↓
-┌─────────────────────────────────────────────────────────────────┐
-│ 阶段1：需求发散                                               │
-├─────────────────────────────────────────────────────────────────┤
-│ Brain-SDD        → 想法、点子、灵感、初步脑洞、废弃方案          │
-│        ↓                                                       │
-│ Competitor-SDD   → 竞品功能、交互、优缺点、可借鉴点、避坑点      │
-└─────────────────────────────────────────────────────────────────┘
-                              ↓
-┌─────────────────────────────────────────────────────────────────┐
-│ 阶段2：需求定义                                               │
-├─────────────────────────────────────────────────────────────────┤
-│ PRD-SDD          → 原始需求、用户场景、功能边界、需求补全        │
-│   ├─ 用户角色定义                                             │
-│   ├─ 用户旅程梳理                                             │
-│   ├─ 产品方案设计                                             │
-│   └─ 架构&模块拆分（附录）                                     │
-└─────────────────────────────────────────────────────────────────┘
-                              ↓
-┌─────────────────────────────────────────────────────────────────┐
-│ 阶段3：技术设计                                               │
-├─────────────────────────────────────────────────────────────────┤
-│ Figma设计        → 设计稿、组件库（对齐Base-SDD）              │
-│        ↓                                                       │
-│ UI-SDD           → 页面结构、组件清单、交互流程、内嵌Figma链接   │
-│        ↓                                                       │
-│ Code-SDD         → 代码结构、函数定义、数据模型、代码规范        │
-│        ↓                                                       │
-│ API-SDD          → 接口定义、参数、返回值、错误码、契约版本      │
-│        ↓                                                       │
-│ Env-SDD          → 环境配置、权限、SDK、APIKey、原生工程配置    │
-│        ↓                                                       │
-│ Test-SDD         → 测试用例、测试策略、测试数据                  │
-└─────────────────────────────────────────────────────────────────┘
-                              ↓
-┌─────────────────────────────────────────────────────────────────┐
-│ 阶段4：开发执行                                               │
-├─────────────────────────────────────────────────────────────────┤
-│ TDD开发          → 按Test-SDD实施，测试先行                      │
-│        ↓                                                       │
-│ 分层测试         → 单元/UI/真机/E2E                            │
-│        ↓                                                       │
-│ Bug闭环          → systematic-debugging → sdd-add              │
-└─────────────────────────────────────────────────────────────────┘
-                              ↓
-┌─────────────────────────────────────────────────────────────────┐
-│ 阶段5：发布归档                                               │
-├─────────────────────────────────────────────────────────────────┤
-│ quality-gate     → 质量门禁检查                                │
-│        ↓                                                       │
-│ sdd-deploy       → 打包、发布、部署流程                        │
-│        ↓                                                       │
-│ release-flow     → 版本发布                                    │
-│        ↓                                                       │
-│ claudeception    → 经验沉淀                                  │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-## 二、功能新增流程
-
-```
-PRD-SDD补充 → Figma更新 → UI-SDD补充 → Code-SDD补充 → API-SDD补充 → Env-SDD补充 → Test-SDD补充 → sdd-add → verification-before-completion → quality-gate → release-flow
-```
-
-## 三、Bug修复流程
-
-```
-systematic-debugging → Test-SDD补充回归用例 → sdd-add修复 → verification-before-completion → quality-gate → claudeception
-```
-
-## 四、快速迭代流程
-
-```
-requirement-completion-officer(可选) → writing-plans(可选) → sdd-add → verification-before-completion → quality-gate → finishing-a-development-branch(可选) → 简单发布
-```
-
-## 五、技能映射关系
-
-| SDD模板 | 对应技能 |
-|---------|---------|
-| Base-SDD | sdd, sdd-full |
-| Brain-SDD | brainstorming |
-| Competitor-SDD | competitive-brief, market-research |
-| PRD-SDD | prd-write, requirement-completion-officer |
-| UI-SDD | ui-sdd |
-| Code-SDD | sdd-code, test-driven-development |
-| API-SDD | sdd（接口拆分） |
-| Env-SDD | sdd-deploy, sdd-ops |
-| Test-SDD | sdd-test, test-driven-development |

package/skills/sdd-framework/template-version.lock

@@ -1,14 +0,0 @@
-{
-  "templateVersion": "v4.1",
-  "projectBind": {
-    "个人备忘录APP": "v4.1",
-    "简易记账工具": "v3.0"
-  },
-  "updateLog": [
-    {
-      "version": "v4.1",
-      "updateTime": "2026-05-06",
-      "updateContent": "skill选项式设计、全流程融合、AI协作规范、技能映射优化"
-    }
-  ]
-}

package/skills/special-tools/env-check/SKILL.md

@@ -1,53 +0,0 @@
-name: 环境预检标准化SDD
-description: 本机配置、依赖版本、网络连接预检固定话术与流程规范
-author: 
-version: 1.0.0
-trigger:
-  - 环境预检
-  - 环境检查
-  - 依赖检查
-tags:
-  - 环境配置
-  - 预检流程
-  - 开发环境
-
-【claude code调用标识：环境预检标准化SDD】【trae调用标识：环境预检标准化SDD+环境检查】【流程场景：1.完整3阶段SDD流程、2.从零开始新项目、3.小型功能迭代、4.Bug处理、5.代码发布】
-
-## 功能描述
-
-本技能提供环境预检标准化流程，包含本机配置、依赖版本、网络连接的检查清单和流程规范，帮助团队快速验证开发环境。
-
-## 调用方式
-
-### Claude Code调用
-```
-调用 环境预检标准化SDD 项目名称=个人备忘录APP
-```
-
-### Trae调用
-```
-trae调用 环境预检标准化SDD 项目名称=个人备忘录APP 环境类型=development 流程场景=从零开始新项目
-```
-
-## 参数说明
-
-| 参数名 | 类型 | 必填 | 说明 |
-|--------|------|------|------|
-| 项目名称 | string | 是 | 项目名称 |
-| 环境类型 | string | 否 | development/test/production |
-
-## 输出内容
-
-1. 本机配置检查（OS版本、IDE版本、依赖工具）
-2. 依赖版本检查（语言环境、第三方SDK）
-3. 网络连接检查（网络可用性、API连通性）
-4. 工程配置检查（pubspec、密钥、环境变量）
-5. 预检流程（自动脚本、手动清单、修复指南）
-6. 预检报告（结果汇总、问题清单、修复建议）
-
-## 适用场景
-
-- 项目启动前环境检查
-- Bug排查时环境验证
-- 团队协作环境统一
-- CI/CD流程集成

package/skills/special-tools/receiving-code-review/SKILL.md

@@ -1,215 +0,0 @@
-【claude code调用标识：receiving-code-review】【trae调用标识：receiving-code-review+代码审查接收】【流程场景：1.完整3阶段SDD流程、3.小型功能迭代、5.代码发布】
-
----
-name: receiving-code-review
-description: 在收到代码审查反馈时使用，在实施建议之前，特别是如果反馈似乎不清楚或技术上有问题 - 需要技术严谨性和验证，而不是表演性同意或盲目实施
----
-
-# 代码审查接收
-
-## 概述
-
-代码审查需要技术评估，而不是情感表演。
-
-**核心原则：** 实施前验证。假设前询问。技术正确性优先于社交舒适度。
-
-## 响应模式
-
-```
-收到代码审查反馈时：
-
-1. 阅读：完整阅读反馈，不做出反应
-2. 理解：用自己的话重述要求（或询问）
-3. 验证：对照代码库现实进行检查
-4. 评估：对这个代码库技术上是否合理？
-5. 响应：技术确认或有理由的反驳
-6. 实施：一次一个项目，测试每个项目
-```
-
-## 禁止的响应
-
-**永远不要：**
-- "你绝对正确！"（明确违反 CLAUDE.md）
-- "好观点！" / "优秀的反馈！"（表演性的）
-- "让我现在实施那个"（验证前）
-
-**相反：**
-- 重述技术要求
-- 提出澄清问题
-- 如果错误，用技术推理反驳
-- 直接开始工作（行动 > 言语）
-
-## 处理不清楚的反馈
-
-```
-如果任何项目不清楚：
-  停止 - 暂时不要实施任何内容
-  要求澄清不清楚的项目
-
-原因：项目可能相关。部分理解 = 错误实施。
-```
-
-**示例：**
-```
-你的人类伙伴："修复 1-6"
-你理解 1,2,3,6。对 4,5 不清楚。
-
-❌ 错误：现在实施 1,2,3,6，稍后询问 4,5
-✅ 正确："我理解项目 1,2,3,6。在继续之前需要澄清 4 和 5。"
-```
-
-## 特定来源处理
-
-### 来自你的人类伙伴
-- **可信** - 理解后实施
-- **如果范围不清楚，仍要询问**
-- **无表演性同意**
-- **直接行动**或技术确认
-
-### 来自外部审查者
-```
-实施前：
-  1. 检查：对这个代码库技术上是否正确？
-  2. 检查：是否破坏现有功能？
-  3. 检查：当前实现的原因？
-  4. 检查：是否在所有平台/版本上工作？
-  5. 检查：审查者是否理解完整上下文？
-
-如果建议似乎错误：
-  用技术推理反驳
-
-如果无法轻松验证：
-  说明："没有 [X] 我无法验证这一点。我应该 [调查/询问/继续]？"
-
-如果与你的人类伙伴之前的决定冲突：
-  先停止并与你的人类伙伴讨论
-```
-
-**你的人类伙伴的规则：** "外部反馈 - 保持怀疑，但仔细检查"
-
-## "专业"功能的 YAGNI 检查
-
-```
-如果审查者建议"正确实施"：
-  在代码库中搜索实际使用
-
-  如果未使用："这个端点没有被调用。移除它（YAGNI）？"
-  如果使用：则正确实施
-```
-
-**你的人类伙伴的规则：** "你和审查者都向我报告。如果我们不需要这个功能，就不要添加它。"
-
-## 实施顺序
-
-```
-对于多项反馈：
-  1. 首先澄清任何不清楚的内容
-  2. 然后按以下顺序实施：
-     - 阻塞问题（中断，安全）
-     - 简单修复（拼写错误，导入）
-     - 复杂修复（重构，逻辑）
-  3. 单独测试每个修复
-  4. 验证无回归
-```
-
-## 何时反驳
-
-当以下情况时反驳：
-- 建议破坏现有功能
-- 审查者缺乏完整上下文
-- 违反 YAGNI（未使用的功能）
-- 对这个技术栈技术上不正确
-- 存在遗留/兼容性原因
-- 与你的人类伙伴的架构决策冲突
-
-**如何反驳：**
-- 使用技术推理，而非防御性
-- 提出具体问题
-- 引用工作测试/代码
-- 如果是架构问题，让你的人类伙伴参与
-
-**如果不愿意大声反驳的信号：** "Circle K 有奇怪的事情发生"
-
-## 确认正确的反馈
-
-当反馈正确时：
-```
-✅ "已修复。[对更改的简要描述]"
-✅ "好发现 - [具体问题]。在 [位置] 已修复。"
-✅ [直接修复并在代码中显示]
-
-❌ "你绝对正确！"
-❌ "好观点！"
-❌ "感谢发现那个！"
-❌ "感谢 [任何内容]"
-❌ 任何感谢表达
-```
-
-**为什么不感谢：** 行动说话。直接修复。代码本身表明你听到了反馈。
-
-**如果你发现自己要写"谢谢"：** 删除它。改为说明修复。
-
-## 优雅地纠正你的反驳
-
-如果你反驳了但错了：
-```
-✅ "你是对的 - 我检查了 [X]，它确实 [Y]。现在实施。"
-✅ "验证了这一点，你是正确的。我最初的理解是错误的，因为 [原因]。正在修复。"
-
-❌ 冗长的道歉
-❌ 为你反驳的原因辩护
-❌ 过度解释
-```
-
-事实陈述纠正并继续。
-
-## 常见错误
-
-| 错误 | 修复 |
-|------|------|
-| 表演性同意 | 说明要求或直接行动 |
-| 盲目实施 | 首先对照代码库验证 |
-| 批量实施而不测试 | 一次一个，测试每个 |
-| 假设审查者是对的 | 检查是否破坏事物 |
-| 避免反驳 | 技术正确性 > 舒适度 |
-| 部分实施 | 首先澄清所有项目 |
-| 无法验证，仍继续 | 说明限制，请求方向 |
-
-## 真实示例
-
-**表演性同意（错误）：**
-```
-审查者："移除遗留代码"
-❌ "你绝对正确！让我移除那个..."
-```
-
-**技术验证（正确）：**
-```
-审查者："移除遗留代码"
-✅ "检查中... 构建目标是 10.15+，此 API 需要 13+。需要遗留代码以保持向后兼容。当前实现的 bundle ID 错误 - 修复它还是放弃 13 之前的支持？"
-```
-
-**YAGNI（正确）：**
-```
-审查者："实施带有数据库、日期过滤器、CSV 导出的适当指标跟踪"
-✅ "搜索代码库 - 没有调用此端点。移除它（YAGNI）？还是我遗漏了使用情况？"
-```
-
-**不清楚的项目（正确）：**
-```
-你的人类伙伴："修复项目 1-6"
-你理解 1,2,3,6。对 4,5 不清楚。
-✅ "理解 1,2,3,6。在实施之前需要澄清 4 和 5。"
-```
-
-## GitHub 线程回复
-
-在 GitHub 上回复内联审查评论时，在评论线程中回复（`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`），而不是作为顶级 PR 评论。
-
-## 底线
-
-**外部反馈 = 要评估的建议，不是要遵循的命令。**
-
-验证。提问。然后实施。
-
-无表演性同意。始终保持技术严谨。