review-elixir

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Elixir Code Review

Elixir代码评审

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 '\.ex$|\.exs$|\.heex$'

bash

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

Step 2: Verify Linter/Formatter Status

步骤2：验证代码检查器/格式化工具状态

CRITICAL: Run project linters BEFORE flagging any style issues.

bash

undefined

重要提示：在标记任何样式问题之前，先运行项目代码检查器。

bash

undefined

Check formatting

检查格式化情况

mix format --check-formatted

Check Credo if present

检查是否存在Credo

if [ -f ".credo.exs" ] || grep -q ":credo" mix.exs 2>/dev/null; then mix credo --strict fi

Check Dialyzer if configured

检查是否配置了Dialyzer

if grep -q ":dialyxir" mix.exs 2>/dev/null; then mix dialyzer --format short fi


**Rules:**
- If a linter passes for a specific rule, DO NOT flag that issue manually
- Linter configuration is authoritative for style rules
- Only flag issues that linters cannot detect (semantic issues, architectural problems)

if grep -q ":dialyxir" mix.exs 2>/dev/null; then mix dialyzer --format short fi


**规则:**
- 如果某个规则通过了代码检查器的验证，请勿手动标记该问题
- 代码检查器的配置是样式规则的权威依据
- 仅标记代码检查器无法检测到的问题（语义问题、架构问题）

Step 3: Detect Technologies

步骤3：检测技术栈

bash

undefined

bash

undefined

Detect Phoenix

检测Phoenix

grep -r "use Phoenix|Phoenix.Router|Phoenix.Controller" --include="*.ex" -l | head -3

Detect LiveView

检测LiveView

grep -r "use Phoenix.LiveView|Phoenix.LiveComponent|~H" --include="*.ex" -l | head -3

Detect Oban

检测Oban

grep -r "use Oban.Worker|Oban.insert" --include="*.ex" -l | head -3

Check for test files

检查测试文件

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

undefined

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

undefined

Step 4: Load Verification Protocol

步骤4：加载验证协议

Load

beagle-elixir:review-verification-protocol

skill and keep its checklist in mind throughout the review.

加载

beagle-elixir:review-verification-protocol

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

Step 5: Load Skills

步骤5：加载技能

Use the

Skill

tool to load each applicable skill.

Always load:

```
beagle-elixir:elixir-code-review
```

Conditionally load based on detection:

Condition	Skill
Phoenix detected	`beagle-elixir:phoenix-code-review`
LiveView detected	`beagle-elixir:liveview-code-review`
Performance focus requested	`beagle-elixir:elixir-performance-review`
Security focus requested	`beagle-elixir:elixir-security-review`
Test files changed	`beagle-elixir:exunit-code-review`

使用

Skill

工具加载所有适用的技能。

必须加载的技能:

```
beagle-elixir:elixir-code-review
```

根据检测结果条件加载:

条件	技能
检测到Phoenix	`beagle-elixir:phoenix-code-review`
检测到LiveView	`beagle-elixir:liveview-code-review`
要求关注性能	`beagle-elixir:elixir-performance-review`
要求关注安全	`beagle-elixir:elixir-security-review`
测试文件有变更	`beagle-elixir:exunit-code-review`

Step 6: Review

步骤6：评审

Sequential (default):

Load applicable skills
Review Elixir quality issues first
Review Phoenix patterns (if detected)
Review LiveView patterns (if detected)
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

串行模式（默认）:

加载所有适用技能
首先评审Elixir质量问题
评审Phoenix模式（如果检测到）
评审LiveView模式（如果检测到）
评审检测到的其他技术领域
整合评审结果

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

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

Before Flagging Issues

标记问题前的准备

Check CLAUDE.md for documented intentional patterns
Check code comments around the flagged area for "intentional", "optimization", or "NOTE:"
Trace the code path before claiming missing coverage
Consider framework idioms - what looks wrong generically may be correct for Elixir/Phoenix

查看CLAUDE.md中的文档化意向模式
查看标记区域周围的代码注释，寻找“intentional”（有意为之）、“optimization”（优化）或“NOTE:”等字样
追踪代码路径后再声称存在覆盖缺失
考虑框架惯用写法——从通用角度看可能存在问题的写法，在Elixir/Phoenix中可能是正确的

Step 7: Verify Findings

步骤7：验证评审发现

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 8: Review Convergence

步骤8：评审收敛

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、代码检查器插件）
创建全新模块、文件或测试套件
提取新的behaviour、协议或抽象

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

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, type safety, 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

mix format --check-formatted
mix credo --strict
mix dialyzer
mix test

All checks must pass before approval.

修复完成后，运行以下命令：

bash

mix format --check-formatted
mix credo --strict
mix dialyzer
mix test

所有检查必须通过后方可批准。

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
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...）
每个问题需包含文件:行号
清晰区分问题/原因/修复部分
根据实际严重程度分类
修复后运行验证
单次评审报告所有问题——请勿保留至后续迭代
重新评审仅验证之前的修复——不进行新发现
请求添加全新代码（新模块、依赖、测试套件）属于信息性建议，非阻塞项
评审结论忽略次要和信息性项——仅严重和主要问题会阻塞批准