name: phx:review description: 使用并行专家代理审查代码。查找并解释问题，进行严重性分类。是工作流循环的一部分。 argument-hint: [test|security|oban|deploy|iron-laws|all] disable-model-invocation: true

审查 Elixir/Phoenix 代码

通过生成并行专家代理来审查代码。查找并解释问题 — 不要创建任务或修复任何内容。

使用方法

/phx:review                          # 审查所有更改的文件
/phx:review test                     # 仅审查测试文件
/phx:review security                 # 仅运行安全审计
/phx:review oban                     # 仅审查 Oban 工作器
/phx:review deploy                   # 验证部署配置
/phx:review iron-laws                # 仅检查违反 Iron Laws 的情况
/phx:review .claude/plans/auth/plan.md    # 审查计划的实现

参数

$ARGUMENTS = 关注领域或计划文件路径。

工作流程

步骤 1: 识别更改的文件并准备目录

# 关键: 在生成代理之前创建输出目录 — 代理无法创建目录，会在写入时反复失败
SLUG="$(basename "$(ls -td .claude/plans/*/ 2>/dev/null | head -1)" 2>/dev/null || echo "review")"
mkdir -p ".claude/plans/${SLUG}/reviews" ".claude/plans/${SLUG}/summaries"

# 如果没有计划上下文，使用备用目录
mkdir -p .claude/reviews

git diff --name-only HEAD~5   # 最近的更改
git diff --name-only main     # 或从 main 分支的更改

步骤 1b: 加载计划上下文（草稿本）

如果审查一个计划，读取 .claude/plans/${SLUG}/scratchpad.md 以获取计划决策、理由和交接笔记。在提示中包含相关决策，使代理了解代码为何以某种方式编写。这消除了会话考古的需求。

步骤 1c: 检查先前的审查输出

在生成代理之前，检查现有的审查文件：

ls .claude/plans/${SLUG}/reviews/ 2>/dev/null
ls .claude/plans/${SLUG}/summaries/review-consolidated.md 2>/dev/null

如果存在先前的审查，读取整合摘要，并将其作为“先前发现”上下文包含在每个代理的提示中，并指示：“关注新问题。将仍然存在的问题标记为持续。不要重新报告已修复的问题。”

步骤 2: 生成审查代理（必须）

切勿在同一审查中生成相同角色的代理两次。 如果审查一个计划，所有代理应限定在计划的更改文件中，单次通过。不要先运行限定审查再运行更广泛的审查 — 每个角色一次通过。

必须使用 Task 工具生成代理。不要自己分析代码 — 委托给代理。

对于 /phx:review 或 /phx:review all — 在一条消息中生成所有 5 个代理（并行）。 使用这些确切的 subagent_type 值：

代理	subagent_type
Elixir 审查员	`elixir-phoenix:elixir-reviewer`
测试审查员	`elixir-phoenix:testing-reviewer`
安全分析器	`elixir-phoenix:security-analyzer`
验证运行器	`elixir-phoenix:verification-runner`
Iron Law 法官	`elixir-phoenix:iron-law-judge`

生成所有代理时使用 mode: "bypassPermissions" 和 run_in_background: true — 后台代理无法回答交互式 Bash 权限提示。

对于聚焦审查 — 仅生成指定的代理：

参数	subagent_type
`test`	`elixir-phoenix:testing-reviewer`
`security`	`elixir-phoenix:security-analyzer`
`oban`	`elixir-phoenix:oban-specialist`
`deploy`	`elixir-phoenix:deployment-validator`
`iron-laws`	`elixir-phoenix:iron-law-judge`

零代理生成 = 技能失败。

步骤 3: 收集和压缩发现

使用 TaskOutput 并设置 block: true 等待所有代理完全完成。在所有代理都完成之前，不要报告状态 — 忽略中间完成通知。

验证运行器后备方案：如果验证运行器代理失败或超时，直接运行验证。仅对更改的文件进行格式化检查：

mix compile --warnings-as-errors
CHANGED=$(git diff --name-only HEAD~5 | grep '\.exs\?$' | tr '
' ' ')
if [ -n "$CHANGED" ]; then mix format --check-formatted $CHANGED; fi
mix credo --strict && mix test

不要留下未完成的验证。

对于完整审查（5 个代理）：所有代理完成后，生成 elixir-phoenix:context-supervisor 以压缩输出：

提示: "压缩审查代理输出。
  input_dir: .claude/plans/{slug}/reviews
  output_dir: .claude/plans/{slug}/summaries
  output_file: review-consolidated.md
  priority_instructions: 阻塞器和警告：全部保留。
    建议：将类似的压缩成组。
    去冲突：当 iron-law-judge 和 elixir-reviewer 标记相同代码时，保留 iron-law-judge 的发现。"

对于聚焦审查（1 个代理）：跳过主管，直接读取代理输出。

步骤 4: 生成审查摘要

读取整合摘要（完整审查）或代理输出（聚焦审查）。写入到 .claude/plans/{slug}/reviews/{feature}-review.md，并给出判决：通过 | 通过但有警告 | 需要更改 | 阻塞。

步骤 5: 展示发现并询问用户

停止并展示审查。 不要创建任务或修复任何内容。

在阻塞或需要更改时：显示按严重性分类的发现数量，然后通过 AskUserQuestion 提供具体选项：

首先分类 — /phx:triage 将发现转换为任务（推荐）
重新计划修复 — /phx:plan .claude/plans/{slug}/reviews/{file}.md
直接修复 — 在此会话中立即修复阻塞器
我自己处理 — 我将接手

示例: “审查完成 — 3 个阻塞器，5 个警告，2 个建议。推荐先进行分类以优先处理。”

在通过 / 通过但有警告时：建议 /phx:compound、/phx:document、/phx:learn。如果警告显示范围差距，也建议：/phx:plan .claude/plans/{slug}/reviews/{file}.md 从审查发现创建后续计划。

Iron Laws

审查是只读的 — 查找和解释，从不修复
审查后永不自动修复 — 总是先询问用户
总是提供两条路径：/phx:plan 和 /phx:work
在声明前研究 — 代理在声称 CI/CD 或外部服务相关之前必须研究

与工作流程的集成

/phx:plan → /phx:work
       ↓
/phx:review  ← 你在这里（仅发现，无任务）
       ↓
   阻塞？ → /phx:triage, /phx:plan, 或 /phx:work
   通过    → /phx:compound（捕捉解决方案）

参考

references/review-template.md — 完整审查模板格式
references/example-review.md — 示例审查输出
references/blocker-handling.md — 严重性分类