sdd-skills 1.1.6 → 1.1.8

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.6",
+  "version": "1.1.8",
   "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,32 +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` 命令**压缩会话上下文。
+⚠️ **注意**：Backend Engineer **不触发** `/compact` 命令。
 
-### 触发时机
+### 为什么不触发 /compact
 
-在以下情况完成时触发 `/compact`：
-- **正常流程完成**：后端 OpenSpec 已批准，代码已实现并通过验证，已交付给 Tester
-- **修复流程完成**：收到 Tester 修复请求后，修复完成并已重新提测给 `/tester`
+- Backend Engineer 不是工作流的终点，后续还有 Code Reviewer → Tester → Git Engineer
+- 在修复循环中保持上下文连续性很重要（修复轮次、错误历史等）
+- `/compact` 只在工作流的**起点**（SAE）和**终点**（Git Engineer MR 成功）触发
 
-### 执行方式
+### 何时会触发 /compact
 
-```
-/compact
-```
-
-### 目的
-
-- 清理会话中的冗余上下文（代码实现细节、验证输出等）
-- 为下一个角色（Tester）提供干净的起点
-- 保持会话响应速度和质量
+- 当整个工作流完成时（Git Engineer MR 创建成功）
+- 当达到最大修复轮次需要人工介入时
 
 ## 在 Pre-Execution Review 中的角色
 
@@ -476,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

@@ -1,6 +1,6 @@
 ---
 name: code-reviewer
-description: 代码审查专家，负责代码质量、安全审查和规范检查。当测试通过需要代码审查时激活。检查代码风格、最佳实践、安全漏洞、性能问题，审查不通过时触发钉钉通知。
+description: 代码审查专家，负责代码质量、安全审查和规范检查。当代码实现完成需要代码审查时激活。检查代码风格、最佳实践、安全漏洞、性能问题，审查不通过时触发钉钉通知。
 ---
 
 # Code Reviewer
@@ -211,7 +211,7 @@ const HeavyComponent = defineAsyncComponent(() =>
 - [ ] 避免魔法数字，使用常量
 - [ ] 避免重复代码（DRY 原则）
 - [ ] 复杂逻辑有注释说明
-- [ ] 测试覆盖率达标（后端 >= 90%, 前端 >= 70%）
+- [ ] 测试覆盖率达标（后端 >= 90%, 前端 >= 90%）
 
 ```go
 // ❌ 可维护性问题：魔法数字
@@ -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 修复问题...
 
 📢 已发送钉钉通知（审查不通过）
 ```
@@ -393,7 +391,7 @@ npm audit
 - [ ] Pinia store 设计合理
 - [ ] 类型定义完整
 - [ ] 复杂逻辑有注释
-- [ ] 测试覆盖率 >= 70%
+- [ ] 测试覆盖率 >= 90%
 ```
 
 ## 钉钉通知集成
@@ -415,33 +413,26 @@ npm audit
 
 ## 与其他 Skills 的协作
 
-1. **上游**: 接收 Tester 验证通过的代码
+1. **上游**: 接收 Backend Engineer 和 Frontend Engineer 的代码实现
 2. **下游**:
-   - 审查通过 → 交给 Git Engineer
-   - 审查不通过 → 返回相应的 Engineer 修复
+   - 审查通过 → 交给 Tester 进行测试验证
+   - 审查不通过 → **自动调用** 对应 Engineer 修复 → 重新审查
 3. **并行**: 无
 
 ## 会话管理
 
-⚠️ **重要**：当 Code Reviewer 角色流程完成后，**必须执行 `/compact` 命令**压缩会话上下文。
-
-### 触发时机
+⚠️ **注意**：Code Reviewer **不触发** `/compact` 命令。
 
-在以下情况完成时触发 `/compact`：
-- **审查通过**：代码审查通过，已交付给 Git Engineer
-- **审查不通过**：已发送钉钉通知，问题已反馈给对应的 Engineer 修复
+### 为什么不触发 /compact
 
-### 执行方式
-
-```
-/compact
-```
+- Code Reviewer 不是工作流的终点，后续还有 Tester → Git Engineer
+- 在修复循环中保持上下文连续性很重要（审查问题、修复历史等）
+- `/compact` 只在工作流的**起点**（SAE）和**终点**（Git Engineer MR 成功）触发
 
-### 目的
+### 何时会触发 /compact
 
-- 清理会话中的冗余上下文（审查详情、自动化检查输出等）
-- 为下一个角色（Git Engineer）或修复角色提供干净的起点
-- 保持会话响应速度和质量
+- 当整个工作流完成时（Git Engineer MR 创建成功）
+- 当达到最大修复轮次需要人工介入时
 
 ## 在 Pre-Execution Review 中的角色
 
@@ -518,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 修复后重新提交审查]
 
 重新审查...
 
@@ -541,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,32 +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` 命令**压缩会话上下文。
+⚠️ **注意**：Frontend Engineer **不触发** `/compact` 命令。
 
-### 触发时机
+### 为什么不触发 /compact
 
-在以下情况完成时触发 `/compact`：
-- **正常流程完成**：前端 OpenSpec 已批准，代码已实现并通过验证，已交付给 Tester
-- **修复流程完成**：收到 Tester 修复请求后，修复完成并已重新提测给 `/tester`
+- Frontend Engineer 不是工作流的终点，后续还有 Code Reviewer → Tester → Git Engineer
+- 在修复循环中保持上下文连续性很重要（修复轮次、错误历史等）
+- `/compact` 只在工作流的**起点**（SAE）和**终点**（Git Engineer MR 成功）触发
 
-### 执行方式
+### 何时会触发 /compact
 
-```
-/compact
-```
-
-### 目的
-
-- 清理会话中的冗余上下文（组件代码、样式细节、验证输出等）
-- 为下一个角色（Tester）提供干净的起点
-- 保持会话响应速度和质量
+- 当整个工作流完成时（Git Engineer MR 创建成功）
+- 当达到最大修复轮次需要人工介入时
 
 ## 在 Pre-Execution Review 中的角色
 
@@ -670,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

@@ -1,6 +1,6 @@
 ---
 name: git-engineer
-description: Git工程师，负责代码提交、版本管理和MR创建。当代码审查通过需要提交代码时激活。执行预检测（lint/build/test）、规范化提交、创建GitLab MR，失败时触发钉钉通知。
+description: Git工程师，负责代码提交、版本管理和MR创建。当测试通过需要提交代码时激活。执行预检测（lint/build/test）、规范化提交、创建GitLab MR，失败时触发钉钉通知。
 ---
 
 # Git Engineer
@@ -56,7 +56,7 @@ npm run test:unit
 
 # 6. 检查覆盖率
 npm run test:coverage
-# 要求: >= 70%
+# 要求: >= 90%
 ```
 
 ✅ **预检测通过标准**：
@@ -74,8 +74,8 @@ npm run test:coverage
 - Lint 检查失败：5 个错误
 - 单元测试失败：2/15 测试用例
 
-建议操作：
-返回对应的 Engineer 修复问题
+🔄 自动修复：调用对应 Engineer 修复问题...
+修复完成后将走完整流程：Engineer → Code Reviewer → Tester → Git Engineer
 
 📢 已发送钉钉通知（预检测失败）
 ```
@@ -202,7 +202,7 @@ glab mr create \
 
 ## 测试结果
 - 后端覆盖率：92% (>= 90%)
-- 前端覆盖率：75% (>= 70%)
+- 前端覆盖率：92% (>= 90%)
 - E2E 测试：3/3 通过
 
 ## 验收标准
@@ -244,7 +244,7 @@ glab mr create
 
 ## 测试结果
 - 后端覆盖率：XX% (>= 90%)
-- 前端覆盖率：XX% (>= 70%)
+- 前端覆盖率：XX% (>= 90%)
 - E2E 测试：X/X 通过
 
 ## 验收标准
@@ -410,21 +410,29 @@ glab mr status
 
 ## 与其他 Skills 的协作
 
-1. **上游**: 接收 Code Reviewer 审查通过的代码
+1. **上游**: 接收 Tester 测试通过的代码
 2. **下游**:
    - 预检测通过 + MR 创建成功 → 工作流完成
-   - 预检测失败 → 返回对应的 Engineer 修复
+   - 预检测失败 → **自动调用** 对应 Engineer 修复 → 走完整流程回来（Code Reviewer → Tester → Git Engineer）
 3. **并行**: 无
 
 ## 会话管理
 
-⚠️ **重要**：当 Git Engineer 角色流程完成后，**必须执行 `/compact` 命令**压缩会话上下文。
+⚠️ **重要**：Git Engineer 是工作流的**终点**，在特定情况下触发 `/compact` 命令。
 
 ### 触发时机
 
-在以下情况完成时触发 `/compact`：
+**仅在以下情况触发 `/compact`**：
 - **MR 创建成功**：预检测通过，MR 已创建，整个 SDD 工作流完成
-- **预检测失败**：已发送钉钉通知，问题已反馈给对应的 Engineer 修复
+
+**不触发 /compact 的情况**：
+- **预检测失败**：问题自动反馈给 Engineer 修复，需要保持上下文以便后续修复循环
+
+### 为什么这样设计
+
+- Git Engineer 是工作流的终点，MR 成功代表整个工作流完成
+- 预检测失败时需要返回 Engineer 修复，保持上下文有助于追踪修复历史
+- `/compact` 只在工作流的**起点**（SAE）和**终点**（Git Engineer MR 成功）触发
 
 ### 执行方式
 
@@ -434,8 +442,8 @@ glab mr status
 
 ### 目的
 
-- 清理会话中的冗余上下文（预检测输出、Git 操作日志等）
-- 为可能的下一轮工作流或新任务提供干净的起点
+- 清理整个工作流的冗余上下文（需求分析、代码实现、测试、审查等）
+- 为下一个工作流或新任务提供干净的起点
 - 保持会话响应速度和质量
 
 ## 在 Pre-Execution Review 中的角色
@@ -467,7 +475,7 @@ glab mr status
 ✅ 类型检查：通过
 ✅ 编译检查：通过
 ✅ 单元测试：8/8 通过
-✅ 覆盖率：75% (>= 70%)
+✅ 覆盖率：92% (>= 90%)
 
 ✅ 所有预检测通过！
 

package/skills/notifier/SKILL.md

@@ -454,25 +454,18 @@ chmod +x test_notification.sh
 
 ## 会话管理
 
-⚠️ **重要**：当 Notifier 角色流程完成后，**必须执行 `/compact` 命令**压缩会话上下文。
+⚠️ **注意**：Notifier **不触发** `/compact` 命令。
 
-### 触发时机
+### 为什么不触发 /compact
 
-在以下情况完成时触发 `/compact`：
-- **通知发送成功**：钉钉通知已成功发送
-- **通知发送失败**：配置错误或发送失败，已输出错误信息
+- Notifier 是辅助角色，不是主工作流的一部分
+- 通知发送后通常会返回到调用它的 Skill 继续执行
+- `/compact` 只在工作流的**起点**（SAE）和**终点**（Git Engineer MR 成功）触发
 
-### 执行方式
+### 何时会触发 /compact
 
-```
-/compact
-```
-
-### 目的
-
-- 清理会话中的冗余上下文（Webhook 请求/响应、配置读取等）
-- 为调用者或下一个角色提供干净的起点
-- 保持会话响应速度和质量
+- 当整个工作流完成时（Git Engineer MR 创建成功）
+- 当达到最大修复轮次需要人工介入时
 
 ## 在 Pre-Execution Review 中的角色
 

package/skills/sae/SKILL.md

@@ -185,7 +185,7 @@ Response (401):
 ## 决策原则
 
 遵循以下技术决策优先级：
-1. **稳定性 > 性能 > 安全性 > 成本**
+1. **安全性 > 稳定性 > 性能 > 成本**
 2. **技术选型标准**:
    - 成熟度高，社区活跃
    - 团队熟悉程度
@@ -244,9 +244,15 @@ Response (401):
 
 ⚠️ **重要**：当 SAE 角色流程完成后，**必须执行 `/compact` 命令**压缩会话上下文。
 
+### 为什么 SAE 需要触发 /compact
+
+SAE 是工作流的**起点**，完成需求分析后：
+- 需求分析阶段的探索和讨论内容较多
+- 后续进入实现阶段，是相对独立的新阶段
+- 压缩后为 Engineer 提供干净的起点
+
 ### 触发时机
 
-在以下情况完成时触发 `/compact`：
 - 需求规格文档已生成并保存
 - Spec 文档、Proposal 文档、Tasks 文档已全部创建
 - 已向用户确认下一步交给 Backend Engineer 和 Frontend Engineer
@@ -257,12 +263,6 @@ Response (401):
 /compact
 ```
 
-### 目的
-
-- 清理会话中的冗余上下文
-- 为下一个角色（Backend/Frontend Engineer）提供干净的起点
-- 保持会话响应速度和质量
-
 ## 示例对话
 
 ```

package/skills/tester/SKILL.md

@@ -167,7 +167,7 @@ npm run test:e2e -- --project=chromium
 
 ✅ 验收标准：5/5 满足
 
-下一步请 Code Reviewer 进行代码审查。
+下一步请 Git Engineer 进行预检测和提交。
 ```
 
 **测试失败（自动修复中）**：
@@ -480,37 +480,31 @@ 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` 命令**压缩会话上下文。
+⚠️ **注意**：Tester **不触发** `/compact` 命令。
 
-### 触发时机
+### 为什么不触发 /compact
 
-在以下情况完成时触发 `/compact`：
-- **测试全部通过**：所有测试验证通过，已交付给 Code Reviewer
-- **达到最大修复轮次**：已尝试 3 轮自动修复仍失败，已发送钉钉通知请求人工介入
+- Tester 不是工作流的终点，后续还有 Git Engineer
+- 在修复循环中保持上下文连续性很重要（测试输出、错误日志、修复轮次记录等）
+- `/compact` 只在工作流的**起点**（SAE）和**终点**（Git Engineer MR 成功）触发
 
-### 执行方式
+### 何时会触发 /compact
 
-```
-/compact
-```
-
-### 目的
-
-- 清理会话中的冗余上下文（测试输出、错误日志、修复循环记录等）
-- 为下一个角色（Code Reviewer）提供干净的起点
-- 保持会话响应速度和质量
+- 当整个工作流完成时（Git Engineer MR 创建成功）
+- 当达到最大修复轮次需要人工介入时
 
 ## 在 Pre-Execution Review 中的角色
 
@@ -603,5 +597,5 @@ lhci autorun
 - E2E 测试：3/3 通过
 - 验收标准：5/5 满足
 
-下一步请 Code Reviewer 进行代码审查。
+下一步请 Git Engineer 进行预检测和提交。
 ```