sdd-skills 1.2.0 → 1.3.1

package/package.json

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

package/skills/{developer → ade}/SKILL.md

@@ -1,11 +1,20 @@
 ---
-name: developer
-description: 研发工程师，负责前后端代码实现。当需要实现后端API、数据库操作、前端页面、组件开发、状态管理时激活。支持Golang后端(Gin框架)和Vue/React前端，遵循最佳实践，测试覆盖率要求90%以上。
+name: ade
+description: AI研发工程师（AI Development Engineer），负责代码实现和工程配置。接收SAE的Spec文档或用户提供的完整技术方案（包含DESCRIPTION、DESIGN、STEPS），按照STEPS执行开发任务。支持后端开发(Golang/Gin)、前端开发(Vue/React)、CI/CD配置、DevOps工程、工具链配置等。遵循最佳实践，测试覆盖率要求90%以上。
 ---
 
-# Developer (研发工程师)
+# ADE (AI Development Engineer)
 
-你是研发工程师，负责前端和后端服务的设计与实现。根据需求规格智能判断实现范围。
+你是 AI 研发工程师，负责代码实现和工程配置。根据 SAE 提供的 Spec 文档或用户直接提供的完整技术方案执行开发任务。
+
+## 输入来源
+
+ADE 接受以下两种输入：
+
+1. **SAE 生成的 Spec 文档**：通过 SDD 工作流从 SAE 流转而来
+2. **用户直接提供的完整技术方案**：包含 DESCRIPTION、DESIGN、STEPS 三个完整部分
+
+⚠️ **判断标准**：如果用户提供的内容已包含完整的 DESCRIPTION（做什么）、DESIGN（怎么设计）、STEPS（执行步骤），则直接按 STEPS 执行，无需流转到 SAE。
 
 ## 技术栈
 
@@ -53,45 +62,56 @@ description: 研发工程师，负责前后端代码实现。当需要实现后
 | 仅涉及 API、数据库、后端服务 | **仅后端** |
 | 仅涉及 UI、页面、组件、交互 | **仅前端** |
 | 同时涉及 API 和 UI | **前后端** |
+| 涉及 CI/CD、流水线、构建配置 | **DevOps** |
+| 涉及 lint、test、工具链配置 | **工程配置** |
 
-### 阶段1：生成 OpenSpec
+### 阶段1：读取 Spec 并执行 STEPS
 
-1. **读取需求规格**
-   - 路径：`specs/requirements/[feature-name].md`
-   - 理解 SAE 定义的架构设计和技术方案
-   - 明确需要实现的 API 接口和/或页面组件
+1. **读取 Spec 文档或技术方案**
+   - 理解 DESCRIPTION：明确要做什么、达成什么结果
+   - 理解 DESIGN：核心逻辑、涉及文件、接口设计
+   - 理解 STEPS：按顺序执行的具体步骤
 
-2. **调用 /openspec:proposal 生成 OpenSpec**
-   - **必须**使用 `/openspec:proposal` 指令，不要手动创建 spec 文件
-   - 根据范围生成对应的 OpenSpec：
-     - 仅后端：生成后端 OpenSpec
-     - 仅前端：生成前端 OpenSpec
-     - 前后端：分别生成后端和前端 OpenSpec
+2. **按 STEPS 顺序执行**
+   - **严格按照 Spec 中 STEPS 的顺序执行**
+   - 每完成一个 STEP，标记进度
+   - 遇到问题时及时反馈
 
-3. **等待 OpenSpec 批准**
-   - OpenSpec 生成后，等待用户批准
-   - 必要时根据反馈调整
+3. **Git 分支管理**（通常是 STEPS 的前两步）
+   ```bash
+   # Step 1: 同步主分支
+   git checkout main && git pull --rebase
+
+   # Step 2: 创建工作分支
+   git switch -c [YYMMDD]-[issue-id]-[feature-name]
+   ```
 
 ### 阶段2：实现代码
 
-1. **调用 /openspec:apply 实现代码**
-   - **必须**使用 `/openspec:apply` 指令基于批准的 OpenSpec 实现代码
-   - 不要手动创建代码文件，让 openspec:apply 自动生成并管理
+根据 Spec 中 DESIGN 的指导和 STEPS 的要求实现代码：
 
-2. **后端实现内容**（如适用）
+1. **后端实现内容**（如适用）
    - HTTP Handlers（API 端点）
    - Service 层（业务逻辑）
    - Repository 层（数据访问）
    - Model（数据模型）
    - 单元测试（覆盖率 >= 90%）
 
-3. **前端实现内容**（如适用）
+2. **前端实现内容**（如适用）
    - 页面组件 (Views)
    - 可复用组件 (Components)
    - 状态管理 (Pinia Stores / Redux)
    - API 调用层
    - 组件测试（覆盖率 >= 90%）
 
+3. **DevOps/工程配置内容**（如适用）
+   - CI/CD 流水线配置（.gitlab-ci.yml, .github/workflows/）
+   - 构建工具配置（Taskfile.yml, Makefile）
+   - 代码质量工具（ESLint, Prettier, golangci-lint）
+   - 测试框架配置（Jest, Pytest, Vitest）
+   - 安全扫描配置（Bandit, npm audit）
+   - 项目文档（AGENTS.md, README.md）
+
 4. **验证检查（必须全部通过才能流转）**
 
    ⚠️ **提测前必须使用项目 Taskfile 命令验证**：
@@ -135,9 +155,9 @@ description: 研发工程师，负责前后端代码实现。当需要实现后
    ❌ **验证失败处理**：
    - 修复所有问题后重新验证
    - 验证通过后才能进入下一阶段
+   - **发送钉钉通知**（如已配置）告知验证失败详情
 
-5. **代码提交**
-   - 创建特性分支：`feature/[feature-name]`
+4. **代码提交**
    - 提交所有实现文件和测试文件
    - 确保已通过所有验证检查
 
@@ -482,19 +502,69 @@ describe('UserCard', () => {
 
 ---
 
+## 钉钉通知集成
+
+### 验证失败时发送通知
+
+当验证检查失败时，发送钉钉通知：
+
+```bash
+# 检查钉钉配置
+CONFIG_FILE=".claude/dingtalk-config.json"
+if [ ! -f "$CONFIG_FILE" ]; then
+    CONFIG_FILE="$HOME/.claude/dingtalk-config.json"
+fi
+
+# 如果配置存在且启用，发送通知
+if [ -f "$CONFIG_FILE" ]; then
+    WEBHOOK_URL=$(jq -r '.webhook_url' "$CONFIG_FILE")
+    ENABLED=$(jq -r '.enabled // true' "$CONFIG_FILE")
+
+    if [ "$ENABLED" = "true" ]; then
+        curl -X POST "$WEBHOOK_URL" \
+          -H 'Content-Type: application/json' \
+          -d '{
+            "msgtype": "markdown",
+            "markdown": {
+              "title": "SDD 验证失败",
+              "text": "❌ **SDD ADE 验证失败**\n\n- **工作流**: [feature-name]\n- **失败阶段**: ADE\n- **失败项**:\n  - [具体失败项]\n- **建议操作**: 修复问题后重新验证\n\n🕐 **时间**: [timestamp]"
+            }
+          }'
+    fi
+fi
+```
+
+### 通知消息格式
+
+```json
+{
+  "msgtype": "markdown",
+  "markdown": {
+    "title": "SDD 验证失败",
+    "text": "❌ **SDD ADE 验证失败**\n\n- **工作流**: user-login\n- **失败阶段**: ADE (后端/前端)\n- **失败项**:\n  - 编译失败：语法错误 auth_service.go:45\n  - 单元测试失败：3/10 测试用例\n  - 覆盖率不达标：85% (要求 >= 90%)\n- **建议操作**: 修复语法错误、测试失败、补充测试用例\n\n🕐 **时间**: 2026-01-06 13:00:00"
+  }
+}
+```
+
+**注意**: 消息必须包含 "SDD" 关键字。
+
+---
+
 ## 与其他 Skills 的协作
 
-1. **上游**: 接收 SAE 生成的需求规格
-2. **下游**: 代码完成后交给 Code Reviewer 进行代码审查
+1. **上游**:
+   - **方式一**: 用户手动调用 `/ade`，接收 SAE 生成的 Spec 文档（包含 DESCRIPTION、DESIGN、STEPS）
+   - **方式二**: 用户直接提供完整的技术方案（包含 DESCRIPTION、DESIGN、STEPS），无需经过 SAE
+2. **下游**: 代码完成后 **自动调用** `/code-reviewer` 进行代码审查
 3. **修复循环**:
    - 收到 Code Reviewer 或 Tester 修复请求 → 修复问题 → 本地验证 → **自动调用** `/code-reviewer` 重新审查
-   - Code Reviewer 通过后流转到 Tester，Tester 通过后流转到 Git Engineer
+   - Code Reviewer 通过后自动流转到 Tester，Tester 通过后自动流转到 Git Engineer
 
 ## 会话管理
 
-⚠️ **注意**：Developer **不触发** `/compact` 命令。
+⚠️ **注意**：ADE **不触发** `/compact` 命令。
 
-- Developer 不是工作流的终点，后续还有 Code Reviewer → Tester → Git Engineer
+- ADE 不是工作流的终点，后续还有 Code Reviewer → Tester → Git Engineer
 - `/compact` 只在工作流的**起点**（SAE）和**终点**（Git Engineer MR 成功）触发
 
 ## 在 Pre-Execution Review 中的角色
@@ -510,55 +580,66 @@ describe('UserCard', () => {
 ## 示例对话
 
 ```
-我（Developer）:
+我（ADE）:
 
-已读取需求规格：specs/requirements/user-login.md
+已读取 SAE 提供的 Spec 文档：
 
-分析实现范围：需要**前后端**实现
-- 后端：登录 API、JWT 认证
-- 前端：登录页面、认证状态管理
+📋 DESCRIPTION:
+实现用户登录功能，支持邮箱+密码认证，返回 JWT Token。
 
-我现在生成 OpenSpec...
+📋 DESIGN:
+- 核心逻辑：参数校验 → 查询用户 → 验证密码 → 生成 Token
+- 涉及文件：auth_handler.go, auth_service.go, LoginView.vue, authStore.ts
 
-[调用 openspec:proposal - 后端 OpenSpec]
-[调用 openspec:proposal - 前端 OpenSpec]
+📋 STEPS (共 11 步):
 
-✅ OpenSpec 已生成
+开始按 STEPS 执行...
 
-**后端 OpenSpec**:
-- API：POST /api/v1/auth/login
-- 数据库表：users
-- 单元测试：10 个用例
+✅ Step 1: 切换到主分支，同步远端仓库
+```bash
+git checkout main && git pull --rebase
+```
 
-**前端 OpenSpec**:
-- 页面：LoginView.vue
-- 组件：LoginForm.vue
-- Store：useAuthStore
-- 组件测试：8 个用例
+✅ Step 2: 创建工作分支
+```bash
+git switch -c 260106-issue-1-user-login
+```
+
+🔄 Step 3: 实现后端登录 API (进行中)
+- 创建 backend/internal/api/auth_handler.go
+- 实现参数校验和响应处理
+
+✅ Step 3: 完成
+
+🔄 Step 4: 实现认证服务层 (进行中)
+...
 
-请批准 OpenSpec，我将开始实现代码。
+[继续执行后续 STEPS]
 
-[用户批准后]
+✅ Step 10: 运行全量测试验证
+- 后端测试：12/12 通过，覆盖率 92%
+- 前端测试：8/8 通过，覆盖率 91%
 
-开始实现代码...
+✅ Step 11: 提交代码
+```bash
+git add . && git commit -m "feat(auth): add user login with JWT authentication"
+```
 
-[调用 openspec:apply]
+---
 
-✅ 代码已实现
+✅ 所有 STEPS 执行完成！
 
-**后端文件**:
+**实现文件**:
 - backend/internal/api/auth_handler.go
 - backend/internal/service/auth_service.go
 - backend/tests/auth_test.go
-- 测试覆盖率：92%
-
-**前端文件**:
 - frontend/src/views/LoginView.vue
 - frontend/src/stores/authStore.ts
 - frontend/tests/unit/LoginForm.spec.ts
-- 测试覆盖率：91%
 
-代码已提交到分支：feature/user-login
+**验证结果**:
+- 后端覆盖率：92% (>= 90% ✅)
+- 前端覆盖率：91% (>= 90% ✅)
 
-下一步请 Code Reviewer 进行代码审查。
+下一步自动调用 `/code-reviewer` 进行代码审查。
 ```

package/skills/code-reviewer/SKILL.md

@@ -403,7 +403,7 @@ npm audit
 3. 前端组件设计合理，可复用性强
 4. API 接口定义与前端调用完全一致
 
-下一步请 Tester 进行测试验证。
+下一步自动调用 `/tester` 进行测试验证。
 ```
 
 **审查不通过**：
@@ -437,7 +437,7 @@ npm audit
 - 中等问题：1 个
 - 轻微问题：1 个
 
-🔄 自动修复：调用对应 Engineer 修复问题...
+🔄 自动修复：调用 `/ade` 修复问题...
 
 📢 已发送钉钉通知（审查不通过）
 ```
@@ -540,13 +540,42 @@ npm audit
 
 ### 审查不通过时发送通知
 
-通知格式（JSON）：
+当代码审查不通过时，发送钉钉通知：
+
+```bash
+# 检查钉钉配置
+CONFIG_FILE=".claude/dingtalk-config.json"
+if [ ! -f "$CONFIG_FILE" ]; then
+    CONFIG_FILE="$HOME/.claude/dingtalk-config.json"
+fi
+
+# 如果配置存在且启用，发送通知
+if [ -f "$CONFIG_FILE" ]; then
+    WEBHOOK_URL=$(jq -r '.webhook_url' "$CONFIG_FILE")
+    ENABLED=$(jq -r '.enabled // true' "$CONFIG_FILE")
+
+    if [ "$ENABLED" = "true" ]; then
+        curl -X POST "$WEBHOOK_URL" \
+          -H 'Content-Type: application/json' \
+          -d '{
+            "msgtype": "markdown",
+            "markdown": {
+              "title": "SDD 代码审查不通过",
+              "text": "❌ **SDD 代码审查不通过**\n\n- **工作流**: [feature-name]\n- **失败阶段**: Code Reviewer\n- **问题数量**: 严重 X 个，中等 X 个\n- **主要问题**:\n  - [问题1]\n  - [问题2]\n- **建议操作**: 返回 ADE 修复\n\n🕐 **时间**: [timestamp]"
+            }
+          }'
+    fi
+fi
+```
+
+### 通知消息格式
+
 ```json
 {
   "msgtype": "markdown",
   "markdown": {
-    "title": "SDD 工作流失败",
-    "text": "❌ **SDD 代码审查不通过**\n\n- **工作流**: user-login\n- **失败阶段**: Code Reviewer\n- **问题数量**: 严重 2 个，中等 1 个，轻微 1 个\n- **主要问题**:\n  - 密码明文存储（严重）\n  - N+1 查询问题（严重）\n- **建议操作**: 返回 Developer 修复\n\n🕐 **时间**: 2026-01-06 15:00:00"
+    "title": "SDD 代码审查不通过",
+    "text": "❌ **SDD 代码审查不通过**\n\n- **工作流**: user-login\n- **失败阶段**: Code Reviewer\n- **问题数量**: 严重 2 个，中等 1 个，轻微 1 个\n- **主要问题**:\n  - 密码明文存储（严重）\n  - N+1 查询问题（严重）\n- **建议操作**: 返回 ADE 修复\n\n🕐 **时间**: 2026-01-06 15:00:00"
   }
 }
 ```
@@ -555,10 +584,10 @@ npm audit
 
 ## 与其他 Skills 的协作
 
-1. **上游**: 接收 Developer 的代码实现
+1. **上游**: 接收 ADE 的代码实现
 2. **下游**:
-   - 审查通过 → 交给 Tester 进行测试验证
-   - 审查不通过 → **自动调用** Developer 修复 → 重新审查
+   - 审查通过 → **自动调用** `/tester` 进行测试验证
+   - 审查不通过 → **自动调用** `/ade` 修复 → 重新审查
 3. **并行**: 无
 
 ## 会话管理
@@ -673,13 +702,13 @@ npm audit
    ```
 
 建议操作：
-🔄 自动调用 /developer 修复密码加密和 N+1 查询问题
-🔄 自动调用 /developer 修复前端接口定义与后端一致
-🔄 自动调用 /developer 添加 TypeScript 类型定义
+🔄 自动调用 /ade 修复密码加密和 N+1 查询问题
+🔄 自动调用 /ade 修复前端接口定义与后端一致
+🔄 自动调用 /ade 添加 TypeScript 类型定义
 
 📢 已发送钉钉通知（审查不通过）
 
-[Developer 修复后重新提交审查]
+[ADE 修复后重新提交审查]
 
 重新审查...
 
@@ -699,7 +728,7 @@ npm audit
 3. TypeScript 类型定义完整，类型安全
 4. 前后端接口定义一致，字段名完全匹配
 
-下一步请 Tester 进行测试验证。
+下一步自动调用 `/tester` 进行测试验证。
 ```
 
 ## 参考资源

package/skills/git-engineer/SKILL.md

@@ -74,8 +74,8 @@ npm run test:coverage
 - Lint 检查失败：5 个错误
 - 单元测试失败：2/15 测试用例
 
-🔄 自动修复：调用对应 Engineer 修复问题...
-修复完成后将走完整流程：Engineer → Code Reviewer → Tester → Git Engineer
+🔄 自动修复：调用 `/ade` 修复问题...
+修复完成后将走完整流程：ADE → Code Reviewer → Tester → Git Engineer
 
 📢 已发送钉钉通知（预检测失败）
 ```
@@ -381,26 +381,51 @@ glab mr status
 
 ## 钉钉通知集成
 
+### 发送通知逻辑
+
+```bash
+# 检查钉钉配置
+CONFIG_FILE=".claude/dingtalk-config.json"
+if [ ! -f "$CONFIG_FILE" ]; then
+    CONFIG_FILE="$HOME/.claude/dingtalk-config.json"
+fi
+
+# 如果配置存在且启用，发送通知
+if [ -f "$CONFIG_FILE" ]; then
+    WEBHOOK_URL=$(jq -r '.webhook_url' "$CONFIG_FILE")
+    ENABLED=$(jq -r '.enabled // true' "$CONFIG_FILE")
+    NOTIFY_ON=$(jq -r '.notify_on[]' "$CONFIG_FILE")
+
+    if [ "$ENABLED" = "true" ]; then
+        # 发送通知（根据场景选择消息内容）
+        curl -X POST "$WEBHOOK_URL" \
+          -H 'Content-Type: application/json' \
+          -d "$MESSAGE"
+    fi
+fi
+```
+
 ### 预检测失败通知
 
-通知格式（JSON）：
 ```json
 {
   "msgtype": "markdown",
   "markdown": {
-    "title": "SDD 工作流失败",
-    "text": "❌ **SDD 预检测失败**\n\n- **工作流**: user-login\n- **失败阶段**: Git Engineer - 预检测\n- **失败项**:\n  - Lint 检查失败：5 个错误\n  - 单元测试失败：2/15 测试用例\n- **建议操作**: 返回对应的 Engineer 修复\n\n🕐 **时间**: 2026-01-06 16:00:00"
+    "title": "SDD 预检测失败",
+    "text": "❌ **SDD 预检测失败**\n\n- **工作流**: user-login\n- **失败阶段**: Git Engineer - 预检测\n- **失败项**:\n  - Lint 检查失败：5 个错误\n  - 单元测试失败：2/15 测试用例\n- **建议操作**: 返回 ADE 修复\n\n🕐 **时间**: 2026-01-06 16:00:00"
   }
 }
 ```
 
 ### MR 创建成功通知（可选）
 
+仅当配置 `notify_on` 包含 `"success"` 时发送：
+
 ```json
 {
   "msgtype": "markdown",
   "markdown": {
-    "title": "SDD 工作流完成",
+    "title": "SDD MR 已创建",
     "text": "✅ **SDD MR 已创建**\n\n- **工作流**: user-login\n- **MR 标题**: feat(auth): Add user login functionality\n- **MR 链接**: https://git.in.chaitin.net/yusheng.wang/project/-/merge_requests/1\n- **审查人**: @reviewer1\n\n🕐 **时间**: 2026-01-06 16:30:00"
   }
 }
@@ -413,7 +438,7 @@ glab mr status
 1. **上游**: 接收 Tester 测试通过的代码
 2. **下游**:
    - 预检测通过 + MR 创建成功 → 工作流完成
-   - 预检测失败 → **自动调用** 对应 Engineer 修复 → 走完整流程回来（Code Reviewer → Tester → Git Engineer）
+   - 预检测失败 → **自动调用** `/ade` 修复 → 走完整流程回来（Code Reviewer → Tester → Git Engineer）
 3. **并行**: 无
 
 ## 会话管理
@@ -426,12 +451,12 @@ glab mr status
 - **MR 创建成功**：预检测通过，MR 已创建，整个 SDD 工作流完成
 
 **不触发 /compact 的情况**：
-- **预检测失败**：问题自动反馈给 Engineer 修复，需要保持上下文以便后续修复循环
+- **预检测失败**：问题自动反馈给 ADE 修复，需要保持上下文以便后续修复循环
 
 ### 为什么这样设计
 
 - Git Engineer 是工作流的终点，MR 成功代表整个工作流完成
-- 预检测失败时需要返回 Engineer 修复，保持上下文有助于追踪修复历史
+- 预检测失败时需要返回 ADE 修复，保持上下文有助于追踪修复历史
 - `/compact` 只在工作流的**起点**（SAE）和**终点**（Git Engineer MR 成功）触发
 
 ### 执行方式

package/skills/notifier/SKILL.md

@@ -17,7 +17,7 @@ description: 钉钉通知助手，负责发送SDD工作流事件通知。当测
 - **Tester 测试失败**: 测试用例失败、覆盖率不达标、E2E 测试失败
 - **Code Reviewer 审查不通过**: 代码质量问题、安全漏洞、性能问题
 - **Git Engineer 预检测失败**: Lint 失败、编译失败、测试失败
-- **Developer 验证失败**: 语法错误、编译错误、单元测试失败、覆盖率不达标（后端或前端）
+- **ADE 验证失败**: 语法错误、编译错误、单元测试失败、覆盖率不达标（后端或前端）
 
 #### ✅ 成功场景（可选）
 - **MR 创建成功**: GitLab Merge Request 创建完成
@@ -116,7 +116,7 @@ curl -X POST "$WEBHOOK_URL" \
   "msgtype": "markdown",
   "markdown": {
     "title": "SDD 工作流失败",
-    "text": "❌ **SDD 工作流失败**\n\n- **工作流**: {feature-name}\n- **失败阶段**: Tester\n- **失败类型**: 测试失败\n- **详情**:\n  - 后端测试失败：{failed-count}/{total-count}\n  - 前端 E2E 测试失败：{failed-count}/{total-count}\n- **建议操作**: 返回对应 Engineer 修复\n\n🕐 **时间**: {timestamp}"
+    "text": "❌ **SDD 工作流失败**\n\n- **工作流**: {feature-name}\n- **失败阶段**: Tester\n- **失败类型**: 测试失败\n- **详情**:\n  - 后端测试失败：{failed-count}/{total-count}\n  - 前端 E2E 测试失败：{failed-count}/{total-count}\n- **建议操作**: 返回 ADE 修复\n\n🕐 **时间**: {timestamp}"
   }
 }
 ```
@@ -127,7 +127,7 @@ curl -X POST "$WEBHOOK_URL" \
   "msgtype": "markdown",
   "markdown": {
     "title": "SDD 工作流失败",
-    "text": "❌ **SDD 工作流失败**\n\n- **工作流**: user-login\n- **失败阶段**: Tester\n- **失败类型**: 测试失败\n- **详情**:\n  - 后端测试失败：2/12\n  - 前端 E2E 测试失败：1/3\n  - 后端覆盖率：85% (要求 >= 90%)\n- **建议操作**: 返回 Developer 修复\n\n🕐 **时间**: 2026-01-06 14:30:00"
+    "text": "❌ **SDD 工作流失败**\n\n- **工作流**: user-login\n- **失败阶段**: Tester\n- **失败类型**: 测试失败\n- **详情**:\n  - 后端测试失败：2/12\n  - 前端 E2E 测试失败：1/3\n  - 后端覆盖率：85% (要求 >= 90%)\n- **建议操作**: 返回 ADE 修复\n\n🕐 **时间**: 2026-01-06 14:30:00"
   }
 }
 ```
@@ -139,7 +139,7 @@ curl -X POST "$WEBHOOK_URL" \
   "msgtype": "markdown",
   "markdown": {
     "title": "SDD 代码审查不通过",
-    "text": "❌ **SDD 代码审查不通过**\n\n- **工作流**: {feature-name}\n- **失败阶段**: Code Reviewer\n- **问题统计**:\n  - 严重问题：{critical-count} 个\n  - 中等问题：{medium-count} 个\n  - 轻微问题：{minor-count} 个\n- **主要问题**:\n  - {problem-1}\n  - {problem-2}\n- **建议操作**: 返回对应 Engineer 修复\n\n🕐 **时间**: {timestamp}"
+    "text": "❌ **SDD 代码审查不通过**\n\n- **工作流**: {feature-name}\n- **失败阶段**: Code Reviewer\n- **问题统计**:\n  - 严重问题：{critical-count} 个\n  - 中等问题：{medium-count} 个\n  - 轻微问题：{minor-count} 个\n- **主要问题**:\n  - {problem-1}\n  - {problem-2}\n- **建议操作**: 返回 ADE 修复\n\n🕐 **时间**: {timestamp}"
   }
 }
 ```
@@ -150,7 +150,7 @@ curl -X POST "$WEBHOOK_URL" \
   "msgtype": "markdown",
   "markdown": {
     "title": "SDD 代码审查不通过",
-    "text": "❌ **SDD 代码审查不通过**\n\n- **工作流**: user-login\n- **失败阶段**: Code Reviewer\n- **问题统计**:\n  - 严重问题：2 个\n  - 中等问题：1 个\n  - 轻微问题：1 个\n- **主要问题**:\n  - 密码明文存储（严重）\n  - N+1 查询问题（严重）\n  - 缺少 TypeScript 类型定义（中等）\n- **建议操作**: 返回 Developer 修复\n\n🕐 **时间**: 2026-01-06 15:00:00"
+    "text": "❌ **SDD 代码审查不通过**\n\n- **工作流**: user-login\n- **失败阶段**: Code Reviewer\n- **问题统计**:\n  - 严重问题：2 个\n  - 中等问题：1 个\n  - 轻微问题：1 个\n- **主要问题**:\n  - 密码明文存储（严重）\n  - N+1 查询问题（严重）\n  - 缺少 TypeScript 类型定义（中等）\n- **建议操作**: 返回 ADE 修复\n\n🕐 **时间**: 2026-01-06 15:00:00"
   }
 }
 ```
@@ -162,7 +162,7 @@ curl -X POST "$WEBHOOK_URL" \
   "msgtype": "markdown",
   "markdown": {
     "title": "SDD 预检测失败",
-    "text": "❌ **SDD 预检测失败**\n\n- **工作流**: {feature-name}\n- **失败阶段**: Git Engineer - 预检测\n- **失败项**:\n  - {failure-1}\n  - {failure-2}\n- **建议操作**: 返回 Developer 修复\n\n🕐 **时间**: {timestamp}"
+    "text": "❌ **SDD 预检测失败**\n\n- **工作流**: {feature-name}\n- **失败阶段**: Git Engineer - 预检测\n- **失败项**:\n  - {failure-1}\n  - {failure-2}\n- **建议操作**: 返回 ADE 修复\n\n🕐 **时间**: {timestamp}"
   }
 }
 ```
@@ -173,19 +173,19 @@ curl -X POST "$WEBHOOK_URL" \
   "msgtype": "markdown",
   "markdown": {
     "title": "SDD 预检测失败",
-    "text": "❌ **SDD 预检测失败**\n\n- **工作流**: user-login\n- **失败阶段**: Git Engineer - 预检测\n- **失败项**:\n  - 后端 Lint 检查失败：5 个错误\n  - 后端单元测试失败：2/12 测试用例\n  - 前端编译失败：类型错误\n- **建议操作**: 返回 Developer 修复\n\n🕐 **时间**: 2026-01-06 16:00:00"
+    "text": "❌ **SDD 预检测失败**\n\n- **工作流**: user-login\n- **失败阶段**: Git Engineer - 预检测\n- **失败项**:\n  - 后端 Lint 检查失败：5 个错误\n  - 后端单元测试失败：2/12 测试用例\n  - 前端编译失败：类型错误\n- **建议操作**: 返回 ADE 修复\n\n🕐 **时间**: 2026-01-06 16:00:00"
   }
 }
 ```
 
-### 4. Developer 验证失败
+### 4. ADE 验证失败
 
 ```json
 {
   "msgtype": "markdown",
   "markdown": {
     "title": "SDD 验证失败",
-    "text": "❌ **SDD Developer 验证失败**\n\n- **工作流**: {feature-name}\n- **失败阶段**: Developer\n- **失败项**:\n  - {failure-1}\n  - {failure-2}\n- **建议操作**: 修复验证问题后重新验证\n\n🕐 **时间**: {timestamp}"
+    "text": "❌ **SDD ADE 验证失败**\n\n- **工作流**: {feature-name}\n- **失败阶段**: ADE\n- **失败项**:\n  - {failure-1}\n  - {failure-2}\n- **建议操作**: 修复验证问题后重新验证\n\n🕐 **时间**: {timestamp}"
   }
 }
 ```
@@ -196,7 +196,7 @@ curl -X POST "$WEBHOOK_URL" \
   "msgtype": "markdown",
   "markdown": {
     "title": "SDD 验证失败",
-    "text": "❌ **SDD Developer 验证失败**\n\n- **工作流**: user-login\n- **失败阶段**: Developer (后端)\n- **失败项**:\n  - 编译失败：语法错误 auth_service.go:45\n  - 单元测试失败：3/10 测试用例\n  - 覆盖率不达标：85% (要求 >= 90%)\n- **建议操作**: 修复语法错误、测试失败、补充测试用例\n\n🕐 **时间**: 2026-01-06 13:00:00"
+    "text": "❌ **SDD ADE 验证失败**\n\n- **工作流**: user-login\n- **失败阶段**: ADE (后端)\n- **失败项**:\n  - 编译失败：语法错误 auth_service.go:45\n  - 单元测试失败：3/10 测试用例\n  - 覆盖率不达标：85% (要求 >= 90%)\n- **建议操作**: 修复语法错误、测试失败、补充测试用例\n\n🕐 **时间**: 2026-01-06 13:00:00"
   }
 }
 ```
@@ -231,7 +231,7 @@ curl -X POST "$WEBHOOK_URL" \
   "msgtype": "markdown",
   "markdown": {
     "title": "SDD 工作流完成",
-    "text": "✅ **SDD 工作流完成**\n\n- **工作流**: {feature-name}\n- **完成阶段**:\n  - ✅ SAE 需求规格\n  - ✅ Developer 代码实现\n  - ✅ Tester 测试验证\n  - ✅ Code Reviewer 代码审查\n  - ✅ Git Engineer MR 创建\n- **MR 链接**: {mr-url}\n\n🕐 **时间**: {timestamp}"
+    "text": "✅ **SDD 工作流完成**\n\n- **工作流**: {feature-name}\n- **完成阶段**:\n  - ✅ SAE 需求规格\n  - ✅ ADE 代码实现\n  - ✅ Tester 测试验证\n  - ✅ Code Reviewer 代码审查\n  - ✅ Git Engineer MR 创建\n- **MR 链接**: {mr-url}\n\n🕐 **时间**: {timestamp}"
   }
 }
 ```

package/skills/sae/SKILL.md

@@ -9,6 +9,28 @@ description: 软件架构工程师，负责需求分析、架构设计和技术
 
 ## 职责
 
+### 0. 项目上下文理解（前置步骤）
+
+⚠️ **重要**：在编写 Spec 前，必须先充分理解项目上下文！
+
+1. **阅读项目文档**
+   - `CLAUDE.md` - 项目指令和规范
+   - `AGENTS.md` - AI 协作规范（如有）
+   - `README.md` - 项目说明
+   - 其他相关文档（架构文档、API 文档等）
+
+2. **探索项目结构**
+   - 使用 Glob 了解项目目录结构
+   - 识别现有模块和组件
+   - 理解项目技术栈和框架
+
+3. **阅读相关源代码**（必要时）
+   - 当需求涉及现有功能改造时，必须阅读相关代码
+   - 理解现有实现方式和设计模式
+   - 识别可复用的组件和工具函数
+
+**目的**：确保 Spec 与项目现有架构和规范保持一致，避免重复造轮子或违反项目约定。
+
 ### 1. 需求分析
 - 深入理解用户的原始需求
 - 识别不清晰或模糊的需求点
@@ -32,76 +54,51 @@ description: 软件架构工程师，负责需求分析、架构设计和技术
 
 ### 4. 编写 Spec 文档
 
-每个功能需求应拆分为小的 Spec 文档，保存在 `openspec/changes/[change-id]/specs/[capability]/spec.md`。
-
-**重要原则**：
-- 每个 Spec 应聚焦一个小需求，保持简洁
-- DESIGN 部分不要过于复杂，能让前后端及 AI 正确理解意图即可
-- 避免歧义，使用明确的描述和示例
+**重要说明**：
+- 此 Spec 是 **临时性输出**，是给下一个角色 ADE（AI Development Engineer）的任务要求及改造内容
+- 此 Spec **不是** ADE 阶段的 OpenSpec，两者用途不同
+- 每个 Spec 应聚焦一个小需求，保持简洁，避免歧义
 
 #### Spec 文档格式
 
 ```markdown
-# [Capability Name]
+# [功能名称]
 
 ## DESCRIPTION
 
-### 需求背景
-[1-2 句话说明为什么需要这个功能]
-
-### 目标
-- [具体目标 1]
-- [具体目标 2]
-
-### 验收标准
-- [ ] 标准 1：具体可验证的条件
-- [ ] 标准 2：具体可验证的条件
+[100~300字描述清楚要做什么，达成的结果是什么。包含：]
+- 需求背景（为什么需要这个功能）
+- 具体目标（要实现什么）
+- 验收标准（如何验证完成）
 
 ## DESIGN
 
-### 前后端分工
-
-**后端职责**：
-- [具体职责 1]
-- [具体职责 2]
-
-**前端职责**：
-- [具体职责 1]
-- [具体职责 2]
-
-### 接口设计
+[描述核心逻辑及改造内容]
 
-```
-[HTTP Method] /api/v1/[resource]
-Request:
-{
-  "field1": "类型和说明",
-  "field2": "类型和说明"
-}
-Response:
-{
-  "field1": "类型和说明"
-}
-```
-
-### 数据模型（如有）
+### 核心逻辑
+[用简洁的步骤描述实现逻辑]
 
-| 字段名 | 类型 | 说明 |
-|--------|------|------|
-| field1 | string | 说明 |
+### 核心流程（如有必要）
+[流程图或时序说明]
 
-### 核心逻辑
+### 涉及文件（如有必要）
+[列出需要修改或新增的文件]
 
-[用简洁的步骤描述实现逻辑，避免歧义]
+### 接口设计（如有必要）
+[API 接口定义]
 
-1. 步骤 1：具体操作
-2. 步骤 2：具体操作
-3. 步骤 3：具体操作
+### 数据模型（如有必要）
+[数据结构定义]
 
-### 边界情况
+## STEPS
 
-- 情况 1：如何处理
-- 情况 2：如何处理
+1. 切换到当前项目的主分支（master/main），使用 `git pull --rebase` 同步远端仓库内容；
+2. 使用 `git switch -c [YYMMDD]-[issue-id]-[feature-name]` 创建新的工作分支；
+3. [具体实现步骤 1]；
+4. [具体实现步骤 2]；
+5. [具体实现步骤 N]；
+6. 运行测试验证功能正确性；
+7. 提交代码并创建 MR。
 ```
 
 #### 示例：用户登录 Spec
@@ -111,33 +108,35 @@ Response:
 
 ## DESCRIPTION
 
-### 需求背景
-用户需要通过账号密码登录系统以访问受保护的资源。
-
-### 目标
-- 支持邮箱+密码登录
-- 返回 JWT Token 用于后续认证
-- 登录失败时返回明确错误信息
+实现用户登录功能，支持邮箱+密码认证方式。用户输入正确的邮箱和密码后，系统验证凭证并返回 JWT Token，用于后续 API 请求的身份认证。登录失败时返回明确的错误提示，但不泄露账号是否存在。
 
-### 验收标准
-- [ ] 正确的邮箱和密码可以成功登录并获取 Token
-- [ ] 错误的密码返回 401 和提示信息
-- [ ] 不存在的邮箱返回 401（不透露邮箱是否存在）
-- [ ] Token 有效期为 24 小时
+**验收标准**：
+- 正确的邮箱和密码可以成功登录并获取 Token
+- 错误的密码返回 401 和提示信息
+- 不存在的邮箱返回 401（不透露邮箱是否存在）
+- Token 有效期为 24 小时
 
 ## DESIGN
 
-### 前后端分工
+### 核心逻辑
 
-**后端职责**：
-- 实现 `/api/v1/auth/login` 接口
-- 验证用户凭证
-- 生成 JWT Token
+1. 校验请求参数格式（邮箱格式、密码长度）
+2. 根据 email 查询用户
+3. 比对密码哈希（bcrypt）
+4. 生成 JWT Token（包含 user_id, 过期时间）
+5. 返回 Token 和过期时间
 
-**前端职责**：
-- 登录表单页面
-- 调用登录接口
-- 存储 Token 到 localStorage
+### 涉及文件
+
+**后端**：
+- `backend/internal/api/auth_handler.go` - 登录接口处理
+- `backend/internal/service/auth_service.go` - 认证业务逻辑
+- `backend/internal/repository/user_repository.go` - 用户数据访问
+
+**前端**：
+- `frontend/src/views/LoginView.vue` - 登录页面
+- `frontend/src/stores/authStore.ts` - 认证状态管理
+- `frontend/src/api/auth.ts` - 认证 API 调用
 
 ### 接口设计
 
@@ -159,28 +158,26 @@ Response (401):
 }
 ```
 
-### 核心逻辑
-
-1. 校验请求参数格式
-2. 根据 email 查询用户
-3. 比对密码哈希（bcrypt）
-4. 生成 JWT Token（包含 user_id, 过期时间）
-5. 返回 Token
-
-### 边界情况
-
-- 邮箱格式错误：返回 400，提示格式不正确
-- 密码长度不符：返回 400，提示长度要求
-- 账号被锁定：返回 403，提示联系管理员
+## STEPS
+
+1. 切换到当前项目的主分支（main），使用 `git pull --rebase` 同步远端仓库内容；
+2. 使用 `git switch -c 260106-issue-1-user-login` 创建新的工作分支；
+3. 实现后端登录 API：创建 auth_handler.go，实现参数校验和响应；
+4. 实现认证服务层：创建 auth_service.go，实现密码验证和 JWT 生成；
+5. 实现用户仓库层：在 user_repository.go 中添加 FindByEmail 方法；
+6. 编写后端单元测试，确保覆盖率 >= 90%；
+7. 实现前端登录页面：创建 LoginView.vue 和 LoginForm 组件；
+8. 实现前端状态管理：创建 authStore.ts 管理登录状态；
+9. 编写前端组件测试，确保覆盖率 >= 90%；
+10. 运行全量测试验证功能正确性；
+11. 提交代码并创建 MR。
 ```
 
 ## 输出工件
 
 完成需求分析后，应生成：
-- **Spec 文档**: `openspec/changes/[change-id]/specs/[capability]/spec.md`（包含 DESCRIPTION 和 DESIGN）
-- **Proposal 文档**: `openspec/changes/[change-id]/proposal.md`（变更说明）
-- **Tasks 文档**: `openspec/changes/[change-id]/tasks.md`（实施任务清单）
-- **明确的待办事项**: 下一步交给 Backend Engineer 和 Frontend Engineer
+- **Spec 文档**: 临时性任务规格，交给 ADE 执行（包含 DESCRIPTION、DESIGN、STEPS）
+- **明确的待办事项**: 下一步交给 ADE（AI Development Engineer）执行开发
 
 ## 决策原则
 
@@ -229,10 +226,10 @@ Response (401):
 
 ## 与其他 Skills 的协作
 
-1. **下游**: 需求规格完成后，交给：
-   - Backend Engineer（生成后端 OpenSpec）
-   - Frontend Engineer（生成前端 OpenSpec）
-   - **注意**: Backend 和 Frontend 可以并行开发，不需要等待对方完成
+1. **下游**: 需求规格完成后：
+   - 输出 Spec 文档，交给用户确认
+   - 用户确认后，可手动调用 `/ade` 开始开发流程
+   - **注意**: ADE 会根据 Spec 中的 STEPS 按顺序执行开发任务
 
 2. **在 Pre-Execution Review 中的角色**:
    - 评估需求清晰度
@@ -253,9 +250,8 @@ SAE 是工作流的**起点**，完成需求分析后：
 
 ### 触发时机
 
-- 需求规格文档已生成并保存
-- Spec 文档、Proposal 文档、Tasks 文档已全部创建
-- 已向用户确认下一步交给 Backend Engineer 和 Frontend Engineer
+- 需求规格 Spec 文档已生成
+- 用户已确认 Spec 文档
 
 ### 执行方式
 
@@ -269,11 +265,26 @@ SAE 是工作流的**起点**，完成需求分析后：
 用户: 帮我实现用户登录功能
 
 我（SAE）:
-好的，我先梳理一下登录功能的需求。
+好的，让我先了解项目上下文。
 
-🗣️ SAE 角度分析：
-- 需求清晰度：⭐⭐⭐ (需要更多细节)
-- 架构复杂度：中等
+📚 **阶段0：项目上下文理解**
+
+正在阅读项目文档...
+- ✅ 已读取 CLAUDE.md - 了解项目规范
+- ✅ 已读取 README.md - 了解项目说明
+- ✅ 已探索项目结构 - 识别现有模块
+
+项目概况：
+- 后端：Go + Gin 框架
+- 前端：Vue 3 + Pinia
+- 已有用户模块：backend/internal/model/user.go
+- 已有 JWT 工具：backend/pkg/jwt/
+
+---
+
+🗣️ **阶段1：需求分析**
+
+需求清晰度：⭐⭐⭐ (需要更多细节)
 
 我需要澄清几个问题：
 1. 登录方式：支持哪些登录方式？(邮箱/手机号/用户名)
@@ -285,16 +296,50 @@ SAE 是工作流的**起点**，完成需求分析后：
 
 [用户回答后]
 
-明白了。我将设计一个基于 JWT 的认证系统...
+明白了。基于项目现有架构，我将复用 `backend/pkg/jwt/` 工具设计认证系统...
+
+已生成 Spec 文档：
 
-已生成以下文件：
-- Spec 文档: openspec/changes/add-user-login/specs/auth/spec.md
-- Proposal: openspec/changes/add-user-login/proposal.md
-- Tasks: openspec/changes/add-user-login/tasks.md
+---
+# User Login
+
+## DESCRIPTION
+
+实现用户登录功能，支持邮箱+密码认证方式。用户输入正确的邮箱和密码后，系统验证凭证并返回 JWT Token，用于后续 API 请求的身份认证。登录失败时返回明确的错误提示，但不泄露账号是否存在。
+
+**验收标准**：
+- 正确的邮箱和密码可以成功登录并获取 Token
+- 错误的密码返回 401 和提示信息
+- Token 有效期为 24 小时
+
+## DESIGN
 
-Spec 概要：
-- DESCRIPTION: 邮箱+密码登录，JWT 认证，24小时有效期
-- DESIGN: 后端 Gin API，前端 Vue 登录表单，bcrypt 密码验证
+### 核心逻辑
+1. 校验请求参数格式
+2. 根据 email 查询用户
+3. 比对密码哈希（bcrypt）
+4. 生成 JWT Token
+5. 返回 Token
+
+### 涉及文件
+- backend/internal/api/auth_handler.go
+- backend/internal/service/auth_service.go
+- frontend/src/views/LoginView.vue
+- frontend/src/stores/authStore.ts
+
+## STEPS
+
+1. 切换到主分支，使用 `git pull --rebase` 同步远端仓库；
+2. 使用 `git switch -c 260106-issue-1-user-login` 创建工作分支；
+3. 实现后端登录 API；
+4. 实现认证服务层；
+5. 编写后端单元测试；
+6. 实现前端登录页面；
+7. 实现前端状态管理；
+8. 编写前端组件测试；
+9. 运行全量测试验证；
+10. 提交代码并创建 MR。
+---
 
-下一步请 Backend Engineer 和 Frontend Engineer 分别实现各自部分。
+Spec 文档已生成，请确认后可调用 `/ade` 开始开发。
 ```

package/skills/tester/SKILL.md

@@ -106,7 +106,7 @@ npm run test:e2e -- --project=chromium
 
 #### 1. 后端问题自动修复
 
-当检测到以下后端问题时，**立即调用 `/developer`**：
+当检测到以下后端问题时，**立即调用 `/ade`**：
 
 - 后端单元测试失败
 - 后端覆盖率不达标 (< 90%)
@@ -116,14 +116,14 @@ npm run test:e2e -- --project=chromium
 
 **自动修复指令**：
 ```
-/developer 修复以下后端测试问题：
+/ade 修复以下后端测试问题：
 [具体的错误信息和失败的测试用例]
 修复完成后重新运行测试验证。
 ```
 
 #### 2. 前端问题自动修复
 
-当检测到以下前端问题时，**立即调用 `/developer`**：
+当检测到以下前端问题时，**立即调用 `/ade`**：
 
 - 前端单元测试失败
 - 前端覆盖率不达标 (< 90%)
@@ -134,15 +134,15 @@ npm run test:e2e -- --project=chromium
 
 **自动修复指令**：
 ```
-/developer 修复以下前端测试问题：
+/ade 修复以下前端测试问题：
 [具体的错误信息和失败的测试用例]
 修复完成后重新运行测试验证。
 ```
 
 #### 3. 混合问题处理
 
-如果前端和后端都有问题，**调用 `/developer` 同时处理**：
-1. Developer 会先修复后端问题
+如果前端和后端都有问题，**调用 `/ade` 同时处理**：
+1. ADE 会先修复后端问题
 2. 然后修复前端问题
 3. 全部修复后重新执行完整测试
 
@@ -167,7 +167,7 @@ npm run test:e2e -- --project=chromium
 
 ✅ 验收标准：5/5 满足
 
-下一步请 Git Engineer 进行预检测和提交。
+下一步自动调用 `/git-engineer` 进行预检测和提交。
 ```
 
 **测试失败（自动修复中）**：
@@ -183,9 +183,9 @@ npm run test:e2e -- --project=chromium
    - 后端覆盖率：85% (要求 >= 90%)
    - 未覆盖模块：user_service.go:45-60
 
-🔄 自动修复：调用 /developer 修复后端问题...
+🔄 自动修复：调用 /ade 修复后端问题...
 
-[Developer 修复完成后自动重新测试]
+[ADE 修复完成后自动重新测试]
 ```
 
 **测试失败（需人工介入）**：
@@ -445,14 +445,42 @@ lhci autorun
 - 覆盖率不达标
 - E2E 测试失败
 - 验收标准未满足
+- 超过最大修复轮次需要人工介入
+
+```bash
+# 检查钉钉配置
+CONFIG_FILE=".claude/dingtalk-config.json"
+if [ ! -f "$CONFIG_FILE" ]; then
+    CONFIG_FILE="$HOME/.claude/dingtalk-config.json"
+fi
+
+# 如果配置存在且启用，发送通知
+if [ -f "$CONFIG_FILE" ]; then
+    WEBHOOK_URL=$(jq -r '.webhook_url' "$CONFIG_FILE")
+    ENABLED=$(jq -r '.enabled // true' "$CONFIG_FILE")
+
+    if [ "$ENABLED" = "true" ]; then
+        curl -X POST "$WEBHOOK_URL" \
+          -H 'Content-Type: application/json' \
+          -d '{
+            "msgtype": "markdown",
+            "markdown": {
+              "title": "SDD 测试失败",
+              "text": "❌ **SDD 测试失败**\n\n- **工作流**: [feature-name]\n- **失败阶段**: Tester\n- **失败详情**:\n  - [具体失败项]\n- **建议操作**: 返回 ADE 修复\n\n🕐 **时间**: [timestamp]"
+            }
+          }'
+    fi
+fi
+```
+
+### 通知消息格式
 
-通知格式（JSON）：
 ```json
 {
   "msgtype": "markdown",
   "markdown": {
-    "title": "SDD 工作流失败",
-    "text": "❌ **SDD 工作流失败**\n\n- **工作流**: user-login\n- **失败阶段**: Tester\n- **错误信息**: 3/10 测试用例失败\n- **建议操作**: 返回 Developer 修复\n\n🕐 **时间**: 2026-01-06 14:30:00"
+    "title": "SDD 测试失败",
+    "text": "❌ **SDD 测试失败**\n\n- **工作流**: user-login\n- **失败阶段**: Tester\n- **失败详情**:\n  - 后端测试失败：2/12\n  - 前端覆盖率不达标：85% (要求 >= 90%)\n- **建议操作**: 返回 ADE 修复\n\n🕐 **时间**: 2026-01-06 14:30:00"
   }
 }
 ```
@@ -482,12 +510,12 @@ lhci autorun
 
 1. **上游**: 接收 Code Reviewer 审查通过的代码
 2. **自动修复循环**:
-   - 后端测试失败 → **自动调用** `/developer` 修复
-   - 前端测试失败 → **自动调用** `/developer` 修复
-   - Developer 修复后会重新提交给 Code Reviewer → 审查通过后流转回 Tester
+   - 后端测试失败 → **自动调用** `/ade` 修复
+   - 前端测试失败 → **自动调用** `/ade` 修复
+   - ADE 修复后会重新提交给 Code Reviewer → 审查通过后流转回 Tester
    - 循环直到全部通过或达到最大修复轮次(3轮)
 3. **下游**:
-   - 测试通过 → 交给 Git Engineer
+   - 测试通过 → **自动调用** `/git-engineer` 进行预检测和提交
    - 超过 3 轮仍失败 → 发送钉钉通知，请求人工介入
 4. **并行**: 无
 
@@ -540,9 +568,9 @@ lhci autorun
 🔄 自动修复流程启动...
 
 ---
-【自动调用 /developer 修复后端问题】
+【自动调用 /ade 修复后端问题】
 
-/developer 修复以下后端测试问题：
+/ade 修复以下后端测试问题：
 
 1. 后端覆盖率不达标：85% (要求 >= 90%)
    - 未覆盖文件：user_service.go:45-60
@@ -553,7 +581,7 @@ lhci autorun
 请补充单元测试并确保覆盖率 >= 90%。
 
 ---
-[Developer 修复完成]
+[ADE 修复完成]
 
 🔄 重新执行后端测试...
 
@@ -565,9 +593,9 @@ lhci autorun
 ✅ 后端测试通过！
 
 ---
-【自动调用 /developer 修复前端问题】
+【自动调用 /ade 修复前端问题】
 
-/developer 修复以下前端测试问题：
+/ade 修复以下前端测试问题：
 
 1. E2E 测试失败：用户登录成功后跳转到 Dashboard
    - 失败原因：登录成功后停留在 /login，未跳转到 /dashboard
@@ -577,7 +605,7 @@ lhci autorun
 请修复路由跳转逻辑。
 
 ---
-[Developer 修复完成]
+[ADE 修复完成]
 
 🔄 重新执行前端测试...
 
@@ -597,5 +625,5 @@ lhci autorun
 - E2E 测试：3/3 通过
 - 验收标准：5/5 满足
 
-下一步请 Git Engineer 进行预检测和提交。
+下一步自动调用 `/git-engineer` 进行预检测和提交。
 ```