code-reviewer

分类: 测试与安全 | 上传者: hivemoot | 下载: 0 | 版本: v1.0（最新）

PR 的结构化代码审查方法。优先考虑正确性，标记常见的反模式，执行范围规则，检查测试覆盖率，并提供可操作的反馈。与语言无关。 --- ## 技能：代码审阅者您正在运行代码审阅者技能。对您审核的每个 PR 应用结构化、基于证据的审核方法。 ### 审核优先顺序按此顺序审核。如果较高的优先级是干净的，则停止阻塞较低的优先级。 1. **正确性** — 它是否解决了所述问题？它会破坏现有的行为吗？ 2. **安全性** — 注入、身份验证问题、秘密暴露 3. **可靠性** — 错误处理、故障模式、边缘情况 4. **性能** — N+1 模式、不必要的分配、算法复杂性 5. **可维护性** — 可读性、命名、模式一致性 6. **样式** — 格式、约定（永远不会单独阻止样式） ### 标记的常见模式 #### 无声错误吞噬 - 空 `catch`/` except`/`rescue` 块或仅记录并继续的块 - 忽略易错操作的返回值 - 抑制错误：`|| true`, `2>/dev/null`, bare ` except: pass`, `_ = err` #### N+1 和循环效率低下 - API 调用、数据库查询或循环内的文件读取 - 缺少急切加载/批处理操作（例如，`prefetch_lated`、`include`、`DataLoader`、`JOIN`、批处理 API 调用） - 重复的昂贵计算，可以从循环中提升 #### 竞争条件 - 共享从没有防护的异步或并发上下文访问可变状态 - 无原子性的先检查后执行模式 (TOCTOU) - 并发数据访问时缺少锁、互斥体或原子操作 #### 边界问题 - 缺少信任边界处的输入验证（用户输入、API 响应） - 没有运行时检查的不安全类型转换或断言 - 范围、切片或索引操作中的差一错误 #### 向后兼容性 - 重命名或删除公共 API，而无需迁移路径 - 更改了破坏现有功能的函数签名

更新日志: Source: GitHub https://github.com/hivemoot/hivemoot-agent

目录结构

当前层级: tree/main/skills/code-reviewer/

📄 SKILL.md 4.1 KB

SKILL.md

---
name: code-reviewer
description: >
  Structured code review methodology for PRs. Prioritizes correctness,
  flags common anti-patterns, enforces scope discipline, checks test
  coverage, and provides actionable feedback. Language-agnostic.
---

## Skill: Code Reviewer

You are running with the code-reviewer skill active. Apply a structured,
evidence-based review methodology to every PR you review.

### Review Priorities

Review in this order. Stop blocking on lower priorities if higher ones are clean.

1. **Correctness** — Does it solve the stated problem? Does it break existing behavior?
2. **Security** — Injection, auth issues, secret exposure
3. **Reliability** — Error handling, failure modes, edge cases
4. **Performance** — N+1 patterns, unnecessary allocations, algorithmic complexity
5. **Maintainability** — Readability, naming, patterns consistency
6. **Style** — Formatting, conventions (never block on style alone)

### Common Patterns to Flag

#### Silent error swallowing

- Empty `catch`/`except`/`rescue` blocks or ones that only log and continue
- Ignored return values from fallible operations
- Suppressed errors: `|| true`, `2>/dev/null`, bare `except: pass`, `_ = err`

#### N+1 and loop inefficiency

- API calls, database queries, or file reads inside loops
- Missing eager loading / batch operations (e.g., `prefetch_related`, `include`,
  `DataLoader`, `JOIN`, batch API calls)
- Repeated expensive computations that could be hoisted out of the loop

#### Race conditions

- Shared mutable state accessed from async or concurrent contexts without guards
- Check-then-act patterns without atomicity (TOCTOU)
- Missing locks, mutexes, or atomic operations on concurrent data access

#### Boundary issues

- Missing input validation at trust boundaries (user input, API responses)
- Unsafe type casts or assertions without runtime checks
- Off-by-one errors in range, slice, or index operations

#### Backwards compatibility

- Renamed or removed public APIs without migration path
- Changed function signatures that break existing callers
- Modified config/data formats without backwards-compatible parsing

#### Scope creep

- PR does more than the linked issue asked for
- Unrelated refactoring bundled with the feature
- "While I'm here" changes that should be separate PRs

### Feedback Guidelines

**Be actionable** — Propose a fix, not just an observation. "This could race"
is vague. "Add a mutex guard around lines 42-48 because X and Y can interleave" is useful.

**Distinguish blocking from non-blocking** — Prefix non-blocking comments with
"Nit:" or "Optional:" so the author knows what must change vs. what's a suggestion.

**Approve when only minor issues remain** — If your feedback is all nits and
suggestions, approve the PR. Don't force another review cycle for cosmetic changes.

**Don't block for style** — If the code follows the project's existing conventions,
don't request changes to match your personal preference.

**Give credit** — If the implementation is clever, clean, or solves a hard problem
well, say so. Good feedback isn't only about problems.

### Test Coverage Check

When reviewing, verify:
- New code paths have corresponding tests
- Edge cases are covered (empty input, boundary values, error conditions)
- Error paths are tested, not just happy paths
- Tests verify behavior, not implementation details
- Mocks don't hide the bug they're supposed to test

### Review Idempotency

Before submitting your review, check if you already have a terminal review
(APPROVED or CHANGES_REQUESTED) at the current HEAD SHA. If you do and have
no new blocking finding, skip the duplicate review.

### When NOT to Apply

- Your own PR (self-review is a different workflow)
- Draft PRs not marked ready for review (unless author explicitly requested feedback)
- PRs from bots that only bump versions (focus on dependency risk instead)

### Quality Checklist

Before submitting your review:
- [ ] Read the linked issue to understand intent
- [ ] Every changed file reviewed
- [ ] Blocking vs non-blocking feedback clearly distinguished
- [ ] Each comment includes a concrete suggestion
- [ ] Formal review status set (approve/request-changes/comment)

登录后下载/点赞/收藏 ❤ 5 | ★ 0

code-reviewer

目录结构

SKILL.md

举报内容

提示