sdd-skills 1.1.5 → 1.1.7

package/docs/workflow-guide.md

@@ -42,16 +42,18 @@ SAE (需求分析 + 架构设计)
                     ↓
               (前后端并行开发)
                     ↓
-            Tester (测试验证)
+         Code Reviewer (代码审查)  ← 先审查代码质量
                     ↓
-         Code Reviewer (代码审查)
+            Tester (测试验证)      ← 再进行功能测试
                     ↓
      Git Engineer (预检测 + 提交 + MR)
                     ↓
             完成 (等待 MR 批准)
 ```
 
-**注意**: Backend 和 Frontend Engineer 可以并行开发，通过 API 契约协作，无需等待对方完成。
+**注意**:
+- Backend 和 Frontend Engineer 可以并行开发，通过 API 契约协作，无需等待对方完成
+- **先 Code Review 后提测**：确保代码质量后再进行功能测试，避免测试通过但代码有设计缺陷的情况
 
 ---
 
@@ -273,33 +275,9 @@ SAE (需求分析 + 架构设计)
 - Pinia stores
 - 单元测试
 
-### 阶段 4: 测试验证 (Tester)
+### 阶段 4: 代码审查 (Code Reviewer)
 
-**输入**: 后端和前端代码实现
-
-**工作流程**:
-1. 读取需求规格和 OpenSpec
-2. 执行后端测试:
-   - 单元测试
-   - 集成测试
-   - 覆盖率检查 (>= 90%)
-3. 执行前端测试:
-   - 单元测试
-   - E2E 测试 (Playwright)
-   - 覆盖率检查 (>= 70%)
-4. 验收标准检查
-5. 生成测试报告
-
-**成功**: 交给 Code Reviewer
-**失败**: 返回对应 Engineer + 发送钉钉通知
-
-**输出**:
-- 测试报告
-- 覆盖率报告
-
-### 阶段 5: 代码审查 (Code Reviewer)
-
-**输入**: 通过测试的代码
+**输入**: 前后端代码实现
 
 **工作流程**:
 1. 读取需求规格和 OpenSpec
@@ -314,16 +292,40 @@ SAE (需求分析 + 架构设计)
    - 可维护性
 5. 生成审查报告
 
-**成功**: 交给 Git Engineer
-**失败**: 返回对应 Engineer + 发送钉钉通知
+**成功**: 交给 Tester
+**失败**: 返回对应 Engineer 修复 → 重新审查
 
 **输出**:
 - 代码审查报告
 - 问题清单 (如有)
 
+### 阶段 5: 测试验证 (Tester)
+
+**输入**: 审查通过的代码
+
+**工作流程**:
+1. 读取需求规格和 OpenSpec
+2. 执行后端测试:
+   - 单元测试
+   - 集成测试
+   - 覆盖率检查 (>= 90%)
+3. 执行前端测试:
+   - 单元测试
+   - E2E 测试 (Playwright)
+   - 覆盖率检查 (>= 90%)
+4. 验收标准检查
+5. 生成测试报告
+
+**成功**: 交给 Git Engineer
+**失败**: 返回对应 Engineer 修复 → Code Reviewer → Tester
+
+**输出**:
+- 测试报告
+- 覆盖率报告
+
 ### 阶段 6: 提交和 MR (Git Engineer)
 
-**输入**: 通过审查的代码
+**输入**: 测试通过的代码
 
 **工作流程**:
 1. 执行预检测:
@@ -335,7 +337,7 @@ SAE (需求分析 + 架构设计)
 5. 指定审查人和标签
 
 **成功**: 工作流完成 + 发送钉钉通知 (可选)
-**失败**: 返回对应 Engineer + 发送钉钉通知
+**失败**: 返回对应 Engineer 修复 → Code Reviewer → Tester → Git Engineer
 
 **输出**:
 - Git 提交

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sdd-skills",
-  "version": "1.1.5",
+  "version": "1.1.7",
   "description": "Spec-Driven Development Skills for Claude Code - SAE/ADE workflow automation",
   "type": "module",
   "main": "install.js",

package/skills/backend-engineer/SKILL.md

@@ -101,15 +101,16 @@ description: 高级Golang后端工程师，负责后端API设计与实现。当
    - 提交所有实现文件和测试文件
    - 确保已通过所有验证检查
 
-### 阶段3：修复模式（来自 Tester 的修复请求）
+### 阶段3：修复模式（来自 Code Reviewer 或 Tester 的修复请求）
 
-⚠️ **当收到 Tester 的修复请求时，执行此流程**
+⚠️ **当收到修复请求时，执行此流程**
 
 #### 1. 分析问题
 
-- 仔细阅读 Tester 提供的错误信息
+- 仔细阅读提供的错误信息
 - 定位问题代码文件和行号
-- 理解失败的测试用例和预期行为
+- 理解失败原因和预期行为
+- **识别修复来源**：来自 Code Reviewer 还是 Tester
 
 #### 2. 修复问题
 
@@ -122,6 +123,8 @@ description: 高级Golang后端工程师，负责后端API设计与实现。当
 | 编译错误 | 修复语法和类型错误 |
 | Lint 错误 | 按规范修正代码风格 |
 | API 响应错误 | 修复 Handler/Service 逻辑 |
+| 安全问题 | 修复 SQL 注入、密码明文等问题 |
+| 性能问题 | 修复 N+1 查询、缓存策略等问题 |
 
 #### 3. 本地验证
 
@@ -137,12 +140,12 @@ go test ./... -coverprofile=coverage.out
 go tool cover -func=coverage.out | grep total  # 确保 >= 90%
 ```
 
-#### 4. 自动重新提测
+#### 4. 自动重新提交审查
 
-✅ **修复并验证通过后，必须自动调用 `/tester` 重新提测**：
+✅ **修复并验证通过后，必须自动调用 `/code-reviewer` 重新审查**：
 
 ```
-/tester 后端修复已完成，请重新执行测试验证：
+/code-reviewer 后端修复已完成，请重新执行代码审查：
 
 修复内容：
 - [具体修复的问题描述]
@@ -155,7 +158,7 @@ go tool cover -func=coverage.out | grep total  # 确保 >= 90%
 - 覆盖率：✅ XX% (>= 90%)
 ```
 
-⚠️ **重要**：修复完成后 **必须自动调用 `/tester`**，无需等待人工指令！
+⚠️ **重要**：修复完成后 **必须自动调用 `/code-reviewer`**，无需等待人工指令！
 
 ## 代码规范
 
@@ -402,10 +405,25 @@ mockRepo.EXPECT().FindByEmail("test@example.com").Return(&user, nil)
 
 1. **上游**: 接收 SAE 生成的需求规格
 2. **并行**: 与 Frontend Engineer 并行工作，通过 API 契约协作
-3. **下游**: 代码完成后交给 Tester 进行测试
+3. **下游**: 代码完成后交给 Code Reviewer 进行代码审查
 4. **修复循环**:
-   - 收到 Tester 修复请求 → 修复问题 → 本地验证 → **自动调用** `/tester` 重新提测
-   - 循环直到测试全部通过
+   - 收到 Code Reviewer 或 Tester 修复请求 → 修复问题 → 本地验证 → **自动调用** `/code-reviewer` 重新审查
+   - Code Reviewer 通过后流转到 Tester，Tester 通过后流转到 Git Engineer
+
+## 会话管理
+
+⚠️ **注意**：Backend Engineer **不触发** `/compact` 命令。
+
+### 为什么不触发 /compact
+
+- Backend Engineer 不是工作流的终点，后续还有 Code Reviewer → Tester → Git Engineer
+- 在修复循环中保持上下文连续性很重要（修复轮次、错误历史等）
+- `/compact` 只在工作流的**起点**（SAE）和**终点**（Git Engineer MR 成功）触发
+
+### 何时会触发 /compact
+
+- 当整个工作流完成时（Git Engineer MR 创建成功）
+- 当达到最大修复轮次需要人工介入时
 
 ## 在 Pre-Execution Review 中的角色
 
@@ -454,9 +472,9 @@ mockRepo.EXPECT().FindByEmail("test@example.com").Return(&user, nil)
 - backend/internal/model/user.go
 - backend/tests/auth_test.go
 
-测试覆盖率：85%
+测试覆盖率：92%
 
 代码已提交到分支：feature/user-login
 
-下一步请 Tester 进行测试验证。
+下一步请 Code Reviewer 进行代码审查。
 ```

package/skills/code-reviewer/SKILL.md

@@ -281,7 +281,7 @@ npm audit
 2. 数据库查询使用了预加载，避免 N+1 问题
 3. 前端组件设计合理，可复用性强
 
-下一步请 Git Engineer 进行预检测和提交。
+下一步请 Tester 进行测试验证。
 ```
 
 **审查不通过**：
@@ -311,9 +311,7 @@ npm audit
 - 中等问题：1 个
 - 轻微问题：1 个
 
-建议操作：
-1. 返回 Backend Engineer 修复安全和性能问题
-2. 返回 Frontend Engineer 修复类型定义问题
+🔄 自动修复：调用对应 Engineer 修复问题...
 
 📢 已发送钉钉通知（审查不通过）
 ```
@@ -415,12 +413,27 @@ npm audit
 
 ## 与其他 Skills 的协作
 
-1. **上游**: 接收 Tester 验证通过的代码
+1. **上游**: 接收 Backend Engineer 和 Frontend Engineer 的代码实现
 2. **下游**:
-   - 审查通过 → 交给 Git Engineer
-   - 审查不通过 → 返回相应的 Engineer 修复
+   - 审查通过 → 交给 Tester 进行测试验证
+   - 审查不通过 → **自动调用** 对应 Engineer 修复 → 重新审查
 3. **并行**: 无
 
+## 会话管理
+
+⚠️ **注意**：Code Reviewer **不触发** `/compact` 命令。
+
+### 为什么不触发 /compact
+
+- Code Reviewer 不是工作流的终点，后续还有 Tester → Git Engineer
+- 在修复循环中保持上下文连续性很重要（审查问题、修复历史等）
+- `/compact` 只在工作流的**起点**（SAE）和**终点**（Git Engineer MR 成功）触发
+
+### 何时会触发 /compact
+
+- 当整个工作流完成时（Git Engineer MR 创建成功）
+- 当达到最大修复轮次需要人工介入时
+
 ## 在 Pre-Execution Review 中的角色
 
 提供代码审查视角评估：
@@ -496,12 +509,12 @@ npm audit
    ```
 
 建议操作：
-1. 返回 Backend Engineer 修复密码加密和 N+1 查询问题
-2. 返回 Frontend Engineer 添加 TypeScript 类型定义
+🔄 自动调用 /backend-engineer 修复密码加密和 N+1 查询问题
+🔄 自动调用 /frontend-engineer 添加 TypeScript 类型定义
 
 📢 已发送钉钉通知（审查不通过）
 
-[Backend Engineer 和 Frontend Engineer 修复后]
+[Backend Engineer 和 Frontend Engineer 修复后重新提交审查]
 
 重新审查...
 
@@ -519,7 +532,7 @@ npm audit
 2. 数据库查询优化到位，使用了预加载
 3. TypeScript 类型定义完整，类型安全
 
-下一步请 Git Engineer 进行预检测和提交。
+下一步请 Tester 进行测试验证。
 ```
 
 ## 参考资源

package/skills/frontend-engineer/SKILL.md

@@ -116,15 +116,16 @@ description: 高级前端工程师，擅长Vue和React多个框架。当需要
    - 提交所有实现文件和测试文件
    - 确保已通过所有验证检查
 
-### 阶段3：修复模式（来自 Tester 的修复请求）
+### 阶段3：修复模式（来自 Code Reviewer 或 Tester 的修复请求）
 
-⚠️ **当收到 Tester 的修复请求时，执行此流程**
+⚠️ **当收到修复请求时，执行此流程**
 
 #### 1. 分析问题
 
-- 仔细阅读 Tester 提供的错误信息
+- 仔细阅读提供的错误信息
 - 定位问题代码文件和行号
-- 理解失败的测试用例和预期行为
+- 理解失败原因和预期行为
+- **识别修复来源**：来自 Code Reviewer 还是 Tester
 
 #### 2. 修复问题
 
@@ -138,6 +139,8 @@ description: 高级前端工程师，擅长Vue和React多个框架。当需要
 | TypeScript 类型错误 | 修复类型定义和类型断言 |
 | 构建失败 | 修复编译错误和依赖问题 |
 | Lint 错误 | 按规范修正代码风格 |
+| 安全问题 | 修复 XSS、输入验证等问题 |
+| 性能问题 | 修复懒加载、虚拟滚动等问题 |
 
 #### 3. 本地验证
 
@@ -153,12 +156,12 @@ npm run test:unit
 npm run test:coverage  # 确保 >= 90%
 ```
 
-#### 4. 自动重新提测
+#### 4. 自动重新提交审查
 
-✅ **修复并验证通过后，必须自动调用 `/tester` 重新提测**：
+✅ **修复并验证通过后，必须自动调用 `/code-reviewer` 重新审查**：
 
 ```
-/tester 前端修复已完成，请重新执行测试验证：
+/code-reviewer 前端修复已完成，请重新执行代码审查：
 
 修复内容：
 - [具体修复的问题描述]
@@ -172,7 +175,7 @@ npm run test:coverage  # 确保 >= 90%
 - 覆盖率：✅ XX% (>= 90%)
 ```
 
-⚠️ **重要**：修复完成后 **必须自动调用 `/tester`**，无需等待人工指令！
+⚠️ **重要**：修复完成后 **必须自动调用 `/code-reviewer`**，无需等待人工指令！
 
 ## 代码规范
 
@@ -596,10 +599,25 @@ test('user can login', async ({ page }) => {
 
 1. **上游**: 接收 SAE 生成的需求规格
 2. **并行**: 与 Backend Engineer 并行工作，通过 API 契约协作
-3. **下游**: 代码完成后交给 Tester 进行 E2E 测试
+3. **下游**: 代码完成后交给 Code Reviewer 进行代码审查
 4. **修复循环**:
-   - 收到 Tester 修复请求 → 修复问题 → 本地验证 → **自动调用** `/tester` 重新提测
-   - 循环直到测试全部通过
+   - 收到 Code Reviewer 或 Tester 修复请求 → 修复问题 → 本地验证 → **自动调用** `/code-reviewer` 重新审查
+   - Code Reviewer 通过后流转到 Tester，Tester 通过后流转到 Git Engineer
+
+## 会话管理
+
+⚠️ **注意**：Frontend Engineer **不触发** `/compact` 命令。
+
+### 为什么不触发 /compact
+
+- Frontend Engineer 不是工作流的终点，后续还有 Code Reviewer → Tester → Git Engineer
+- 在修复循环中保持上下文连续性很重要（修复轮次、错误历史等）
+- `/compact` 只在工作流的**起点**（SAE）和**终点**（Git Engineer MR 成功）触发
+
+### 何时会触发 /compact
+
+- 当整个工作流完成时（Git Engineer MR 创建成功）
+- 当达到最大修复轮次需要人工介入时
 
 ## 在 Pre-Execution Review 中的角色
 
@@ -648,9 +666,9 @@ test('user can login', async ({ page }) => {
 - frontend/src/api/auth.ts
 - frontend/tests/unit/LoginForm.spec.ts
 
-测试覆盖率：75%
+测试覆盖率：92%
 
 代码已提交到分支：feature/user-login
 
-下一步请 Tester 进行 E2E 测试验证。
+下一步请 Code Reviewer 进行代码审查。
 ```

package/skills/git-engineer/SKILL.md

@@ -74,8 +74,8 @@ npm run test:coverage
 - Lint 检查失败：5 个错误
 - 单元测试失败：2/15 测试用例
 
-建议操作：
-返回对应的 Engineer 修复问题
+🔄 自动修复：调用对应 Engineer 修复问题...
+修复完成后将走完整流程：Engineer → Code Reviewer → Tester → Git Engineer
 
 📢 已发送钉钉通知（预检测失败）
 ```
@@ -410,12 +410,42 @@ glab mr status
 
 ## 与其他 Skills 的协作
 
-1. **上游**: 接收 Code Reviewer 审查通过的代码
+1. **上游**: 接收 Tester 测试通过的代码
 2. **下游**:
    - 预检测通过 + MR 创建成功 → 工作流完成
-   - 预检测失败 → 返回对应的 Engineer 修复
+   - 预检测失败 → **自动调用** 对应 Engineer 修复 → 走完整流程回来（Code Reviewer → Tester → Git Engineer）
 3. **并行**: 无
 
+## 会话管理
+
+⚠️ **重要**：Git Engineer 是工作流的**终点**，在特定情况下触发 `/compact` 命令。
+
+### 触发时机
+
+**仅在以下情况触发 `/compact`**：
+- **MR 创建成功**：预检测通过，MR 已创建，整个 SDD 工作流完成
+
+**不触发 /compact 的情况**：
+- **预检测失败**：问题自动反馈给 Engineer 修复，需要保持上下文以便后续修复循环
+
+### 为什么这样设计
+
+- Git Engineer 是工作流的终点，MR 成功代表整个工作流完成
+- 预检测失败时需要返回 Engineer 修复，保持上下文有助于追踪修复历史
+- `/compact` 只在工作流的**起点**（SAE）和**终点**（Git Engineer MR 成功）触发
+
+### 执行方式
+
+```
+/compact
+```
+
+### 目的
+
+- 清理整个工作流的冗余上下文（需求分析、代码实现、测试、审查等）
+- 为下一个工作流或新任务提供干净的起点
+- 保持会话响应速度和质量
+
 ## 在 Pre-Execution Review 中的角色
 
 提供 Git 和 CI/CD 视角评估：

package/skills/notifier/SKILL.md

@@ -452,6 +452,21 @@ chmod +x test_notification.sh
 2. **被动角色**: Notifier 不主动判断，只负责接收参数并发送通知
 3. **独立运行**: 不依赖其他 Skills，可独立测试
 
+## 会话管理
+
+⚠️ **注意**：Notifier **不触发** `/compact` 命令。
+
+### 为什么不触发 /compact
+
+- Notifier 是辅助角色，不是主工作流的一部分
+- 通知发送后通常会返回到调用它的 Skill 继续执行
+- `/compact` 只在工作流的**起点**（SAE）和**终点**（Git Engineer MR 成功）触发
+
+### 何时会触发 /compact
+
+- 当整个工作流完成时（Git Engineer MR 创建成功）
+- 当达到最大修复轮次需要人工介入时
+
 ## 在 Pre-Execution Review 中的角色
 
 不参与 Pre-Execution Review，因为 Notifier 是纯执行角色，不涉及技术评估。

package/skills/sae/SKILL.md

@@ -240,6 +240,29 @@ Response (401):
    - 评估架构复杂度
    - 评估技术方案可行性
 
+## 会话管理
+
+⚠️ **重要**：当 SAE 角色流程完成后，**必须执行 `/compact` 命令**压缩会话上下文。
+
+### 为什么 SAE 需要触发 /compact
+
+SAE 是工作流的**起点**，完成需求分析后：
+- 需求分析阶段的探索和讨论内容较多
+- 后续进入实现阶段，是相对独立的新阶段
+- 压缩后为 Engineer 提供干净的起点
+
+### 触发时机
+
+- 需求规格文档已生成并保存
+- Spec 文档、Proposal 文档、Tasks 文档已全部创建
+- 已向用户确认下一步交给 Backend Engineer 和 Frontend Engineer
+
+### 执行方式
+
+```
+/compact
+```
+
 ## 示例对话
 
 ```

package/skills/tester/SKILL.md

@@ -167,7 +167,7 @@ npm run test:e2e -- --project=chromium
 
 ✅ 验收标准：5/5 满足
 
-下一步请 Code Reviewer 进行代码审查。
+下一步请 Git Engineer 进行预检测和提交。
 ```
 
 **测试失败（自动修复中）**：
@@ -480,16 +480,32 @@ lhci autorun
 
 ## 与其他 Skills 的协作
 
-1. **上游**: 接收 Backend Engineer 和 Frontend Engineer 的代码实现
+1. **上游**: 接收 Code Reviewer 审查通过的代码
 2. **自动修复循环**:
-   - 后端测试失败 → **自动调用** `/backend-engineer` 修复 → 重测
-   - 前端测试失败 → **自动调用** `/frontend-engineer` 修复 → 重测
+   - 后端测试失败 → **自动调用** `/backend-engineer` 修复
+   - 前端测试失败 → **自动调用** `/frontend-engineer` 修复
+   - Engineer 修复后会重新提交给 Code Reviewer → 审查通过后流转回 Tester
    - 循环直到全部通过或达到最大修复轮次(3轮)
 3. **下游**:
-   - 测试通过 → 交给 Code Reviewer
+   - 测试通过 → 交给 Git Engineer
    - 超过 3 轮仍失败 → 发送钉钉通知，请求人工介入
 4. **并行**: 无
 
+## 会话管理
+
+⚠️ **注意**：Tester **不触发** `/compact` 命令。
+
+### 为什么不触发 /compact
+
+- Tester 不是工作流的终点，后续还有 Git Engineer
+- 在修复循环中保持上下文连续性很重要（测试输出、错误日志、修复轮次记录等）
+- `/compact` 只在工作流的**起点**（SAE）和**终点**（Git Engineer MR 成功）触发
+
+### 何时会触发 /compact
+
+- 当整个工作流完成时（Git Engineer MR 创建成功）
+- 当达到最大修复轮次需要人工介入时
+
 ## 在 Pre-Execution Review 中的角色
 
 提供测试策略评估：
@@ -581,5 +597,5 @@ lhci autorun
 - E2E 测试：3/3 通过
 - 验收标准：5/5 满足
 
-下一步请 Code Reviewer 进行代码审查。
+下一步请 Git Engineer 进行预检测和提交。
 ```