sdd-workflow 1.1.0

package/templates/skills/sdd-tasks/SKILL.md

@@ -0,0 +1,199 @@
+---
+name: sdd-tasks
+description: 创建任务分解（Tasks）- 将技术计划和测试用例分解为可执行的开发任务
+invocable: true
+---
+
+# SDD Tasks - 任务分解生成器
+
+将技术计划和测试用例分解为可执行的开发任务，遵循测试优先原则。
+
+## ⚠️ 核心定位：Tasks 是技术实现的执行计划
+
+> Tasks 基于 plan.md 的技术方案进行任务拆分，可以包含具体的文件路径、代码片段和实现细节。
+> 这是 SDD 流程中最接近"代码"的文档之一。
+
+## 核心理念
+
+> **测试任务先行**
+
+每个实现任务都有对应的测试任务，确保：
+1. 先写测试，再写实现
+2. 测试通过才算任务完成
+3. 红-绿-重构的完整循环
+
+## 前置条件
+- 必须已有功能规格: `.specify/specs/{feature_id}/spec.md`
+- 必须已有技术计划: `.specify/specs/{feature_id}/plan.md`
+- **必须已有测试用例: `.specify/specs/{feature_id}/testcases.md`**
+
+## 执行步骤
+
+### 1. 读取关联文档
+- `.specify/specs/{feature_id}/spec.md` - 功能规格
+- `.specify/specs/{feature_id}/plan.md` - 技术计划
+- **`.specify/specs/{feature_id}/testcases.md` - 测试用例**
+- `.specify/memory/constitution.md` - 项目宪法
+
+### 2. 建立测试与实现的映射
+
+根据测试用例文档，建立测试用例与实现任务的映射关系：
+
+| 测试类型 | 对应实现任务 | 测试任务 |
+|----------|--------------|----------|
+| UT-* 单元测试 | 业务逻辑任务 | 对应测试任务 |
+| IT-* 集成测试 | 数据访问任务 | 对应测试任务 |
+| API-* 接口测试 | API层任务 | 对应测试任务 |
+| FT-* 前端测试 | 前端组件任务 | 对应测试任务 |
+| ST-* 状态测试 | 状态管理任务 | 对应测试任务 |
+
+### 3. 分析技术计划
+提取关键实现点：
+- 数据库变更
+- 后端接口
+- 前端组件
+- 测试要求
+
+### 3. 生成任务分解
+
+基于模板 `.specify/templates/tasks-template.md` 生成文档，包括：
+
+#### 标准阶段：
+
+##### Phase 0: 准备工作
+- 环境准备
+- 数据库准备（DDL执行）
+- 依赖安装
+- 测试数据准备
+
+##### Phase 1: 后端开发（测试优先）
+
+**每个实现任务遵循红-绿-重构：**
+```
+Task 1.X-T: 写测试 → Task 1.X: 写实现 → 测试通过
+```
+
+- 数据模型设计 [P]
+- **业务逻辑测试（先）** → 业务逻辑实现
+- 数据访问接口定义 [P]
+- **数据访问测试（先）** → 数据访问实现
+- **应用服务测试（先）** → 应用服务实现
+- **API接口测试（先）** → API层实现
+- 集成测试执行
+
+##### Phase 2: 前端开发（测试优先）
+
+**每个实现任务遵循红-绿-重构：**
+```
+Task 2.X-T: 写测试 → Task 2.X: 写实现 → 测试通过
+```
+
+- API服务层 [P]
+- **状态管理测试（先）** → 状态管理定义
+- **组件测试（先）** → 页面组件
+- 子组件开发
+- 路由配置
+
+##### Phase 3: 测试验收
+- E2E测试执行
+- 接口联调
+- 功能测试（执行testcases.md中的用例）
+- 代码Review
+- 文档更新
+
+> [P] 表示可并行执行的任务
+> **粗体** 表示测试任务（测试优先）
+
+### 4. 任务详情
+每个任务包含：
+- **描述**: 任务内容
+- **文件**: 涉及的文件路径（使用项目实际目录结构，参考 CLAUDE.md）
+- **依赖**: 前置任务
+- **状态**: 待执行/进行中/已完成
+- **验收标准**: 完成标准
+
+### 5. 保存文档
+保存到: `.specify/specs/{feature_id}/tasks.md`
+
+### 6. 检测文档大小
+
+tasks.md 超过 800 行时，自动执行 `/sdd-split tasks {feature_id} --auto` 拆分（在 sdd-run 中）或提示用户使用 `/sdd-split tasks {feature_id}`（手动模式下）。
+
+### 7. 输出摘要
+向用户展示任务概览和预估工时。
+
+## 输出示例
+
+```
+✅ 任务分解已生成: .specify/specs/001-user-authentication/tasks.md
+
+📊 任务概览：
+┌─────────────┬────────┬──────────┐
+│ 阶段        │ 任务数 │ 预估工时 │
+├─────────────┼────────┼──────────┤
+│ 准备工作    │ 2      │ 1h       │
+│ 后端开发    │ 7      │ 8h       │
+│ 前端开发    │ 5      │ 6h       │
+│ 测试验收    │ 4      │ 3h       │
+├─────────────┼────────┼──────────┤
+│ 总计        │ 18     │ 18h      │
+└─────────────┴────────┴──────────┘
+
+🔗 任务依赖图：
+Phase 0 ──→ Phase 1 ──→ Phase 2 ──→ Phase 3
+           (后端)      (前端)      (测试)
+
+📌 检查点：
+- Checkpoint 1: 后端开发完成
+- Checkpoint 2: 前端开发完成
+- Checkpoint 3: 功能验收完成
+
+请检查任务分解，如需调整请告诉我。
+```
+
+## 任务依赖规则
+
+### 串行依赖
+```
+Task 0.1 (环境准备)
+    ↓
+Task 0.2 (数据库准备)
+    ↓
+Task 1.1 (数据模型)
+    ↓
+Task 1.2 (数据访问接口)
+    ↓
+...
+```
+
+### 并行执行
+以下任务可以并行：
+- Task 1.1 (数据模型) 和 Task 1.2 (数据访问接口)
+- Task 2.1 (API服务) 和 Task 2.2 (状态管理)
+
+## 工时估算参考
+
+| 任务类型 | 复杂度 | 预估工时 |
+|----------|--------|----------|
+| 简单CRUD | 低 | 0.5h |
+| 带业务逻辑 | 中 | 1-2h |
+| 复杂业务 | 高 | 2-4h |
+| 单元测试 | - | 实现的30% |
+| 集成测试 | - | 1-2h |
+
+## 反馈触发点
+
+分解任务时，以下情况**必须触发向上反馈**：
+
+1. **plan 中有遗漏** → 任务分解发现缺少接口/组件/数据流设计，反馈回 plan 补充
+2. **plan 方案过度复杂** → 发现可简化实现路径，反馈回 plan 简化
+3. **测试用例与 plan 不匹配** → testcases 覆盖的场景在 plan 中无对应设计，双向确认
+
+反馈流程：在 tasks.md 中创建 CR 记录 → 修正 plan/testcases → 同步更新 tasks.md → 继续分解
+
+## 注意事项
+
+1. **文件路径**: 任务中涉及的文件路径应使用项目实际目录结构（参考 CLAUDE.md 和 constitution.md）
+2. **技术栈适配**: 任务描述应使用项目实际的技术术语和框架名称
+3. **测试优先**: 每个实现任务必须对应一个测试任务
+4. **阶段对齐**: 任务阶段划分应与 plan.md 中的阶段合约一致

package/templates/skills/sdd-testcases/SKILL.md

@@ -0,0 +1,235 @@
+---
+name: sdd-testcases
+description: 创建测试用例设计（Test Cases）- 在实现前定义测试场景、边界条件和验收标准。测试优先，确保实现有据可依。
+invocable: true
+---
+
+# SDD Test Cases - 测试用例设计器
+
+在实现前创建测试用例设计，遵循测试优先原则（Test-First Development）。
+
+## ⚠️ 内容边界：测试用例聚焦行为验证
+
+> 测试用例描述"系统应该表现出什么行为"，而非"系统如何实现"。
+> - 测试场景表格中用 **业务语言** 描述 Given/When/Then
+> - 代码骨架可以有，但应验证 **业务行为** 而非 **实现细节**
+> - 测试方法名用 **业务动作** 命名，不暴露内部实现方式
+
+### 示例对比
+
+**❌ 过度暴露实现**:
+```
+| UT-020 | checkManyLotNumberForSubLotItem-正常 | 父任务通过外键关联了子任务 | 调用checkManyLotNumberForSubLotItem | 通过 findEarliestSubTaskId 找到子任务 |
+```
+
+**✅ 聚焦行为验证**:
+```
+| UT-020 | 子投料单过滤-有关联子任务 | 父任务存在关联的子任务且有投料单数据 | 执行子投料单过滤 | 返回子任务的投料单列表，过滤通过 |
+```
+
+## 核心理念
+
+> **测试先行，实现有据**
+
+1. **先写测试，再写实现**: 每个功能点必须有对应的测试用例
+2. **测试即文档**: 测试用例描述系统期望行为
+3. **红-绿-重构**: 先让测试失败，再让测试通过
+4. **边界优先**: 优先覆盖边界条件和异常场景
+
+## 前置条件
+- 必须已有功能规格: `.specify/specs/{feature_id}/spec.md`
+- 推荐已有项目宪法: `.specify/memory/constitution.md`
+
+## 执行步骤
+
+### 1. 读取规格文档
+读取关联的功能规格: `.specify/specs/{feature_id}/spec.md`
+
+重点提取：
+- 用户故事和验收标准
+- 功能需求列表
+- 边界条件和异常处理
+- 非功能需求（性能等）
+
+### 2. 分析测试范围
+
+#### 2.1 后端测试范围
+- 领域服务/业务逻辑
+- 数据访问层操作
+- API接口契约
+- 边界条件和异常
+
+#### 2.2 前端测试范围
+- 组件渲染和交互
+- 状态管理
+- API调用和错误处理
+- 用户交互流程
+
+### 3. 设计测试用例
+
+#### 3.1 单元测试设计
+为每个业务方法设计：
+- 正常场景 (Happy Path)
+- 边界条件 (Boundary)
+- 异常场景 (Exception)
+- 空值/null处理
+
+#### 3.2 集成测试设计
+- 数据访问层CRUD操作
+- API接口请求响应
+- 数据库事务
+
+#### 3.3 前端测试设计
+- 组件渲染测试
+- 用户交互测试
+- 表单校验测试
+- 状态管理测试
+
+#### 3.4 E2E测试设计
+- 关键用户流程
+- 跨页面操作
+- 完整业务场景
+
+### 4. 生成测试代码骨架
+
+根据项目技术栈（参考 constitution.md）生成对应的测试代码骨架。使用项目测试框架编写示例代码。
+
+**根据 constitution.md 中的技术栈选择对应格式**：
+- 如果后端使用 Java/JVM：使用 JUnit + Mockito 风格
+- 如果后端使用 Go：使用标准 testing 包风格
+- 如果后端使用 Python：使用 pytest 风格
+- 如果前端使用 React：使用 Jest + React Testing Library 风格
+- 如果前端使用 Vue：使用 Vitest + Vue Test Utils 风格
+- 其他框架根据 constitution.md 中的测试框架配置
+
+### 5. 建立测试与实现的映射
+
+| 测试类型 | 关联任务 | 验证内容 |
+|----------|----------|----------|
+| 单元测试 | 后端业务逻辑任务 | 业务逻辑 |
+| 集成测试 | 数据访问任务 | 数据持久化 |
+| API测试 | API接口任务 | 接口契约 |
+| 前端测试 | 前端组件任务 | UI交互 |
+
+### 6. 保存文档
+保存到: `.specify/specs/{feature_id}/testcases.md`
+
+### 7. 输出摘要
+
+```
+✅ 测试用例设计已生成: .specify/specs/{feature_id}/testcases.md
+
+📊 测试用例统计：
+┌─────────────┬────────┬──────────┐
+│ 测试类型    │ 用例数 │ 优先级   │
+├─────────────┼────────┼──────────┤
+│ 单元测试    │ 15     │ P0       │
+│ 集成测试    │ 8      │ P0       │
+│ API测试     │ 10     │ P0       │
+│ 前端测试    │ 12     │ P0       │
+│ E2E测试     │ 3      │ P1       │
+│ 边界测试    │ 8      │ P0       │
+├─────────────┼────────┼──────────┤
+│ 总计        │ 56     │          │
+└─────────────┴────────┴──────────┘
+
+🔗 测试与实现映射：
+- UT-001~015 → 业务逻辑任务
+- IT-001~008 → 数据访问任务
+- API-001~010 → API接口任务
+- FT-001~012 → 前端组件任务
+
+📋 下一步：
+1. 审查测试用例设计
+2. 运行 /sdd-plan 生成技术实现计划
+3. 实现时先写测试，再写实现
+```
+
+## 测试用例设计规范
+
+### 命名规范
+
+#### 后端测试方法（通用格式）
+```
+格式: test_{方法名}_{场景}_{期望结果}
+
+示例:
+test_createOrder_validInput_success
+test_createOrder_nullInput_throwsException
+test_createOrder_insufficientStock_throwsException
+```
+
+#### 前端测试（通用格式）
+```
+格式: should {期望行为} when {条件}
+
+示例:
+should display error message when form is invalid
+should submit form when all fields are valid
+```
+
+### 测试用例ID规范
+
+| 前缀 | 类型 | 示例 |
+|------|------|------|
+| UT- | 单元测试 | UT-001, UT-002 |
+| IT- | 集成测试 | IT-001, IT-002 |
+| API- | API测试 | API-001, API-002 |
+| FT- | 前端测试 | FT-001, FT-002 |
+| ST- | Store/状态测试 | ST-001, ST-002 |
+| E2E- | 端到端测试 | E2E-001, E2E-002 |
+| B- | 边界测试 | B-001, B-002 |
+| PT- | 性能测试 | PT-001, PT-002 |
+
+### Gherkin格式
+
+使用 Given-When-Then 格式描述测试场景：
+
+```gherkin
+场景: UT-001 正常创建订单
+  Given 用户已登录
+  And 购物车中有商品
+  When 用户点击提交订单
+  Then 系统创建订单
+  And 订单状态为"待支付"
+```
+
+## 上下游关系
+
+- **上游**: spec.md → 本阶段
+- **下游**: 本阶段 → sdd-plan / sdd-tasks / sdd-implement
+
+## 反馈触发点
+
+设计测试用例时，以下情况**必须触发向上反馈**：
+
+1. **验收标准无法写出 Given-When-Then** → spec 中需求描述模糊，反馈回 spec 澄清
+2. **发现 spec 未覆盖的异常场景** → 补充到 spec 的用户故事/验收标准中
+3. **多个用户故事之间存在矛盾** → 反馈回 spec 统一逻辑
+
+反馈流程：在 testcases.md 中创建 CR 记录 → 修正 spec.md → 同步更新 testcases.md → 继续设计
+
+## 注意事项
+
+1. **覆盖边界**: 每个功能点至少包含正常+异常+边界三种测试
+2. **独立性**: 测试用例之间相互独立，可并行执行
+3. **可重复**: 测试结果可重复，不依赖外部状态
+4. **快速反馈**: 单元测试应快速执行，便于频繁运行
+5. **有意义的断言**: 断言应该验证业务价值，而非实现细节
+6. **测试数据**: 使用明确的测试数据，避免魔法数字
+7. **技术栈适配**: 测试代码示例使用项目实际测试框架（参考 constitution.md）
+
+## 示例输出
+
+```markdown
+## 1.1 单元测试
+
+### 测试目标: OrderService
+
+| ID | 测试场景 | Given | When | Then |
+|----|----------|-------|------|------|
+| UT-001 | 正常创建订单 | 购物车有商品，库存充足 | 调用createOrder | 返回订单ID |
+| UT-002 | 库存不足 | 购物车有商品，库存不足 | 调用createOrder | 抛出InsufficientStockException |
+| UT-003 | 购物车为空 | 购物车无商品 | 调用createOrder | 抛出EmptyCartException |
+| UT-004 | 用户未登录 | 当前用户为null | 调用createOrder | 抛出UnauthorizedException |
+```

package/templates/specify/README.md

@@ -0,0 +1,179 @@
+# SDD (Specification-Driven Development) Guide
+
+> This document describes how to use SDD specification for development in any project
+
+## Quick Start
+
+### 1. Create a New Feature
+
+Use the script to create a feature directory:
+```bash
+./.specify/scripts/create-feature.sh <feature-name>
+```
+
+Example:
+```bash
+./.specify/scripts/create-feature.sh user-authentication
+# Output: .specify/specs/001-user-authentication/
+```
+
+### 2. Using SDD Commands
+
+| Command | Function | Example |
+|---------|----------|---------|
+| `/sdd-constitution` | Create/update project constitution | `/sdd-constitution` |
+| `/sdd-specify` | Create feature specification | `/sdd-specify user authentication feature` |
+| `/sdd-plan` | Create technical plan | `/sdd-plan implement authentication with JWT` |
+| `/sdd-tasks` | Create task breakdown | `/sdd-tasks` |
+| `/sdd-implement` | Execute development tasks | `/sdd-implement` |
+
+## SDD Process
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│                    SDD Development Process                   │
+├─────────────────────────────────────────────────────────────┤
+│                                                             │
+│  1. Constitution  ->  Establish project principles & rules   │
+│         |                                                   │
+│  2. Specify      ->  Define requirements and user stories    │
+│         |                                                   │
+│  3. Plan         ->  Design technical solution & data model  │
+│         |                                                   │
+│  4. Tasks        ->  Break down development tasks            │
+│         |                                                   │
+│  5. Implement    ->  Execute development and validate        │
+│                                                             │
+└─────────────────────────────────────────────────────────────┘
+```
+
+## Directory Structure
+
+```
+.specify/
+├── memory/
+│   ├── constitution.md           # Project constitution (development principles)
+│   └── project-context.md        # Project context (optional)
+│
+├── specs/
+│   ├── 000-existing-modules/     # Documentation for existing modules
+│   │   ├── module-a/             # Module A
+│   │   └── module-b/             # Module B
+│   │
+│   └── 001-new-feature/          # New feature
+│       ├── spec.md               # Feature specification
+│       ├── testcases.md          # Test cases
+│       ├── plan.md               # Technical plan
+│       ├── tasks.md              # Task breakdown
+│       └── contracts/            # API contracts
+│           └── api-spec.json
+│
+├── templates/
+│   ├── constitution-template.md
+│   ├── spec-template.md
+│   ├── testcases-template.md
+│   ├── plan-template.md
+│   ├── tasks-template.md
+│   ├── spec-modular-template/
+│   ├── plan-modular-template/
+│   ├── tasks-modular-template/
+│   └── requirements/
+│
+├── scripts/
+│   └── create-feature.sh         # Create feature directory
+│
+└── README.md                     # This document
+```
+
+## Document Specification
+
+### Feature Specification (spec.md)
+
+Must include:
+- Feature overview (name, description, business background)
+- User stories (role, goal, value)
+- Functional requirements (core features, UI, data, interfaces)
+- Non-functional requirements (performance, security, compatibility)
+- Acceptance criteria (functional, quality, documentation)
+
+### Test Cases (testcases.md)
+
+Must include:
+- Test strategy (test pyramid, coverage targets)
+- Backend test cases (unit, integration, API)
+- Frontend test cases (component, store)
+- E2E test cases (critical user flows)
+- Boundary condition tests
+- Test execution plan
+
+### Technical Plan (plan.md)
+
+Must include:
+- Architecture design (overall architecture, module breakdown)
+- Data model (table design, entity classes)
+- API design (interface list, request/response format)
+- Frontend implementation (pages, components, state management)
+- Backend implementation (layered design, core classes)
+- Test plan (unit tests, integration tests)
+
+### Task Breakdown (tasks.md)
+
+Must include:
+- Task list (description, files, dependencies, acceptance criteria)
+- Phase breakdown (preparation, backend, frontend, testing)
+- Checkpoints (phase validation points)
+- Time estimates
+
+## Best Practices
+
+### 1. Documentation First
+- Complete specification documents before coding
+- Specification documents require team review
+
+### 2. Acceptance-Driven
+- Every feature has clear acceptance criteria
+- Test cases are based on acceptance criteria
+
+### 3. Progressive Refinement
+- Specification -> Plan -> Tasks, progressively refined
+- Each step can be traced back and modified
+
+### 4. Continuous Updates
+- Update documents when requirements change
+- Record technical decisions in plan documents
+
+### 5. Technology Stack Detection
+- SDD automatically detects your project's technology stack
+- Templates use placeholders that adapt to any stack
+- Constitution records the detected stack for reference
+
+## Documenting Existing Modules
+
+For existing modules, follow these steps to add documentation:
+
+```bash
+# 1. Create module directory
+mkdir -p .specify/specs/000-existing-modules/module-name
+
+# 2. Use SDD commands to analyze existing code and generate documentation
+# In Claude Code, run:
+/sdd-specify Analyze the module-name module and generate specification documentation
+```
+
+## FAQ
+
+### Q: Does SDD conflict with agile development?
+A: No. SDD emphasizes documentation first, but documents can be lightweight. User stories are specifications in SDD.
+
+### Q: Must all documents be completed before coding?
+A: Recommended but not required. For simple features, steps can be merged. The key is to have clear acceptance criteria.
+
+### Q: How to handle urgent requirements?
+A: Implement first, then add documentation. But at minimum, write the feature specification.
+
+### Q: How does SDD work with different technology stacks?
+A: SDD templates use placeholders like `{frontend_framework}`, `{backend_framework}`, `{database}` that are automatically filled based on your project. The constitution detects your stack and all subsequent documents reference it.
+
+---
+
+*For more questions, refer to the project constitution or contact the team*