代码审查工作流Skill workflows-review

---

name: workflows-review description: 使用多代理分析、超思考和工作树进行详尽的代码审查

参数

[PR 编号, GitHub URL, 分支名称, 或最新]

审查命令

<command_purpose> 使用多代理分析、超思考和 Git 工作树进行详尽的代码审查，以进行深度本地检查。 </command_purpose>

介绍

<role>高级代码审查架构师，专长于安全、性能、架构和质量保证</role>

先决条件

<requirements>

• 安装了 GitHub CLI (gh) 并经过身份验证的 Git 仓库
• 干净的主分支/主分支
• 创建工作树和访问仓库的适当权限
• 对于文档审查：Markdown 文件或文档的路径 </requirements>

主要任务

1. 确定审查目标与设置（始终首先执行）

<review_target> #$ARGUMENTS </review_target>

<thinking> 首先，我需要确定审查目标类型并设置代码进行分析。 </thinking>

立即行动：

<task_list>

• [ ] 确定审查类型：PR 编号（数字）、GitHub URL、文件路径（.md）或空（当前分支）
• [ ] 检查当前 git 分支
• [ ] 如果已经在目标分支上（PR 分支、请求的分支名称，或已为审查签出的分支）→ 在当前分支上进行分析
• [ ] 如果与审查目标不同的分支 → 提供使用工作树："使用 git-worktree 技能进行隔离调用 skill: git-worktree 与分支名称
• [ ] 使用 gh pr view --json 获取 PR 元数据，包括标题、正文、文件、链接问题
• [ ] 设置语言特定分析工具
• [ ] 准备安全扫描环境
• [ ] 确保我们在正在审查的分支上。使用 gh pr checkout 切换到分支或手动签出分支。

确保代码已准备好进行分析（无论是在工作树中还是在当前分支上）。只有这样才进行下一步。

</task_list>

受保护工件

<protected_artifacts> 以下路径是复合工程流水线工件，绝不能由任何审查代理标记为删除、移除或 gitignore：

• docs/plans/*.md — 由 /workflows:plan 创建的计划文件。这些是跟踪实施进度的活动文档（复选框由 /workflows:work 勾选）。
• docs/solutions/*.md — 流水线期间创建的解决方案文档。

如果审查代理标记了这些目录中的任何文件进行清理或移除，在综合过程中丢弃该发现。不要为其创建待办事项。 </protected_artifacts>

并行代理审查 PR：

<parallel_tasks>

同时运行所有或大部分这些代理：

1. 任务 kieran-rails-reviewer(PR 内容)
2. 任务 dhh-rails-reviewer(PR 标题)
3. 如果使用 turbo：任务 rails-turbo-expert(PR 内容)
4. 任务 git-history-analyzer(PR 内容)
5. 任务 dependency-detective(PR 内容)
6. 任务 pattern-recognition-specialist(PR 内容)
7. 任务 architecture-strategist(PR 内容)
8. 任务 code-philosopher(PR 内容)
9. 任务 security-sentinel(PR 内容)
10. 任务 performance-oracle(PR 内容)
11. 任务 devops-harmony-analyst(PR 内容)
12. 任务 data-integrity-guardian(PR 内容)
13. 任务 agent-native-reviewer(PR 内容) - 验证新功能是否可被代理访问

</parallel_tasks>

条件代理（如果适用则运行）：

<conditional_agents>

这些代理仅在 PR 符合特定条件时运行。检查 PR 文件列表以确定是否适用：

如果 PR 包含数据库迁移（db/migrate/*.rb 文件）或数据回填：

14. 任务 data-migration-expert(PR 内容) - 验证 ID 映射匹配生产环境，检查交换值，验证回滚安全性
15. 任务 deployment-verification-agent(PR 内容) - 创建 Go/No-Go 部署检查清单，包含 SQL 验证查询

何时运行迁移代理：

• PR 包含匹配 db/migrate/*.rb 的文件
• PR 修改存储 ID、枚举或映射的列
• PR 包含数据回填脚本或 rake 任务
• PR 更改数据读写方式（例如，从外键列更改为字符串列）
• PR 标题/正文提及：迁移、回填、数据转换、ID 映射

这些代理检查的内容：

• data-migration-expert：验证硬编码映射匹配生产现实（防止交换 ID），检查孤立关联，验证双写模式
• deployment-verification-agent：生成可执行的部署前后检查清单，包含 SQL 查询、回滚程序和监控计划

</conditional_agents>

4. 超思考深度探索阶段

<ultrathink_instruction> 对于以下每个阶段，投入最大认知努力。逐步思考。考虑所有角度。质疑假设。并将所有审查综合呈现给用户。</ultrathink_instruction>

<deliverable> 完整的系统上下文映射，包含组件交互 </deliverable>

阶段 3：利益相关者视角分析

<thinking_prompt> 超思考：设身处地为每个利益相关者着想。什么对他们重要？他们的痛点是什么？ </thinking_prompt>

<stakeholder_perspectives>

1. 开发者视角 <questions>

   • 这有多容易理解和修改？
   • API 是否直观？
   • 调试是否直接了当？
   • 我能轻松测试吗？ </questions>

2. 运维视角 <questions>

   • 我如何安全部署这个？
   • 有哪些指标和日志可用？
   • 如何排查问题？
   • 资源需求是什么？ </questions>

3. 最终用户视角 <questions>

   • 功能是否直观？
   • 错误消息有帮助吗？
   • 性能可接受吗？
   • 是否解决了我的问题？ </questions>

4. 安全团队视角 <questions>

   • 攻击面是什么？
   • 有哪些合规要求？
   • 数据如何保护？
   • 审计能力是什么？ </questions>

5. 业务视角 <questions>

   • 投资回报率是什么？
   • 是否有法律/合规风险？
   • 这如何影响上市时间？
   • 总拥有成本是什么？ </questions> </stakeholder_perspectives>

阶段 4：场景探索

<thinking_prompt> 超思考：探索边缘情况和故障场景。什么可能出错？系统在压力下的行为如何？ </thinking_prompt>

<scenario_checklist>

• [ ] 快乐路径：正常操作，输入有效
• [ ] 无效输入：空值、空数据、格式错误数据
• [ ] 边界条件：最小/最大值、空集合
• [ ] 并发访问：竞态条件、死锁
• [ ] 扩展测试：10 倍、100 倍、1000 倍正常负载
• [ ] 网络问题：超时、部分故障
• [ ] 资源耗尽：内存、磁盘、连接
• [ ] 安全攻击：注入、溢出、拒绝服务
• [ ] 数据损坏：部分写入、不一致
• [ ] 级联故障：下游服务问题 </scenario_checklist>

6. 多角度审查视角

技术卓越角度

• 代码工艺评估
• 工程最佳实践
• 技术文档质量
• 工具与自动化评估

业务价值角度

• 功能完整性验证
• 对用户的性能影响
• 成本效益分析
• 上市时间考虑

风险管理角度

• 安全风险评估
• 运维风险评估
• 合规风险验证
• 技术债务积累

团队动态角度

• 代码审查礼仪
• 知识分享有效性
• 协作模式
• 指导机会

4. 简化与极简主义审查

运行任务 code-simplicity-reviewer() 以查看是否可以简化代码。

5. 发现综合与待办事项创建使用 file-todos 技能

<critical_requirement> 所有发现必须使用 file-todos 技能存储在 todos/ 目录中。综合后立即创建待办文件 — 不要首先呈现发现供用户批准。使用该技能进行结构化待办管理。 </critical_requirement>

步骤 1：综合所有发现

<thinking> 整合所有代理报告为分类发现列表。 移除重复项，按严重性和影响优先级排序。 </thinking>

<synthesis_tasks>

• [ ] 收集所有并行代理的发现
• [ ] 丢弃任何建议删除或 gitignore docs/plans/ 或 docs/solutions/ 中文件的发现（参见上方受保护工件）
• [ ] 按类型分类：安全、性能、架构、质量等
• [ ] 分配严重性级别：🔴 关键 (P1)、🟡 重要 (P2)、🔵 可有可无 (P3)
• [ ] 移除重复或重叠的发现
• [ ] 估计每个发现的努力（小/中/大）

</synthesis_tasks>

步骤 2：使用 file-todos 技能创建待办文件

<critical_instruction> 使用 file-todos 技能为所有发现立即创建待办文件。不要逐个呈现发现请求用户批准。使用该技能并行创建所有待办文件，然后向用户总结结果。 </critical_instruction>

实施选项：

选项 A：直接文件创建（快速）

• 使用 Write 工具直接创建待办文件
• 所有发现并行处理以提高速度
• 使用标准模板 .claude/skills/file-todos/assets/todo-template.md
• 遵循命名约定：{issue_id}-pending-{priority}-{description}.md

选项 B：并行子代理（推荐用于规模） 对于具有 15+ 发现的大型 PR，使用子代理并行创建发现文件：

# 启动多个发现创建代理并行
Task() - 为第一个发现创建待办
Task() - 为第二个发现创建待办
Task() - 为第三个发现创建待办
等等，为每个发现。

子代理可以：

• 同时处理多个发现
• 写入详细的待办文件，填充所有部分
• 按严重性组织发现
• 创建全面的建议解决方案
• 添加验收标准和工作日志
• 比顺序处理快得多

执行策略：

1. 将所有发现综合为类别（P1/P2/P3）
2. 按严重性分组发现
3. 启动 3 个并行子代理（每个严重性级别一个）
4. 每个子代理使用 file-todos 技能创建其批次的待办
5. 整合结果并呈现总结

流程（使用 file-todos 技能）：

1. 对于每个发现：

   • 确定严重性（P1/P2/P3）
   • 写入详细的问题陈述和发现
   • 创建 2-3 个建议解决方案，包含优点/缺点/努力/风险
   • 估计努力（小/中/大）
   • 添加验收标准和工作日志

2. 使用 file-todos 技能进行结构化待办管理：

   skill: file-todos
   

   该技能提供：

   • 模板位置：.claude/skills/file-todos/assets/todo-template.md
   • 命名约定：{issue_id}-{status}-{priority}-{description}.md
   • YAML 前驱结构：状态、优先级、issue_id、标签、依赖项
   • 所有必需部分：问题陈述、发现、解决方案等

3. 并行创建待办文件：

   {next_id}-pending-{priority}-{description}.md
   

4. 示例：

   001-pending-p1-path-traversal-vulnerability.md
   002-pending-p1-api-response-validation.md
   003-pending-p2-concurrency-limit.md
   004-pending-p3-unused-parameter.md
   

5. 遵循 file-todos 技能的模板结构：.claude/skills/file-todos/assets/todo-template.md

待办文件结构（来自模板）：

每个待办必须包括：

• YAML 前驱：状态、优先级、issue_id、标签、依赖项
• 问题陈述：什么坏了/缺失，为什么重要
• 发现：来自代理的发现，带证据/位置
• 建议解决方案：2-3 个选项，每个包含优点/缺点/努力/风险
• 推荐操作：（在分类期间填充，初始留空）
• 技术细节：受影响文件、组件、数据库更改
• 验收标准：可测试的检查清单项目
• 工作日志：带操作和学习的日期记录
• 资源：链接到 PR、问题、文档、类似模式

文件命名约定：

{issue_id}-{status}-{priority}-{description}.md

示例：
- 001-pending-p1-security-vulnerability.md
- 002-pending-p2-performance-optimization.md
- 003-pending-p3-code-cleanup.md

状态值：

• pending - 新发现，需要分类/决策
• ready - 经理批准，准备处理
• complete - 工作完成

优先级值：

• p1 - 关键（阻止合并、安全/数据问题）
• p2 - 重要（应修复、架构/性能）
• p3 - 可有可无（增强、清理）

标签： 始终添加 code-review 标签，加上：security、performance、architecture、rails、quality 等

步骤 3：总结报告

创建所有待办文件后，呈现全面总结：

## ✅ 代码审查完成

**审查目标：** PR #XXXX - [PR 标题] **分支：** [分支名称]

### 发现总结：

- **总发现：** [X]
- **🔴 关键 (P1)：** [计数] - 阻止合并
- **🟡 重要 (P2)：** [计数] - 应修复
- **🔵 可有可无 (P3)：** [计数] - 增强

### 创建的待办文件：

**P1 - 关键（阻止合并）：**

- `001-pending-p1-{发现}.md` - {描述}
- `002-pending-p1-{发现}.md` - {描述}

**P2 - 重要：**

- `003-pending-p2-{发现}.md` - {描述}
- `004-pending-p2-{发现}.md` - {描述}

**P3 - 可有可无：**

- `005-pending-p3-{发现}.md` - {描述}

### 使用的审查代理：

- kieran-rails-reviewer
- security-sentinel
- performance-oracle
- architecture-strategist
- agent-native-reviewer
- [其他代理]

### 下一步：

1. **处理 P1 发现：** 关键 — 必须在合并前修复

   - 详细审查每个 P1 待办
   - 实施修复或请求豁免
   - 合并 PR 前验证修复

2. **分类所有待办：**
   ```bash
   ls todos/*-pending-*.md  # 查看所有待办待办
   /triage                  # 使用斜杠命令进行交互分类
   ```

3. 处理批准的待办：

   /resolve_todo_parallel  # 高效修复所有批准项
   

4. 跟踪进度：

   • 状态更改时重命名文件：pending → ready → complete
   • 工作时更新工作日志
   • 提交待办：git add todos/ && git commit -m "refactor: add code review findings"

严重性细分：

🔴 P1（关键 — 阻止合并）：

• 安全漏洞
• 数据损坏风险
• 破坏性更改
• 关键架构问题

🟡 P2（重要 — 应修复）：

• 性能问题
• 显著架构关注点
• 主要代码质量问题
• 可靠性问题

🔵 P3（可有可无）：

• 次要改进
• 代码清理
• 优化机会
• 文档更新

### 7. 端到端测试（可选）

<detect_project_type>

**首先，从 PR 文件检测项目类型：**

| 指示器 | 项目类型 |
|-----------|--------------|
| `*.xcodeproj`、`*.xcworkspace`、`Package.swift` (iOS) | iOS/macOS |
| `Gemfile`、`package.json`、`app/views/*`、`*.html.*` | Web |
| 既有 iOS 文件又有 Web 文件 | 混合（测试两者） |

</detect_project_type>

<offer_testing>

呈现总结报告后，根据项目类型提供适当测试：

**对于 Web 项目：**
```markdown
**"是否想在受影响页面上运行浏览器测试？"**
1. 是 — 运行 `/test-browser`
2. 否 — 跳过

对于 iOS 项目：

**"是否想在应用程序上运行 Xcode 模拟器测试？"**
1. 是 — 运行 `/xcode-test`
2. 否 — 跳过

对于混合项目（例如，Rails + Hotwire Native）：

**"是否想运行端到端测试？"**
1. 仅 Web — 运行 `/test-browser`
2. 仅 iOS — 运行 `/xcode-test`
3. 两者 — 运行两个命令
4. 否 — 跳过

</offer_testing>

如果用户接受 Web 测试：

生成子代理运行浏览器测试（保留主上下文）：

Task general-purpose("为 PR #[编号] 运行 `/test-browser`。测试所有受影响页面，检查控制台错误，通过创建待办和修复处理失败。")

子代理将：

1. 识别 PR 影响的页面
2. 导航到每个页面并捕获快照（使用 Playwright MCP 或 agent-browser CLI）
3. 检查控制台错误
4. 测试关键交互
5. 在 OAuth/电子邮件/支付流程时暂停进行人工验证
6. 为任何失败创建 P1 待办
7. 修复并重试直到所有测试通过

独立： /test-browser [PR 编号]

如果用户接受 iOS 测试：

生成子代理运行 Xcode 测试（保留主上下文）：

Task general-purpose("为方案 [名称] 运行 `/xcode-test`。为模拟器构建、安装、启动、截图、检查崩溃。")

子代理将：

1. 验证 XcodeBuildMCP 已安装
2. 发现项目和方案
3. 为 iOS 模拟器构建
4. 安装并启动应用程序
5. 截取关键屏幕的截图
6. 捕获控制台日志以获取错误
7. 在苹果登录、推送、应用内购买时暂停进行人工验证
8. 为任何失败创建 P1 待办
9. 修复并重试直到所有测试通过

独立： /xcode-test [方案]

重要：P1 发现阻止合并

任何 🔴 P1（关键） 发现必须在合并 PR 前解决。突出显示这些并确保在批准 PR 前解决。