review-go

Go 后端代码审查

参数

• --parallel：如果 Agent 支持并行审查（参见步骤 5），则并发审查各技术领域
• 路径：目标目录（默认为当前工作目录）

步骤 1：识别已更改的文件

git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.go$'

通过条件： 如果没有任何输出，请在摘要中注明 此差异中没有 Go 文件，并跳过步骤 2–6；不要对范围外的文件臆造问题。

步骤 2：检测技术

# Detect BubbleTea TUI
grep -r "charmbracelet/bubbletea\|tea\.Model\|tea\.Cmd" --include="*.go" -l | head -3

# Detect Wish SSH
grep -r "charmbracelet/wish\|ssh\.Session\|wish\.Middleware" --include="*.go" -l | head -3

# Detect Prometheus
grep -r "prometheus/client_golang\|promauto\|prometheus\.Counter" --include="*.go" -l | head -3

# Detect ZeroLog
grep -r "rs/zerolog\|zerolog\.Logger" --include="*.go" -l | head -3

# Check for test files
git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '_test\.go$'

步骤 3：加载验证协议

加载 review-verification-protocol 技能，并在整个审查过程中牢记其检查清单。

步骤 4：加载技能

加载下列适用的技能（打开其 SKILL.md 并遵循其中的要求）。

始终加载：

• go-code-review

根据检测结果有条件地加载：

条件	技能
测试文件已更改	go-testing-code-review
检测到 BubbleTea	bubbletea-code-review
检测到 Wish SSH	wish-ssh-code-review
检测到 Prometheus	prometheus-go-code-review

步骤 5 前的通过条件： 已加载 go-code-review（以及步骤 3 中的验证协议）。仅在对应条件成立时加载条件技能：步骤 1 的差异中包含 _test.go → 加载测试技能；只有当步骤 2 中匹配的 grep 至少返回一个路径时，才加载 BubbleTea/Wish/Prometheus 技能（如果 grep 没有返回结果，不要加载该技能）。

步骤 5：审查

**如果 Agent 支持子 Agent，**则为每个技术领域并行分派一个子 Agent；否则按顺序审查。两种方式都会产生相同的输出。

顺序审查（默认方式，以及子 Agent 不可用时的备用方式）：

1. 加载适用的技能
2. 优先审查 Go 代码质量问题（错误处理、并发、接口）
3. 审查检测到的技术领域
4. 汇总问题

并行审查（--parallel，仅当 Agent 支持子 Agent 时）：

1. 预先检测所有技术
2. 为每个技术领域分派一个子 Agent
3. 每个子 Agent 加载其技能并审查对应领域
4. 等待所有子 Agent 完成
5. 汇总问题

步骤 6：验证问题

报告任何问题前：

1. 重新阅读实际代码（而非只看差异上下文）
2. 对于“未使用”的判断——是否搜索了所有引用？
3. 对于“缺失”的判断——是否检查了框架或上级代码的处理方式？
4. 对于语法问题——是否依据当前版本的文档进行了核实？
5. 删除任何仅属风格偏好、而非实际问题的发现

列出任何严重或主要问题前的硬性门槛（信息性问题可适当放宽）：

1. 阅读深度： 已打开磁盘上的文件，并阅读至少包含该问题的函数或代码块（只阅读差异或摘录内容并不足够）。
2. 未使用／死代码： 已进行引用搜索（rg/IDE），并在问题描述中注明搜索结果（例如，测试之外没有引用）；或者不声称符号未使用。
3. “缺失”行为： 已检查调用方、框架接线方式或文档，以核实所称缺失；或者已降低问题级别或删除该问题。

步骤 7：审查收敛

单轮审查完整性

你必须在一轮审查中报告所有类别（风格、逻辑、类型、测试、安全、性能）中的所有问题。不要把问题留到后续轮次。

提交问题前，请自问：

• “如果所有建议的修复都已应用，我还会在修复后的代码中发现新问题吗？”
• “我是否要求新增代码（测试、类型、模块），而这些代码本身也需要审查？”

如果任一答案为“是”，请在本轮审查中立即包含预计会出现的后续问题，让作者一次性处理所有问题。

范围规则

• 仅审查差异中的代码及直接相关的现有代码
• 不要要求添加差异之前不存在的新功能、测试基础设施或架构变更
• 如果缺少测试覆盖，将其作为一个 Minor 问题标出（“缺少对 X、Y、Z 的测试覆盖”）——不要指定会引入大量新代码的实现细节，例如模拟库、行为提取或依赖注入模式
• 类型规范、文档和命名问题属于 Minor，除非它们影响公共 API 契约
• 不要要求添加新依赖（例如 Mox、测试库、linter 插件）

修复复杂度预算

无论修复规模如何，都应按实际严重程度标出对现有代码的修复要求。

但是，对差异之前不存在的新代码的要求必须归类为 Informational：

• 添加新依赖（例如 Mox、linter 插件）
• 创建全新的模块、文件或测试套件
• 提取新行为、协议或抽象

这些是供作者考虑在后续工作中采纳的改进建议，不是审查阻碍项。

迭代策略

如果这是修复后的重新审查：

• 仅验证先前指出的问题是否已正确解决
• 不要提出与先前问题无关的新发现
• 接受未修复的 Minor/Nice-to-Have 问题，不要再次标出
• 重新审查的目标是验证，而非发现

输出格式

## Review Summary

[1-2 sentence overview of findings]

## Issues

### Critical (Blocking)

1. [FILE:LINE] ISSUE_TITLE
   - Issue: Description of what's wrong
   - Why: Why this matters (bug, race condition, resource leak, security)
   - Fix: Specific recommended fix

### Major (Should Fix)

2. [FILE:LINE] ISSUE_TITLE
   - Issue: ...
   - Why: ...
   - Fix: ...

### Minor (Nice to Have)

N. [FILE:LINE] ISSUE_TITLE
   - Issue: ...
   - Why: ...
   - Fix: ...

### Informational (For Awareness)

N. [FILE:LINE] SUGGESTION_TITLE
   - Suggestion: ...
   - Rationale: ...

## Good Patterns

- [FILE:LINE] Pattern description (preserve this)

## Verdict

Ready: Yes | No | With fixes 1-N (Critical/Major only; Minor items are acceptable)
Rationale: [1-2 sentences]

修复后验证

应用修复后，运行：

go build ./...
go vet ./...
golangci-lint run
go test -v -race ./...

所有检查都必须通过才能批准。

规则

• 审查前加载技能（而不是审查后）
• 按顺序为每个问题编号（1、2、3……）
• 为每个问题注明 FILE:LINE
• 清晰区分 Issue/Why/Fix
• 按实际严重程度分类
• 使用 -race 标志检查竞态条件
• 修复后运行验证
• 一次性报告所有问题——不要留待后续迭代再提出
• 重新审查仅验证先前的修复，不进行新的发现
• 对新代码（新模块、依赖、测试套件）的要求属于 Informational，不会阻止批准
• Verdict 忽略 Minor 和 Informational 项——只有 Critical 和 Major 会阻止批准