@zhouhao4221/devflow-skills 0.2.0 → 0.3.1

package/plugins/req/skills/status/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: status
+description: |
+  查看需求状态 - 详细状态和进度
+---
+
+# 查看需求状态
+
+查看需求的详细状态和进度信息。
+
+## 命令格式
+
+```
+/req:status [REQ-XXX]
+```
+
+**说明**：编号可选，省略时自动选择最近活跃的需求。
+
+---
+
+## 执行流程
+
+### 0. 自动识别需求
+
+如果未提供 REQ-XXX 编号：
+
+按修改时间排序扫描角色对应的 active 目录（readonly 用缓存，primary 优先本地不存在时用缓存，未绑定只用本地）。无结果时提示创建；唯一时自动选中；多个时列表让用户输入序号选择。
+
+### 1. 解析存储路径（按角色）
+
+读取 `.claude/settings.local.json` 的 `requirementProject` 和 `requirementRole`，按角色确定路径：
+- `readonly`：根目录为 `~/.claude-requirements/projects/$PROJECT`
+- `primary`：本地根目录为 `docs/requirements`，缓存为备用
+- 未绑定：仅使用 `docs/requirements`
+
+### 2. 查找需求文档（按角色）
+
+**`primary` 角色**搜索位置（按优先级）：
+1. `$ACTIVE/REQ-XXX-*.md`（本地）
+2. `$COMPLETED/REQ-XXX-*.md`（本地）
+3. `$CACHE_ACTIVE/REQ-XXX-*.md`（本地不存在时）
+4. `$CACHE_COMPLETED/REQ-XXX-*.md`（本地不存在时）
+
+**`readonly` 角色**搜索位置：
+1. `$ACTIVE/REQ-XXX-*.md`（缓存）
+2. `$COMPLETED/REQ-XXX-*.md`（缓存）
+
+如果未找到：
+```
+❌ 未找到需求：REQ-XXX
+
+可用操作：
+- 查看所有需求：/req
+- 创建新需求：/req:new
+```
+
+### 3. 解析需求文档
+
+提取关键信息：
+- 元信息
+- 生命周期状态
+- 功能清单进度
+- 测试要点进度
+- 文件改动清单
+- 变更记录
+
+### 4. 输出详细状态
+
+```
+
+需求状态：REQ-001 部门渠道关联
+
+
+元信息
+编号：REQ-001
+状态：开发中
+优先级：P1
+创建日期：2026-01-07
+负责人：-
+数据来源：本地 (primary)
+项目：my-saas-product
+
+生命周期
+[x] 草稿         2026-01-07
+[x] 待评审       2026-01-07
+[x] ✅ 评审通过      2026-01-07
+[>] 开发中       2026-01-08 ← 当前
+[ ] 测试中
+[ ] 已完成
+
+功能清单（4/6 完成）
+[x] 部门渠道关联
+[x] 渠道范围校验
+[x] 获取可选渠道接口
+[x] 订单数据过滤
+[ ] Dashboard数据过滤      ← 进行中
+[ ] 缓存机制
+
+测试要点（0/8 完成）
+[ ] 部门创建时关联渠道
+[ ] 部门更新时修改渠道关联
+[ ] 上级部门未设置渠道，下级可任意选择
+[ ] 上级部门已设置渠道，下级必须设置且为子集
+[ ] 选择超出范围的渠道报错
+[ ] 订单列表按渠道正确过滤
+[ ] Dashboard 数据按渠道正确过滤
+[ ] 缓存正确失效
+
+文件改动（8/12 完成）
+已完成：
+internal/sys/model/sys_dept_channel_model.go ✅
+internal/sys/store/sys_dept_channel_store.go ✅
+internal/sys/biz/dept_channel.go ✅
+internal/sys/biz/sys_dept.go ✅
+internal/sys/controller/v1/sys_dept.go ✅
+pkg/api/core/v1/sys_dept.go ✅
+internal/sys/router.go ✅
+internal/oms/store/sales_order_store.go ✅
+
+待处理：
+internal/oms/biz/sales_order_biz.go
+internal/dashboard/store/sales_dashboard_store.go
+internal/dashboard/biz/sales_dashboard_biz.go
+docs/swagger/docs.go
+
+变更记录
+2026-01-07 初始版本
+
+评审记录
+2026-01-07 张三 通过 - 方案合理，可以开发
+
+
+
+可用操作：
+# primary 角色显示完整操作
+- 继续开发：/req:dev REQ-001
+- 编辑需求：/req:edit REQ-001
+- 进入测试：/req:test REQ-001
+
+# readonly 角色仅显示只读操作
+# - 查看需求列表：/req
+# - 查看模块：/req:modules
+```
+
+---
+
+## 简洁模式
+
+使用 `--brief` 参数输出简洁信息：
+
+```
+/req:status REQ-001 --brief
+```
+
+输出：
+```
+REQ-001 部门渠道关联
+状态：开发中 | 功能：4/6 | 测试：0/8
+```
+
+---
+
+## 批量查看
+
+查看所有活跃需求状态：
+
+```
+/req:status --all
+```
+
+输出：
+```
+活跃需求状态一览
+
+| 编号 | 标题 | 状态 | 功能进度 | 测试进度 |
+|------|------|------|---------|---------|
+| REQ-001 | 部门渠道关联 | 开发中 | 4/6 | 0/8 |
+| REQ-002 | 用户积分系统 | 待评审 | - | - |
+| REQ-003 | 订单导出优化 | 草稿 | - | - |
+```
+
+## 用户输入
+
+$ARGUMENTS

package/plugins/req/skills/test/SKILL.md

@@ -0,0 +1,431 @@
+---
+name: test
+description: |
+  需求测试 - 综合测试验证（回归 + 新建 + 交互验证）
+---
+
+> **重要**：本命令的测试文件位置、运行命令、环境启动命令均从项目 `docs/prompt/testing.md` 读取，不内置任何项目细节。文件不存在时打印创建提示（非阻塞），并回退到 `docs/prompt/architecture.md` 的「测试规范」章节。
+
+# 需求测试
+
+针对指定需求执行综合测试，包含三个层次：运行已有测试、引导创建新测试、交互验证测试要点。
+
+> **Audience:** Engineer
+> 存储路径和缓存同步规则见 [_storage.md](./_storage.md)
+
+## 命令格式
+
+```
+/req:test [REQ-XXX] [选项]
+```
+
+- 省略编号时自动选择「开发中」或「测试中」的需求
+- 多个候选时让用户选择
+
+### 选项
+
+| 选项 | 说明 |
+|-----|------|
+| `--failed` | 仅运行上次失败的测试 |
+| `--skip-ut` | 跳过 UT 阶段 |
+| `--skip-api` | 跳过 API 测试阶段 |
+| `--skip-e2e` | 跳过 E2E 测试阶段 |
+| `--force` | 某阶段失败时继续后续阶段 |
+
+---
+
+## 总体流程
+
+```
+1. 选择需求 & 前置检查
+2. 提取测试要点（业务维度）
+3. 识别变更范围（代码维度）
+4. 阶段一：UT 
+   回归：运行变更相关的已有 UT
+   新建：缺失时引导创建
+5. 阶段二：API 测试 
+   回归：运行已有 API 测试
+   新建：缺失时引导创建
+6. 阶段三：E2E 测试 
+   回归：运行已有 E2E 测试
+   新建：缺失时引导创建
+7. 交互验证：自动化未覆盖的测试要点
+8. 更新状态为「测试中」& 记录结果
+9. 汇总报告
+```
+
+每个阶段的模式都是：**先跑已有 → 发现缺失 → 引导新建**。
+
+---
+
+## 详细流程
+
+### 1. 选择需求
+
+- 指定编号 → 使用该需求
+- 未指定 → 查找可测试需求（状态为开发中/测试中）
+
+### 2. 前置检查
+
+- 状态必须为「开发中」或「测试中」
+- 检查功能点完成情况，有未完成时警告
+
+### 3. 提取测试要点
+
+从需求文档提取测试要点，作为整个测试过程的验证基准：
+
+```
+需求测试：REQ-001 <需求标题>
+
+测试要点（共 N 项）：
+
+API 测试：
+- [ ] <API 测试点 1>
+- [ ] <API 测试点 2>
+
+业务规则测试：
+- [ ] <业务规则测试点 1>
+- [ ] <业务规则测试点 2>
+
+数据权限测试：
+- [ ] <数据权限测试点 1>
+
+其他测试：
+- [ ] <其他测试点>
+```
+
+### 4. 识别变更范围
+
+从需求文档提取「文件改动清单」，定位本次需求涉及的源文件：
+
+```
+分析变更范围...
+
+从需求文档的「文件改动清单」提取：
+<source-file-1>
+<source-file-2>
+<source-file-3>
+<source-file-N>
+
+关联的测试文件：
+<test-file-1>               ✅ 存在
+<test-file-2>               ✅ 存在
+<test-file-3>               ❌ 不存在
+<test-file-N>               ✅ 存在
+```
+
+**变更范围识别规则**：
+
+1. **优先从需求文档**获取「文件改动清单」中列出的文件
+2. 如果文档中没有明确列出，则通过 `git diff` 对比当前分支与主分支的变更文件
+3. 按 `docs/prompt/testing.md` 定位关联测试文件
+
+---
+
+### 5. 阶段一：UT（变更相关）
+
+**仅运行本次需求变更相关的单元测试。**
+
+#### 5.1 回归 — 运行已有 UT
+
+```
+
+阶段一：单元测试（变更相关）
+
+
+运行已有 UT...
+
+<docs/prompt/testing.md 中定义的 UT 运行命令>
+
+<test-file-1>
+<TestCase_1>            ✅ PASS
+<TestCase_2>            ✅ PASS
+<TestCase_3>            ✅ PASS
+
+<test-file-2>
+<TestCase_4>            ✅ PASS
+<TestCase_5>            ✅ PASS
+
+UT 回归结果：N/N 通过 ✅
+
+测试要点覆盖：
+- [x] <测试要点> ← <对应测试用例>
+```
+
+自动化测试通过后，将能匹配的测试要点标记为已覆盖。
+
+#### 5.2 新建 — 引导补充缺失 UT
+
+```
+⚠️ 以下变更文件缺少 UT：
+- <test-file-missing>
+
+  y → 执行 /req:test_new REQ-001 --type=ut 的流程，生成缺失的测试文件
+  n → 记录为待补充，继续后续阶段
+  skip → 跳过，不再提示
+```
+
+---
+
+### 6. 阶段二：API 测试
+
+#### 6.0 环境检查
+
+API 测试需要 `docs/prompt/testing.md` 中定义的测试环境：
+
+```
+检查测试环境...
+<依赖服务 1>     ✅ 运行中
+<依赖服务 2>     ✅ 运行中
+<后端服务>       ✅ 运行中
+```
+
+如果未启动：
+
+```
+⚠️ 测试环境未就绪
+
+按 docs/prompt/testing.md 测试环境配置启动服务...
+<docs/prompt/testing.md 中定义的测试环境启动命令>
+
+等待服务就绪...
+<依赖服务 1>   ✅ 就绪
+<依赖服务 2>   ✅ 就绪
+<后端服务>     ✅ 就绪
+```
+
+#### 6.1 回归 — 运行已有 API 测试
+
+```
+
+阶段二：API 测试
+
+
+运行已有 API 测试...
+
+<docs/prompt/testing.md 中定义的 API 测试运行命令>
+
+<api-test-file>
+<TestCase_API_1>           ✅ PASS
+<TestCase_API_2>           ✅ PASS
+<TestCase_API_3>           ✅ PASS
+
+API 回归结果：N/N 通过 ✅
+
+测试要点覆盖：
+- [x] <API 测试要点> ← <对应测试用例>
+```
+
+#### 6.2 新建 — 引导补充缺失 API 测试
+
+```
+⚠️ 以下测试要点尚未被 API 测试覆盖：
+- [ ] <未覆盖的 API 测试要点>
+
+  y → 执行 /req:test_new REQ-001 --type=api 的流程
+  n → 记录为待补充，继续后续阶段
+  skip → 跳过
+```
+
+如果 API 测试目录下完全没有相关测试文件：
+
+```
+⚠️ 未找到需求相关的 API 测试文件
+
+  y → 执行 /req:test_new REQ-001 --type=api
+```
+
+---
+
+### 7. 阶段三：E2E 测试
+
+#### 7.0 环境检查
+
+E2E 测试额外需要前端服务：
+
+```
+检查测试环境...
+<依赖服务 1>     ✅ 运行中
+<依赖服务 2>     ✅ 运行中
+<后端服务>       ✅ 运行中
+<前端服务>       ❌ 未启动
+
+启动前端服务...
+<docs/prompt/testing.md 中定义的前端启动命令>
+<前端服务>  ✅ 就绪
+```
+
+#### 7.1 回归 — 运行已有 E2E 测试
+
+```
+
+阶段三：E2E 测试
+
+
+运行已有 E2E 测试...
+
+<docs/prompt/testing.md 中定义的 E2E 运行命令>
+
+  ✅ <E2E 场景描述 1> (Xs)
+  ✅ <E2E 场景描述 2> (Xs)
+
+E2E 回归结果：N/N 通过 ✅
+
+测试要点覆盖：
+- [x] <E2E 测试要点> ← <对应场景名>
+```
+
+#### 7.2 新建 — 引导补充缺失 E2E 测试
+
+```
+⚠️ 以下用户流程尚未被 E2E 覆盖：
+- [ ] <未覆盖的用户流程>
+
+  y → 执行 /req:test_new REQ-001 --type=e2e
+```
+
+如果 E2E 测试目录下完全没有相关测试文件：
+
+```
+⚠️ 未找到需求相关的 E2E 测试文件
+
+  y → 执行 /req:test_new REQ-001 --type=e2e
+  skip → 跳过 E2E 阶段
+```
+
+---
+
+### 8. 交互验证
+
+经过 UT/API/E2E 三个阶段后，检查测试要点的覆盖情况。对于**自动化测试未覆盖到的要点**，引导用户手动验证：
+
+```
+
+交互验证：自动化未覆盖的测试要点
+
+
+已自动覆盖 M/N 项，剩余 K 项需手动验证：
+
+【测试点 X】<测试要点描述>
+
+验证步骤：
+1. <操作步骤 1>
+2. <操作步骤 2>
+3. <预期结果>
+
+验证结果：
+- [ ] 通过
+- [ ] 失败（请描述问题）
+- [ ] 跳过
+
+请输入结果：
+```
+
+逐项引导验证，直到所有未覆盖要点完成。
+
+---
+
+### 9. 更新状态、记录测试结果并同步缓存
+
+测试完成后再更新状态：
+- 修改元信息状态为「测试中」
+- 勾选生命周期「测试中」
+- 更新需求文档的测试要点（勾选通过项，记录日期）
+- 记录自动化覆盖情况
+- **同步到全局缓存**
+
+### 10. 汇总报告
+
+```
+
+综合测试报告 - REQ-001 <需求标题>
+
+
+自动化测试：
+
+阶段     已有   新建   通过   失败   结果    
+
+UT       N      N      N      N      ✅ 通过  
+API      N      N      N      N      ✅ 通过  
+E2E      N      N      N      N      ✅ 通过  
+
+小计     N      N      N      N      ✅ 通过  
+
+
+测试要点覆盖：
+
+测试要点                              覆盖方式  结果    
+
+<测试要点 1>                          API 自动  ✅ 通过  
+<测试要点 2>                          UT 自动   ✅ 通过  
+<测试要点 3>                          E2E 自动  ✅ 通过  
+<测试要点 4>                          手动验证  ✅ 通过  
+
+合计 N/N                                       ✅ 全通过 
+
+```
+
+### 11. 下一步操作
+
+#### 全部通过
+
+```
+测试全部通过！
+
+REQ-001 <需求标题>
+状态：测试中
+自动化：N/N 通过
+测试要点：N/N 覆盖
+
+下一步：
+- 完成需求：/req:done REQ-001
+- 全量回归：/req:test_regression
+- 重新测试：/req:test REQ-001
+```
+
+#### 存在失败
+
+```
+⚠️ 存在测试失败项
+
+失败阶段：<阶段名>
+失败用例：
+- ❌ <失败用例名>
+  文件：<test-file>:<line>
+  原因：<失败原因描述>
+
+未覆盖测试要点：
+- ❌ <测试要点>（手动验证失败）
+  问题：<问题描述>
+
+下一步：
+- 返回修复：/req:dev REQ-001
+- 仅重跑失败：/req:test REQ-001 --failed
+- 忽略继续：/req:test REQ-001 --force
+```
+
+---
+
+## 测试模式说明
+
+### 综合测试（默认）
+按顺序执行 UT → API → E2E → 交互验证，某阶段失败时停止（除非 `--force`）。
+
+### 增量测试
+仅运行上次失败的用例：`/req:test REQ-XXX --failed`
+
+### 跳过某阶段
+```bash
+/req:test REQ-001 --skip-e2e         # 跳过 E2E
+/req:test REQ-001 --skip-ut          # 跳过 UT
+/req:test REQ-001 --skip-api         # 跳过 API
+```
+
+### 强制继续
+某阶段失败时继续后续阶段：`/req:test REQ-XXX --force`（不推荐）
+
+---
+
+## 用户输入
+
+$ARGUMENTS