---
name: multi-perspective-review
description: >
  多视角评审技能，融合 gstack 的 CEO/Design/Eng/DevEx 四视角 review 方法论。
  在每次评审中从多个角色视角审查同一产出，避免单一视角盲区，
  增强现有 /team-review 的评审深度。
---

# Multi-Perspective Review

## 用途

- 把"只从工程视角 review"改成"从多个利益相关方视角同时 review"。
- 适合方案评审、代码评审、上线前检查等需要全面审视的场景。
- 增强现有 `/team-review` 的覆盖面，补充非工程维度的审视。

## 预设视角

### 用户/产品视角

- 这个改动是否真正解决了用户的问题？
- 用户操作路径是否直觉？有没有让用户困惑的状态？
- 异常情况下用户看到什么？能否自助恢复？
- 权限不足、数据为空、网络异常时的体验如何？

### 工程视角

- 代码可读性、可维护性、边界处理是否到位？
- 测试覆盖是否充分？测试能否捕获回归？
- 性能是否可接受？有没有明显的 N+1、全表扫描、内存泄漏？
- 是否遵循现有架构模式和编码规范？

### 安全/合规视角

- 输入验证是否到位？有没有注入风险？
- 鉴权和授权是否正确？有没有越权访问的可能？
- 日志中是否泄露敏感信息？
- 数据处理是否符合合规要求？

### 运维/可观测性视角

- 监控和告警是否配套？关键路径是否有 metric？
- 日志是否结构化且可检索？
- 部署和回滚路径是否清晰？
- 配置变更是否有版本管理？

## 默认做法

### 1. 确定评审范围

从 `/team-review` 或用户请求中接收评审对象：
- 代码变更（diff）
- 方案文档
- 架构设计
- 上线方案

### 2. 多视角扫描

对每个评审对象，从 4 个视角分别产出发现：

```markdown
### 用户/产品视角
- ✅ {通过项}
- ⚠️ {关注项}（Revision Gate）
- ❌ {阻塞项}（Abort Gate）

### 工程视角
- ✅ {通过项}
- ⚠️ {关注项}
- ❌ {阻塞项}

### 安全/合规视角
- ✅ {通过项}
- ⚠️ {关注项}
- ❌ {阻塞项}

### 运维/可观测性视角
- ✅ {通过项}
- ⚠️ {关注项}
- ❌ {阻塞项}
```

### 3. 综合结论

汇总所有视角的发现，输出：
- **放行建议**：放行 / 有条件放行 / 不建议放行
- **阻塞项列表**：跨视角合并后的 Abort Gate 项
- **改进项列表**：Revision Gate 项，按优先级排序
- **视角覆盖度**：标注哪些视角的审查是充分的，哪些因信息不足需要补充

## 与现有能力的关系

| 能力 | 职责 |
|------|------|
| `multi-perspective-review` | 多视角审查框架（本技能） |
| `/team-review` | 标准 QA 评审主链命令 |
| `code-reviewer` agent | 工程视角的代码级 review |
| `security-reviewer` agent | 安全视角的深度审查 |
| `cross-model-review` | 跨模型第二意见（可选叠加） |

## 触发信号

- `/team-review` 中的评审任务。
- 方案评审（Design Review Board）。
- 用户要求"全面审查"或"多角度 review"。
- 关键功能（支付、鉴权、数据迁移）的代码 review。

## 配套约束

1. **不替代专项 review**：多视角 review 是快速全面扫描，深度问题仍需专项 agent（`security-reviewer`、`database-reviewer`）。
2. **证据可追溯**：每个发现必须指向具体的代码位置或文档段落。
3. **时间控制**：单次多视角 review 控制在 4 个视角以内，避免分析过度。