pr-review

PR 评审

获取近期 PR，对其分类、阅读源代码并提供有上下文的评审。

输入

$ARGUMENTS — PR 数量（默认：10）

示例：

• /pr-review — 最近的 10 个开放 PR
• /pr-review 20 — 20 个 PR

工作流

1. 获取近期 PR

gh pr list --repo toss/es-toolkit --state open --limit {count} --json number,title,author,labels,createdAt

2. 对每个 PR 进行初步分类

对每个 PR 运行 /pr-triage {number} 进行分类。

3. 对每个 PR 进行深入评审

对每个 PR，不要止步于分类 — 阅读实际源代码并提供上下文：

a. 阅读当前代码

阅读 main 分支上被修改的文件，了解当前行为：

• 函数源代码：它的作用及工作方式
• 现有测试：已覆盖的内容
• JSDoc：记录的行为和示例

b. 了解 PR 的改动

阅读差异内容，了解改动：

• 改动前后有什么区别？
• 贡献者为什么认为需要这项改动？
• 这项改动符合代码的实际需求吗？

c. 评估影响

• 破坏性变更：函数签名是否有变化？会影响现有用户吗？
• JS 规范对齐：当前行为是否遵循 JS/lodash 惯例？PR 是否会破坏这一点？
• 范围：所有受影响文件都已更新吗？（例如，是否更新了 4 种语言的文档及相关函数）
• 设计原则：是否符合 es-toolkit 的 85% 使用场景 / 简洁性理念？

d. 针对标签的检查

• compat-fix：运行 /compat-review {number}
• new-function：检查是否完整（实现 + 规范 + 重新导出 + 4 种语言的文档）
• core-change：运行 yarn vitest run src/{category}/{fn}.spec.ts + 评估破坏性影响
• docs：检查 4 种语言的文件是否一致更新
• types：运行 tsc --noEmit

4. 检测重复项

按相同函数名或相同修改文件对 PR 进行分组。

5. 逐个 PR 汇报

对每个 PR，输出：

### PR #{number} — {title}

**Classification**: {labels}
**Changed files**: {summary}

**Current code**: {what the function does now, with code snippet}
**PR change**: {what's changing and why, with before/after}
**Context**: {JS spec, lodash behavior, design principle considerations}

**Checkpoints**:
- {specific things to verify}

**Verdict**: {merge / merge with changes / hold for discussion / reject}

6. 总结

## PR Review — {date}

| # | Title | Label | Verdict |
|---|-------|-------|---------|

- {N} ready to merge
- {N} need changes
- {N} need discussion
- {N} potential duplicates