review-go

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Go Backend Code Review

Go后端代码评审

Arguments

参数

```
--parallel
```
: Spawn specialized subagents per technology area
Path: Target directory (default: current working directory)

```
--parallel
```
: 针对每个技术领域生成专门的子Agent
路径：目标目录（默认：当前工作目录）

Step 1: Identify Changed Files

步骤1：识别变更文件

bash

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

bash

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

Step 2: Detect Technologies

步骤2：检测技术栈

bash

undefined

bash

undefined

Detect BubbleTea TUI

检测BubbleTea TUI

grep -r "charmbracelet/bubbletea|tea.Model|tea.Cmd" --include="*.go" -l | head -3

Detect Wish SSH

检测Wish SSH

grep -r "charmbracelet/wish|ssh.Session|wish.Middleware" --include="*.go" -l | head -3

Detect Prometheus

检测Prometheus

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

Detect ZeroLog

检测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$'

undefined

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

undefined

Step 3: Load Verification Protocol

步骤3：加载验证协议

Load

beagle-go:review-verification-protocol

skill and keep its checklist in mind throughout the review.

加载

beagle-go:review-verification-protocol

技能，并在整个评审过程中牢记其检查清单。

Step 4: Load Skills

步骤4：加载技能

Use the

Skill

tool to load each applicable skill (e.g.,

Skill(skill: "beagle-go:go-code-review")

Always load:

```
beagle-go:go-code-review
```

Conditionally load based on detection:

Condition	Skill
Test files changed	`beagle-go:go-testing-code-review`
BubbleTea detected	`beagle-go:bubbletea-code-review`
Wish SSH detected	`beagle-go:wish-ssh-code-review`
Prometheus detected	`beagle-go:prometheus-go-code-review`

使用

Skill

工具加载每个适用的技能（例如：

Skill(skill: "beagle-go:go-code-review")

）。

必须加载：

```
beagle-go:go-code-review
```

根据检测结果条件加载：

条件	技能
测试文件有变更	`beagle-go:go-testing-code-review`
检测到BubbleTea	`beagle-go:bubbletea-code-review`
检测到Wish SSH	`beagle-go:wish-ssh-code-review`
检测到Prometheus	`beagle-go:prometheus-go-code-review`

Step 5: Review

步骤5：评审

Sequential (default):

Load applicable skills
Review Go quality issues first (error handling, concurrency, interfaces)
Review detected technology areas
Consolidate findings

Parallel (--parallel flag):

Detect all technologies upfront
Spawn one subagent per technology area with
```
Task
```
tool
Each agent loads its skill and reviews its domain
Wait for all agents
Consolidate findings

顺序模式（默认）：

加载适用技能
先评审Go代码质量问题（错误处理、并发、接口）
评审检测到的技术领域
整合评审结果

并行模式（--parallel参数）：

预先检测所有技术栈
使用
```
Task
```
工具为每个技术领域生成一个子Agent
每个Agent加载对应技能并评审其领域内容
等待所有Agent完成
整合评审结果

Step 6: Verify Findings

步骤6：验证评审结果

Before reporting any issue:

Re-read the actual code (not just diff context)
For "unused" claims - did you search all references?
For "missing" claims - did you check framework/parent handling?
For syntax issues - did you verify against current version docs?
Remove any findings that are style preferences, not actual issues

在报告任何问题之前：

重新阅读实际代码（不只是差异上下文）
对于“未使用”的判断 - 你是否搜索了所有引用？
对于“缺失”的判断 - 你是否检查了框架/父级处理逻辑？
对于语法问题 - 你是否对照当前版本的文档进行了验证？
移除所有属于风格偏好而非实际问题的评审结果

Step 7: Review Convergence

步骤7：评审收敛

Single-Pass Completeness

单次评审完整性

You MUST report ALL issues across ALL categories (style, logic, types, tests, security, performance) in a single review pass. Do not hold back issues for later rounds.

Before submitting findings, ask yourself:

"If all my recommended fixes are applied, will I find NEW issues in the fixed code?"
"Am I requesting new code (tests, types, modules) that will itself need review?"

If yes to either: include those anticipated downstream issues NOW, in this review, so the author can address everything at once.

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

提交评审结果前，自问：

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

如果任一问题答案为是：请在本次评审中立即包含这些预期的后续问题，以便作者一次性解决所有问题。

Scope Rules

范围规则

Review ONLY the code in the diff and directly related existing code
Do NOT request new features, test infrastructure, or architectural changes that didn't exist before the diff
If test coverage is missing, flag it as ONE Minor issue ("Missing test coverage for X, Y, Z") — do NOT specify implementation details like mock libraries, behaviour extraction, or dependency injection patterns that would introduce substantial new code
Typespecs, documentation, and naming issues are Minor unless they affect public API contracts
Do NOT request adding new dependencies (e.g. Mox, testing libraries, linter plugins)

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

Fix Complexity Budget

修复复杂度预算

Fixes to existing code should be flagged at their real severity regardless of size.

However, requests for net-new code that didn't exist before the diff must be classified as Informational:

Adding a new dependency (e.g. Mox, a linter plugin)
Creating entirely new modules, files, or test suites
Extracting new behaviours, protocols, or abstractions

These are improvement suggestions for the author to consider in future work, not review blockers.

现有代码的修复应根据实际严重程度标记。

然而，对于变更前不存在的全新代码的请求必须归类为信息性建议：

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

这些是供作者在未来工作中考虑的改进建议，而非评审阻塞项。

Iteration Policy

迭代规则

If this is a re-review after fixes were applied:

ONLY verify that previously flagged issues were addressed correctly
Do NOT introduce new findings unrelated to the previous review's issues
Accept Minor/Nice-to-Have issues that weren't fixed — do not re-flag them
The goal of re-review is VERIFICATION, not discovery

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

仅验证之前标记的问题是否已正确解决
不得引入与之前评审问题无关的新发现
接受未修复的次要/锦上添花问题——不得重新标记
重新评审的目标是验证，而非发现新问题

Output Format

输出格式

markdown

undefined

markdown

undefined

Review Summary

评审摘要

[1-2 sentence overview of findings]

[1-2句话概述评审结果]

Issues

问题

Critical (Blocking)

严重（阻塞）

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

[文件:行号] 问题标题
- 问题：错误内容描述
- 原因：该问题的影响（bug、竞态条件、资源泄漏、安全问题）
- 修复：具体的推荐修复方案

Major (Should Fix)

主要（应修复）

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

[文件:行号] 问题标题
- 问题：...
- 原因：...
- 修复：...

Minor (Nice to Have)

次要（锦上添花）

N. [FILE:LINE] ISSUE_TITLE

Issue: ...
Why: ...
Fix: ...

N. [文件:行号] 问题标题

问题：...
原因：...
修复：...

Informational (For Awareness)

信息性（仅供参考）

N. [FILE:LINE] SUGGESTION_TITLE

Suggestion: ...
Rationale: ...

N. [文件:行号] 建议标题

建议：...
理由：...

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]

undefined

可通过：是 | 否 | 需修复1-N项（仅严重/主要问题；次要问题可接受）理由：[1-2句话]

undefined

Post-Fix Verification

修复后验证

After fixes are applied, run:

bash

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

All checks must pass before approval.

修复完成后，运行：

bash

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

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

Rules

规则

Load skills BEFORE reviewing (not after)
Number every issue sequentially (1, 2, 3...)
Include FILE:LINE for each issue
Separate Issue/Why/Fix clearly
Categorize by actual severity
Check for race conditions with
```
-race
```
flag
Run verification after fixes
Report ALL issues in a single pass — do not hold back findings for later iterations
Re-reviews verify previous fixes ONLY — no new discovery
Requests for net-new code (new modules, dependencies, test suites) are Informational, not blocking
The Verdict ignores Minor and Informational items — only Critical and Major block approval

评审前先加载技能（而非之后）
为每个问题顺序编号（1、2、3...）
每个问题包含[文件:行号]
清晰区分问题/原因/修复
根据实际严重程度分类
使用
```
-race
```
标志检查竞态条件
修复后运行验证
单次评审报告所有问题——不得将发现留到后续迭代
重新评审仅验证之前的修复——不进行新发现
对全新代码（新模块、依赖、测试套件）的请求属于信息性建议，而非阻塞项
结论忽略次要和信息性项——仅严重和主要问题会阻塞批准