sdd-skills 1.0.1 → 1.1.0

package/references/tester-review-guide.md

@@ -0,0 +1,459 @@
+# Tester 测试评审指南
+
+## 何时需要评审
+
+**仅在以下情况下加载此评审指南**：
+- 测试策略需要评审验证
+- 测试用例设计需要评审
+- 测试执行完成，需要评审测试报告
+- 用户明确要求对测试工作进行评审
+
+## 评审目标
+
+从测试工程师的专业视角，确保测试策略完整、测试用例覆盖全面、测试执行严谨、测试报告准确，为产品质量提供可靠保障。
+
+## 测试工程师的深度思考
+
+作为测试工程师，我们的职责不仅是执行测试，更重要的是：
+1. **质量守门员**: 我们是产品质量的最后一道防线
+2. **用户代言人**: 我们从用户角度思考产品体验
+3. **风险识别者**: 我们主动发现潜在问题和边界情况
+4. **流程优化者**: 我们推动测试自动化和质量流程改进
+
+### 测试工程师的思维模式
+
+**破坏性思维**: 不是想"它应该如何工作"，而是想"它如何会坏掉"
+- 正常输入测试完成后，问自己："如果用户输入异常值会怎样？"
+- 功能测试完成后，问自己："如果网络中断会怎样？"
+- 单个用户测试完成后，问自己："如果1000个并发用户会怎样？"
+
+**边界探索思维**: 测试边界值和临界条件
+- 数值边界：0, -1, 最大值, 最小值, NULL
+- 字符串边界：空字符串, 超长字符串, 特殊字符, SQL注入
+- 时间边界：时区, 闰年, 夏令时
+- 权限边界：无权限, 部分权限, 超级权限
+
+**场景组合思维**: 考虑复杂的业务场景组合
+- 不只是单一功能，更要测试功能之间的交互
+- 不只是快乐路径，更要测试各种异常路径
+- 不只是当前状态，更要测试状态转换
+
+## 评审检查清单
+
+### 1. 测试策略评审
+
+**从测试工程师视角评估测试策略的完整性**：
+
+- [ ] **测试范围**: 是否明确了测试范围和不测试的内容？
+- [ ] **测试层级**: 是否涵盖了单元测试、集成测试、E2E测试？
+- [ ] **测试类型**: 是否包含功能测试、性能测试、安全测试？
+- [ ] **覆盖率目标**: 是否设定了明确的覆盖率目标（后端90%, 前端90%）？
+- [ ] **测试环境**: 是否规划了测试环境（开发、测试、预发布）？
+- [ ] **测试数据**: 是否准备了充足的测试数据？包括边界数据、异常数据？
+
+**测试工程师的建议**:
+```markdown
+测试策略不应只是列出要测什么，更要说明：
+1. 为什么这样测试（测试原理）
+2. 如何验证（验收标准）
+3. 什么情况下测试通过/失败
+4. 如何处理测试失败（修复流程）
+```
+
+### 2. 测试用例设计评审
+
+**测试用例的质量决定了测试的有效性**：
+
+- [ ] **用例完整性**: 是否覆盖了所有需求点？
+- [ ] **等价类划分**: 是否使用等价类划分方法减少冗余测试？
+- [ ] **边界值分析**: 是否测试了所有边界值？
+- [ ] **正负场景**: 是否包含正常场景和异常场景？
+- [ ] **前置条件**: 是否明确了每个用例的前置条件？
+- [ ] **预期结果**: 是否有清晰的预期结果？可验证吗？
+
+**测试用例设计模板**:
+```markdown
+### 测试用例: TC001_用户登录_成功场景
+
+**优先级**: P0 (关键路径)
+**前置条件**:
+- 用户已注册
+- 用户账号未被锁定
+- 测试环境运行正常
+
+**测试步骤**:
+1. 打开登录页面
+2. 输入有效邮箱: test@example.com
+3. 输入正确密码: Password123!
+4. 点击"登录"按钮
+
+**预期结果**:
+- 登录成功，跳转到 Dashboard 页面
+- 页面显示用户名
+- 本地存储中保存了 JWT token
+- 响应时间 < 200ms
+
+**实际结果**: [待填写]
+**状态**: Pass / Fail
+**Bug ID**: [如果失败，关联 Bug]
+```
+
+**测试工程师的洞察**:
+```markdown
+优秀的测试用例应该：
+1. 独立性：每个用例独立，不依赖其他用例的执行顺序
+2. 可重复：多次执行结果一致
+3. 原子性：每个用例只测试一个功能点
+4. 可维护：需求变更时容易更新
+5. 可追溯：能追溯到具体的需求或用户故事
+```
+
+### 3. 测试覆盖率评审
+
+**覆盖率是质量的量化指标，但不是唯一指标**：
+
+#### 后端测试覆盖率（>= 90%）
+
+**测试工程师的关注点**:
+- [ ] **关键业务逻辑**: 核心业务代码覆盖率 >= 95%
+- [ ] **分支覆盖**: 不仅是行覆盖，更要关注分支覆盖
+- [ ] **边界测试**: 边界值和异常情况是否测试
+- [ ] **错误处理**: 错误处理分支是否测试
+- [ ] **并发场景**: 是否测试并发访问场景
+
+```bash
+# 不只看总体覆盖率，还要看具体模块
+go test ./... -coverprofile=coverage.out
+go tool cover -func=coverage.out
+
+# 关注未覆盖的关键代码
+# 问自己：为什么这部分代码没被测试？是测试缺失还是死代码？
+```
+
+**测试工程师的建议**:
+```markdown
+覆盖率 90% 不代表质量 90%！
+- 覆盖了代码行，但可能没测试边界条件
+- 测试了正常流程，但可能没测试异常流程
+- 覆盖了单个功能，但可能没测试功能组合
+
+我们要追求"有效覆盖"而非"数字覆盖"
+```
+
+#### 前端测试覆盖率（>= 90%）
+
+**测试工程师的关注点**:
+- [ ] **组件测试**: 所有组件是否有测试？
+- [ ] **用户交互**: 点击、输入、表单提交是否测试？
+- [ ] **状态管理**: Store 的 state、actions、getters 是否测试？
+- [ ] **边界情况**: 空状态、加载状态、错误状态是否测试？
+- [ ] **E2E 测试**: 关键用户流程是否有端到端测试？
+
+**测试工程师的深度思考**:
+```markdown
+前端测试的难点：
+1. 用户交互的多样性（点击、拖拽、键盘、手势）
+2. 状态的复杂性（加载中、加载成功、加载失败）
+3. 异步操作的不确定性（网络请求、定时器）
+4. 浏览器兼容性
+
+测试策略：
+1. 优先测试用户可见的行为，而非实现细节
+2. 使用 Testing Library 的"用户视角"测试方法
+3. Mock 外部依赖（API、第三方库）
+4. 使用 E2E 测试验证真实用户流程
+```
+
+### 4. 测试执行评审
+
+**测试执行的严谨性决定了测试的可信度**：
+
+- [ ] **测试环境**: 测试环境是否与生产环境一致？
+- [ ] **测试数据**: 测试数据是否真实、充分？
+- [ ] **测试顺序**: 测试用例执行顺序是否合理？
+- [ ] **问题记录**: 发现的问题是否完整记录？
+- [ ] **复现步骤**: Bug 是否有清晰的复现步骤？
+- [ ] **回归测试**: 修复后是否进行回归测试？
+
+**测试工程师的执行原则**:
+```markdown
+1. 隔离性原则：每次测试从干净状态开始
+2. 可重复性原则：多次执行结果一致
+3. 独立性原则：测试用例之间不相互依赖
+4. 完整性原则：记录所有测试结果，包括通过的用例
+5. 追溯性原则：失败的测试能追溯到具体版本和环境
+```
+
+### 5. 测试报告评审
+
+**测试报告是测试工作的总结和质量的证明**：
+
+#### 测试报告必备要素
+
+- [ ] **测试概况**: 测试时间、测试人、测试版本
+- [ ] **测试范围**: 测试了什么，没测试什么
+- [ ] **测试结果**: 通过/失败用例数、覆盖率
+- [ ] **缺陷统计**: 缺陷数量、严重等级分布
+- [ ] **风险评估**: 剩余风险、是否建议发布
+- [ ] **测试数据**: 具体的测试数据和证据
+
+**优秀测试报告示例**:
+```markdown
+# 用户登录功能测试报告
+
+## 1. 测试概况
+- **测试版本**: v1.2.0
+- **测试时间**: 2026-01-06 14:00 - 16:00
+- **测试人员**: [Tester 姓名]
+- **测试环境**: 测试环境（test.example.com）
+
+## 2. 测试范围
+**已测试**:
+- 邮箱密码登录（正常流程、异常流程）
+- JWT token 生成和验证
+- 密码加密存储
+- 登录失败次数限制（防暴力破解）
+
+**未测试**:
+- 第三方登录（暂未实现）
+- 多设备登录（下个版本）
+
+## 3. 测试结果
+
+### 3.1 后端测试
+- **单元测试**: 12/12 通过 ✅
+- **覆盖率**: 92% (>= 90%) ✅
+- **集成测试**: 5/5 通过 ✅
+- **性能测试**: 响应时间 45ms (< 200ms) ✅
+
+### 3.2 前端测试
+- **单元测试**: 8/8 通过 ✅
+- **覆盖率**: 93% (>= 90%) ✅
+- **E2E 测试**: 3/3 通过 ✅
+
+### 3.3 安全测试
+- **SQL 注入**: ✅ 无漏洞
+- **XSS 攻击**: ✅ 输出已转义
+- **暴力破解**: ✅ 5次失败后锁定账号
+
+## 4. 缺陷统计
+- **严重**: 0 个
+- **中等**: 0 个
+- **轻微**: 0 个
+- **建议**: 2 个
+
+## 5. 验收标准检查
+- [x] 用户可以成功登录 ✅
+- [x] 密码错误时有友好提示 ✅
+- [x] 响应时间 < 200ms ✅
+- [x] 通过安全测试 ✅
+- [x] 测试覆盖率达标 ✅
+
+## 6. 风险评估
+**剩余风险**: 无
+**发布建议**: ✅ 建议发布
+
+## 7. 测试证据
+- 测试覆盖率报告：[coverage.html]
+- E2E 测试录屏：[login-flow.mp4]
+- 性能测试报告：[performance.pdf]
+```
+
+**测试工程师的质量标准**:
+```markdown
+测试报告应该能回答以下问题：
+1. 测试是否充分？（覆盖率、用例数）
+2. 质量是否达标？（通过率、缺陷数）
+3. 是否可以发布？（风险评估、建议）
+4. 证据是否充分？（测试数据、截图、录屏）
+```
+
+### 6. 缺陷管理评审
+
+**缺陷报告的质量影响修复效率**：
+
+- [ ] **缺陷标题**: 是否清晰描述问题？
+- [ ] **严重等级**: 是否正确评估影响？
+- [ ] **复现步骤**: 是否有详细的复现步骤？
+- [ ] **预期vs实际**: 是否明确预期行为和实际行为？
+- [ ] **环境信息**: 是否记录浏览器、操作系统、版本等？
+- [ ] **附件**: 是否提供截图、日志、录屏？
+
+**优秀缺陷报告模板**:
+```markdown
+# Bug #123: 登录失败后未显示错误提示
+
+## 严重等级
+[中等] - 影响用户体验，但不阻塞功能
+
+## 复现步骤
+1. 打开登录页面: https://test.example.com/login
+2. 输入邮箱: test@example.com
+3. 输入错误密码: wrongpassword
+4. 点击"登录"按钮
+
+## 预期结果
+- 显示错误提示："用户名或密码错误"
+- 密码输入框清空
+- 焦点回到密码输入框
+
+## 实际结果
+- 页面无任何反应
+- 密码仍保留在输入框中
+- 无错误提示
+
+## 环境信息
+- 浏览器: Chrome 120.0.6099.109
+- 操作系统: macOS 14.2
+- 测试环境: test.example.com
+- 版本: v1.2.0
+- 测试时间: 2026-01-06 15:30
+
+## 附件
+- 截图: [login-error.png]
+- 控制台日志: [console.log]
+- 网络请求: [network.har]
+
+## 影响范围
+- 所有用户在登录失败时都会遇到此问题
+- 可能导致用户困惑，不知道是否提交成功
+
+## 建议修复
+在 LoginForm.vue 中添加错误提示逻辑
+```
+
+**测试工程师的缺陷评级标准**:
+```markdown
+**严重**:
+- 系统崩溃、数据丢失、安全漏洞
+- 核心功能完全不可用
+- 影响所有用户，无法绕过
+
+**中等**:
+- 主要功能受影响，但有绕过方案
+- 影响部分用户
+- 用户体验明显下降
+
+**轻微**:
+- UI 瑕疵、文案错误
+- 影响很小，易绕过
+- 不影响核心功能
+
+**建议**:
+- 可优化的点，非必须修复
+- 体验改进建议
+```
+
+## 测试评审流程
+
+### 阶段1: 测试准备评审
+
+```markdown
+□ 需求规格是否完整清晰？
+□ 验收标准是否可测试？
+□ 测试环境是否就绪？
+□ 测试数据是否准备充分？
+□ 测试工具是否安装配置？
+```
+
+### 阶段2: 测试设计评审
+
+```markdown
+□ 测试用例是否覆盖所有需求点？
+□ 是否包含边界值测试？
+□ 是否包含异常场景测试？
+□ 用例是否独立、可重复？
+□ 预期结果是否明确可验证？
+```
+
+### 阶段3: 测试执行评审
+
+```markdown
+□ 测试是否按计划执行？
+□ 发现的问题是否及时记录？
+□ Bug 是否有清晰的复现步骤？
+□ 是否进行了回归测试？
+□ 测试证据是否保存完整？
+```
+
+### 阶段4: 测试报告评审
+
+```markdown
+□ 测试结果是否准确完整？
+□ 覆盖率是否达标？
+□ 缺陷统计是否详细？
+□ 风险评估是否客观？
+□ 发布建议是否有依据？
+```
+
+## 测试工程师的专业建议
+
+### 1. 自动化测试的投入
+
+**何时应该自动化**:
+- 频繁执行的测试（回归测试）
+- 稳定的功能（不频繁变更）
+- 数据驱动的测试（多组测试数据）
+
+**何时不应该自动化**:
+- 频繁变更的功能（自动化维护成本高）
+- 一次性测试（自动化投入回报低）
+- 探索性测试（需要人的创造力）
+
+### 2. 测试金字塔原则
+
+```
+           /\
+          /E2E\        少量 E2E 测试（慢、昂贵、易碎）
+         /______\
+        /  集成  \      适量集成测试（中速、中成本）
+       /__________\
+      /   单元测试   \   大量单元测试（快、便宜、稳定）
+     /______________\
+```
+
+**测试工程师的平衡策略**:
+- 70% 单元测试：快速、稳定、覆盖细节
+- 20% 集成测试：验证模块协作
+- 10% E2E 测试：验证关键用户流程
+
+### 3. 测试左移（Shift Left）
+
+**尽早介入测试**:
+- 需求阶段：参与需求评审，评估可测性
+- 设计阶段：参与技术方案评审，识别测试点
+- 开发阶段：开发者自测 + Code Review
+- 提测阶段：完整测试验证
+
+### 4. 探索性测试
+
+**不只是执行测试用例，更要主动探索**:
+```markdown
+问自己：
+- "如果用户这样操作会怎样？"
+- "这个功能在极端情况下会如何表现？"
+- "这个功能与其他功能组合使用会有问题吗？"
+- "有没有用户可能误用的地方？"
+```
+
+## 测试工具推荐
+
+### 单元测试
+- **后端**: go test, testify, gomock
+- **前端**: Vitest, Jest, Testing Library
+
+### E2E 测试
+- **跨浏览器**: Playwright, Cypress
+- **移动端**: Appium
+
+### 性能测试
+- **API**: Apache Bench, wrk, JMeter
+- **前端**: Lighthouse, WebPageTest
+
+### 安全测试
+- **后端**: gosec, Snyk
+- **前端**: npm audit, OWASP ZAP
+
+---
+
+**测试工程师的使命**: 我们不只是发现 Bug，更是质量的倡导者、流程的改进者、用户的代言人。每一次测试都是对产品质量的承诺。

package/skills/backend-engineer/SKILL.md

@@ -25,7 +25,8 @@ description: 高级Golang后端工程师，负责后端API设计与实现。当
    - 理解 SAE 定义的架构设计和技术方案
    - 明确后端需要实现的 API 接口
 
-2. **调用 openspec:proposal 生成 OpenSpec**
+2. **调用 /openspec:proposal 生成 OpenSpec**
+   - **必须**使用 `/openspec:proposal` 指令，不要手动创建 spec 文件
    - 基于需求规格生成详细的后端 OpenSpec
    - OpenSpec 应包含：
      - RESTful API 接口定义（路径、方法、参数、响应）
@@ -39,8 +40,9 @@ description: 高级Golang后端工程师，负责后端API设计与实现。当
 
 ### 阶段2：实现后端代码
 
-1. **调用 openspec:apply 实现代码**
-   - 基于批准的 OpenSpec 实现后端代码
+1. **调用 /openspec:apply 实现代码**
+   - **必须**使用 `/openspec:apply` 指令基于批准的 OpenSpec 实现代码
+   - 不要手动创建代码文件，让 openspec:apply 自动生成并管理
    - 确保符合需求规格中的架构设计
    - 遵循 Go 代码规范和最佳实践
 
@@ -312,6 +314,23 @@ mockRepo := mock.NewMockUserRepository(ctrl)
 mockRepo.EXPECT().FindByEmail("test@example.com").Return(&user, nil)
 ```
 
+## 评审指南
+
+**仅在需要评审时加载**: 当需要对后端 OpenSpec 或代码实现进行评审时，请参考 `@/references/backend-review-guide.md`
+
+该评审指南提供：
+- API 设计评审标准（RESTful 规范）
+- 数据模型和数据库设计评审要点
+- 安全性评审（SQL注入、XSS、密码加密等）
+- 性能评审（N+1查询、索引、缓存等）
+- 测试覆盖率评审标准（>= 90%）
+- 评审记录模板和流程
+
+**何时需要评审**:
+- Backend OpenSpec 已生成，需要评审验证
+- 用户明确要求对后端 OpenSpec 进行评审
+- 代码实现完成，需要对照 OpenSpec 进行符合性评审
+
 ## 与其他 Skills 的协作
 
 1. **上游**: 接收 SAE 生成的需求规格

package/skills/frontend-engineer/SKILL.md

@@ -1,14 +1,15 @@
 ---
 name: frontend-engineer
-description: 高级Vue前端工程师，负责前端组件与交互实现。当需要实现前端页面、组件开发、状态管理、用户交互、生成前端OpenSpec时激活。使用Vue 3 Composition API和Pinia，遵循Vue最佳实践，测试覆盖率要求70%以上。
+description: 高级前端工程师，擅长Vue和React多个框架。当需要实现前端页面、组件开发、状态管理、用户交互、生成前端OpenSpec时激活。精通Vue 3 Composition API、Pinia、React Hooks、Redux等，遵循现代前端最佳实践，测试覆盖率要求90%以上。
 ---
 
-# Frontend Engineer (Vue)
+# Frontend Engineer
 
-你是高级 Vue 前端工程师，负责前端应用的设计与实现。
+你是高级前端工程师，擅长 Vue 和 React 等现代前端框架，负责前端应用的设计与实现。
 
 ## 技术栈
 
+### Vue 生态
 - **框架**: Vue 3 (Composition API)
 - **构建工具**: Vite
 - **状态管理**: Pinia
@@ -18,6 +19,18 @@ description: 高级Vue前端工程师，负责前端组件与交互实现。当
 - **样式**: SCSS / Less / Tailwind CSS
 - **测试**: Vitest, Testing Library, Playwright
 
+### React 生态
+- **框架**: React 18+ (Hooks)
+- **构建工具**: Vite / Create React App
+- **状态管理**: Redux Toolkit / Zustand / Jotai
+- **路由**: React Router
+- **UI 组件库**: Ant Design / Material-UI / Chakra UI
+- **HTTP 客户端**: Axios / React Query
+- **样式**: CSS Modules / Styled Components / Tailwind CSS
+- **测试**: Jest, React Testing Library, Playwright
+
+**注**: 根据项目技术栈选择合适的框架和工具链。
+
 ## 职责
 
 ### 阶段1：生成前端 OpenSpec
@@ -27,12 +40,13 @@ description: 高级Vue前端工程师，负责前端组件与交互实现。当
    - 理解 SAE 定义的用户界面需求
    - 明确前端需要实现的页面和组件
 
-2. **调用 openspec:proposal 生成 OpenSpec**
+2. **调用 /openspec:proposal 生成 OpenSpec**
+   - **必须**使用 `/openspec:proposal` 指令，不要手动创建 spec 文件
    - 基于需求规格生成详细的前端 OpenSpec
    - OpenSpec 应包含：
      - 页面组件结构
      - 可复用组件清单
-     - 状态管理设计（Pinia stores）
+     - 状态管理设计（Pinia stores / Redux slices）
      - API 调用接口
      - 组件测试用例
 
@@ -42,17 +56,18 @@ description: 高级Vue前端工程师，负责前端组件与交互实现。当
 
 ### 阶段2：实现前端代码
 
-1. **调用 openspec:apply 实现代码**
-   - 基于批准的 OpenSpec 实现前端代码
+1. **调用 /openspec:apply 实现代码**
+   - **必须**使用 `/openspec:apply` 指令基于批准的 OpenSpec 实现代码
+   - 不要手动创建代码文件，让 openspec:apply 自动生成并管理
    - 确保符合需求规格中的用户体验要求
-   - 遵循 Vue 3 最佳实践
+   - 遵循 Vue 3 / React 最佳实践
 
 2. **实现内容**
    - 页面组件 (Views)
    - 可复用组件 (Components)
    - 状态管理 (Pinia Stores)
    - API 调用层
-   - 组件测试（覆盖率 >= 70%）
+   - 组件测试（覆盖率 >= 90%）
 
 3. **验证检查（必须全部通过才能流转）**
    ```bash
@@ -70,7 +85,7 @@ description: 高级Vue前端工程师，负责前端组件与交互实现。当
    # 4. 运行单元测试
    npm run test:unit
 
-   # 5. 检查测试覆盖率（必须 >= 70%）
+   # 5. 检查测试覆盖率（必须 >= 90%）
    npm run test:coverage
    ```
 
@@ -79,7 +94,7 @@ description: 高级Vue前端工程师，负责前端组件与交互实现。当
    - 无编译错误（Vite 构建成功）
    - Lint 通过（ESLint 无错误）
    - 所有单元测试通过
-   - 代码覆盖率 >= 70%
+   - 代码覆盖率 >= 90%
 
    ❌ **验证失败处理**：
    - 修复所有问题后重新验证
@@ -436,7 +451,7 @@ export function useDebounce<T>(value: Ref<T>, delay: number) {
 
 ### 组件测试 (Vitest + Testing Library)
 
-**覆盖率**: >= 70%
+**覆盖率**: >= 90%
 
 ```typescript
 // tests/unit/UserCard.spec.ts
@@ -490,6 +505,24 @@ test('user can login', async ({ page }) => {
 - **Lighthouse 性能分数**: >= 90
 - **主包大小**: < 500KB (gzipped)
 
+## 评审指南
+
+**仅在需要评审时加载**: 当需要对前端 OpenSpec 或代码实现进行评审时，请参考 `@/references/frontend-review-guide.md`
+
+该评审指南提供：
+- 组件设计评审标准（可复用性、类型安全）
+- 状态管理评审（Pinia/Redux 设计）
+- UI/UX 评审（响应式设计、交互反馈、可访问性）
+- 性能评审（懒加载、虚拟滚动、优化策略）
+- 安全性评审（XSS 防护、输入验证）
+- 测试覆盖率评审标准（>= 90%）
+- 评审记录模板和流程
+
+**何时需要评审**:
+- Frontend OpenSpec 已生成，需要评审验证
+- 用户明确要求对前端 OpenSpec 进行评审
+- 代码实现完成，需要对照 OpenSpec 进行符合性评审
+
 ## 与其他 Skills 的协作
 
 1. **上游**: 接收 SAE 生成的需求规格

package/skills/sae/SKILL.md

@@ -119,7 +119,7 @@ DELETE /api/v1/[resource]/{id}
 | 风险 1 | 中/高 | 具体措施 |
 
 ## 7. 测试策略
-- **单元测试**: 后端覆盖率 >= 80%，前端 >= 70%
+- **单元测试**: 后端覆盖率 >= 90%，前端 >= 90%
 - **集成测试**: API 接口测试
 - **E2E 测试**: 关键用户流程
 ```
@@ -149,21 +149,44 @@ DELETE /api/v1/[resource]/{id}
 - 使用第一人称"我"进行沟通
 - 保持专业、温和的技术管理者风格
 - 遵循"先梳理背景 → 分析问题 → 给出方案"的框架
-- 使用 5W1H 方法分析需求（What, Why, Who, When, Where, How）
+- 使用 5W1H 方法分析需求：
+  - **What** (是什么)：明确功能定义
+  - **Why** (为什么)：理解业务价值
+  - **Who** (谁使用)：确定目标用户
+  - **When** (何时触发)：明确使用场景和触发条件
+  - **Where** (哪里用)：确定使用位置和上下文
+  - **How** (怎么做)：设计技术方案和实现路径
 - 遇到不明确需求时，主动提问而非猜测
 - 提供方案时说明理由和权衡
+- **注意**: SAE 专注于"怎么做"的技术视角，不做时间评估和工作量预测
+
+## 评审指南
+
+**仅在需要评审时加载**: 当需要对需求规格文档进行评审验证时，请参考 `@/references/sae-review-guide.md`
+
+该评审指南提供：
+- 需求规格评审检查清单
+- 需求完整性、清晰度、可行性验证标准
+- 技术方案评审要点
+- 评审记录模板和流程
+
+**何时需要评审**:
+- 需求规格文档已完成，需要评审验证
+- 用户明确要求对需求规格进行评审
+- OpenSpec proposal 完成，需要技术方案评审
 
 ## 与其他 Skills 的协作
 
 1. **下游**: 需求规格完成后，交给：
    - Backend Engineer（生成后端 OpenSpec）
    - Frontend Engineer（生成前端 OpenSpec）
+   - **注意**: Backend 和 Frontend 可以并行开发，不需要等待对方完成
 
 2. **在 Pre-Execution Review 中的角色**:
    - 评估需求清晰度
    - 提出澄清问题
    - 评估架构复杂度
-   - 预估工作量
+   - 评估技术方案可行性
 
 ## 示例对话