PR Code Review (Local)

Perform a thorough local code review with full project context — reads source files directly, no API truncation limits.

Announce at start: "I'm using pr-review skill to review the pull request."

Usage

/pr-review [pr_number]

$ARGUMENTS is an optional PR number. If omitted, auto-detect from the current branch.

---

Steps

Step 1 — Determine PR Number

If $ARGUMENTS is non-empty, use it as the PR number.

Otherwise run:

gh pr view --json number -q .number

If this also fails (not on a PR branch), abort with:

No PR number provided and cannot detect one from the current branch. Usage: /pr-review <pr_number>

Step 2 — Check CI Status

gh pr view <PR_NUMBER> --json statusCheckRollup \
  --jq '.statusCheckRollup[] | {name: .name, status: .status, conclusion: .conclusion}'

必检 job 列表：

• Code Quality
• Unit Tests (ubuntu-latest)
• Unit Tests (macos-14)
• Unit Tests (windows-2022)
• Coverage Test
• i18n-check

（build-test 为可选 job，不纳入必检范围。）

特殊情形： 满足以下任一条件时，跳过此步骤，直接继续：

• statusCheckRollup 为空（CI 从未触发）
• statusCheckRollup 非空，但所有必检 job 均不在列表中（说明 pr-checks.yml 工作流整体未触发，如仅改动 docs/md 文件的 PR）

解析逻辑： 对上述必检 job 逐一检查，跳过列表中不存在的 job，对存在的分三种情形处理：

情形 1 — 全部通过（所有必检 job 均满足 status == COMPLETED && conclusion == SUCCESS）

直接继续后续步骤，无需提示。

情形 2 — 部分仍在运行（存在 status 为 QUEUED 或 IN_PROGRESS 的必检 job）

显示警告并询问：

⏳ 以下 CI job 尚未完成：[job 列表] PR CI 未全部完成，建议等待后再 review。是否仍要继续？(yes/no)

• 用户选 no → 终止
• 用户选 yes → 继续后续步骤

情形 3 — 存在失败（存在 conclusion 为 FAILURE 或 CANCELLED 的必检 job）

显示警告并询问：

❌ 以下 CI job 未通过：[job 列表及结论] PR CI 存在失败，review 结论可能不准确。是否仍要继续？(yes/no)

• 用户选 yes → 继续，并在最终报告"变更概述"段落末尾追加 CI 状态警告（格式见"报告增强"节）

• 用户选 no → 终止 review，随即询问：

  是否在 PR #<PR_NUMBER> 发表评论，提醒作者修复失败的 CI job？(yes/no)

  • 用户选 yes → 发布 CI 失败提醒评论（格式见下方"CI 失败提醒评论"节），然后退出
  • 用户选 no → 直接退出

CI 失败提醒评论

当 CI 失败且用户选择不继续 review 但选择发布提醒时，评论格式：

gh pr comment <PR_NUMBER> --body "<!-- pr-review-bot -->

## CI 检查未通过

以下 job 在本次 review 时未通过，请修复：

| Job | 结论 |
|-----|------|
| <失败的 job 名称> | ❌ <FAILURE 或 CANCELLED> |

本次 code review 暂缓，待 CI 全部通过后将重新执行。"

（仅列出实际失败的 job，跳过已通过的。）

报告增强

当 CI 存在失败但用户选择继续时，在最终报告"变更概述"段落末尾追加：

> ⚠️ **CI 状态警告**：以下 job 在 review 时未通过：`<job 名称>`（<结论>）。本报告结论仅供参考，建议修复 CI 后重新 review。

---

Step 3 — Check Working Tree

git status --porcelain

If the output is non-empty, abort with:

Working tree has uncommitted changes. Please commit or stash them before running pr-review.

Step 4 — Record Current Branch

git branch --show-current

Save this as <original_branch> for Step 10.

Step 5 — Checkout PR Branch

gh pr checkout <PR_NUMBER>

Save the checked-out branch name:

git branch --show-current

Step 6 — Collect Context (Parallel)

Run the following in parallel:

PR metadata:

gh pr view <PR_NUMBER> --json title,body,author,labels,headRefName,baseRefName,state,createdAt,updatedAt

Full diff (no truncation):

git diff origin/<baseRefName>...HEAD

Changed file list:

git diff --name-status origin/<baseRefName>...HEAD

Existing pr-assess comment (if any):

gh pr view <PR_NUMBER> --json comments --jq '.comments[] | select(.body | startswith("<!-- pr-assess-bot -->")) | .body'

If a pr-assess comment exists, use it as supplementary context (risk signals, change overview) when forming your review. Do not re-verify its conclusions — treat it as background information only.

Step 7 — Run Lint on Changed Files

Run oxlint on all changed .ts / .tsx files (skip deleted files):

bunx oxlint <changed_ts_tsx_files...>

Save the lint output as lint baseline. Use it when reviewing style and code quality in Step 8:

• If a pattern produces no lint warning → it is project-approved; do not flag it as a style issue.
• If a pattern produces a lint warning/error → it is a real violation; report it at the appropriate severity (ERROR → HIGH, WARNING → LOW).
• Do not suggest replacing a lint-clean pattern with an alternative based on general convention alone (e.g. do not suggest spread over Object.assign if no-map-spread is active).

Step 8 — Read Changed File Contents

Use the Read tool to read each changed file locally.

Skip:

• *.lock files
• Images, fonts
• dist/, node_modules/, .cache/
• *.map, *.min.js, *.min.css

Priority order (read highest priority first):

1. src/process/
2. src/process/channels/
3. src/common/
4. src/process/worker/
5. src/renderer/

Also read key interface/type definition files imported by the changed files when they provide important context.

Step 9 — Perform Code Review

Write the code review report in Chinese.

Review dimensions:

• 方案合理性 — 整体方案是否正确解决了问题；是否引入不必要的复杂度；是否与项目已有架构和模式一致；是否存在更简单/优雅的实现路径；方案本身是否存在已知缺陷或设计盲点。具体评估要点：方案是否真正解决了 PR 描述的问题（而不是解决了另一个问题）；是否绕过了框架/库提供的现成机制（重复造轮子）；是否与 src/process/、src/renderer/、IPC bridge 等架构边界一致；是否引入了不必要的抽象层或过度工程化；方案是否有已知的边界情况或竞态条件，在设计层面未被考虑
• 正确性 — 逻辑是否正确，边界条件是否处理
• 安全性 — 注入、XSS、密钥泄露、权限越界
• 不可变性 — 是否存在对象/数组直接变异（本项目关键原则）
• 错误处理 — 异常是否被静默吞掉，错误信息是否合理
• 性能 — 不必要的重渲染、大循环、阻塞调用
• 代码质量 — 函数长度、嵌套深度、命名清晰度
• 遗留 console.log — 生产代码中是否有调试日志残留
• 测试 — 对照 testing skill 的标准评估，以下任一情况须指出：
  • 新增功能没有对应测试用例
  • 修改了逻辑但未更新已有相关测试
  • 新增的源文件被 vitest.config.ts 的 coverage.exclude 意外排除（即本应计入覆盖但被错误排除）
  • 已有测试不符合 testing skill Step 2 的质量规则
• 可测试性 — 变更后的代码是否仍可独立测试；依赖是否可 mock； 是否与已有模块保持解耦；能否在不依赖完整运行环境的情况下运行单元测试。 发现耦合时区分来源：
  • 本次改动新引入的耦合 — 按影响程度定级（新功能从设计阶段就应解耦，列为 HIGH；导致测试无法运行则列为 CRITICAL）
  • 已存在的历史耦合 — 不作为本 PR 阻塞点，建议单独开 issue 跟踪

只报告真实存在的问题。 如果某个维度代码没有问题，跳过即可，不要为了显示"有在认真 review"而凑问题。以实际代码为准，有则报告，无则如实说代码干净。方案合理性维度同理——如果方案本身没有问题，如实写"方案合理"即可，不要为了体现"有深度"而刻意挑剔。

For each issue found:

1. Specify file path and line number(s)
2. Quote the problematic code
3. Explain why it is an issue
4. Provide a concrete fix with corrected code

Use the following report template:

---

## Code Review：<PR 标题> (#<PR_NUMBER>)

### 变更概述

[2–3 句话说明这个 PR 改了什么，影响了哪些模块。]

---

### 方案评估

**结论**：✅ 方案合理 / ⚠️ 方案有缺陷 / ❌ 方案根本错误

[2–4 句话说明：方案是否正确解决了目标问题；是否与项目架构一致；有无更优雅的替代方案（如有，简述思路）；方案层面有无设计盲点。]

---

### 问题清单

#### 🔴 CRITICAL — <问题标题>

**文件**：`path/to/file.ts`，第 N 行

**问题代码**：

```ts
// 有问题的代码
```

问题说明：[说明为什么有问题]

修复建议：

// 修复后的代码

---

🟠 HIGH — <问题标题>

（格式同上）

---

🟡 MEDIUM — <问题标题>

（格式同上）

---

🔵 LOW — <问题标题>

（格式同上）

---

汇总

#	严重级别	文件	问题
1	🔴 CRITICAL	file.ts:N	...
2	🟠 HIGH	file.ts:N	...

结论

[以下三选一：]

• ✅ 批准合并 — 无阻塞性问题
• ⚠️ 有条件批准 — 存在小问题，处理后可合并
• ❌ 需要修改 — 存在阻塞性问题，必须先解决

[一句话说明理由]

---

本报告由本地 pr-review skill 生成，包含完整项目上下文，无截断限制。

---

If no issues are found across all dimensions, output:

> ✅ 未发现明显问题，代码质量良好，建议批准合并。

### Step 10 — Ask to Post Comment

Print the complete review report to the terminal, then ask the user:

> Review 完成。是否将此报告发布为 PR #<PR_NUMBER> 的评论？(yes/no)

If the user says **yes**:

1. Check for an existing review comment:
```bash
gh pr view <PR_NUMBER> --json comments --jq '.comments[] | select(.body | startswith("<!-- pr-review-bot -->")) | .databaseId'

2. If a previous comment exists, update it:

gh api repos/{owner}/{repo}/issues/comments/<comment_id> -X PATCH -f body="<!-- pr-review-bot -->

<review_report>"

3. If no previous comment exists, create a new one:

gh pr comment <PR_NUMBER> --body "<!-- pr-review-bot -->

<review_report>"

Step 11 — Cleanup

Switch back to the original branch:

git checkout <original_branch>

Ask the user:

是否删除本地 PR 分支 <pr_branch>？(yes/no)

If yes:

git branch -D <pr_branch>