pr-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# PR Review Skill

## Goal

Review code changes like a strong senior engineer:
- Find bugs and regressions
- Validate spec/ticket alignment
- Identify edge cases and failure paths
- Catch security/performance risks
- Ensure maintainable implementation

Focus ONLY on:
- Changed code
- Directly impacted areas
- Real production risk

Do NOT:
- Rewrite unrelated code
- Suggest large refactors unless necessary
- Nitpick formatting or subjective style
- Criticize architecture unrelated to the change

---

# Review Strategy

## Step 1 — Understand Context

Before reviewing:
- What problem is being solved?
- What behavior changed?
- What files changed?
- Is there a spec, ticket, or expected behavior?
- What parts of the system are impacted?

If a spec/design exists:
- Read it first
- Validate implementation against it

---

## Step 2 — Review Like Production Will Break

Assume this code may fail in production.

Ask:
- What breaks first?
- What happens on invalid input?
- What happens on timeout?
- What happens on partial failure?
- What happens with null/empty data?
- Can this corrupt data?
- Can this create inconsistent state?
- Can this break existing flows?

This is more important than style.

---

# Core Review Areas

## 1. Correctness
- [ ] Logic works as intended
- [ ] Matches spec/ticket
- [ ] Handles edge cases
- [ ] Handles async/concurrency safely
- [ ] No obvious broken flows

Focus on:
- null/undefined
- empty collections
- retries
- duplicate actions
- stale state
- race conditions
- incorrect assumptions

---

## 2. Regression Risk
- [ ] Existing flows still work
- [ ] Existing callers still work
- [ ] Contracts remain compatible
- [ ] Changes don't silently alter behavior

Pay extra attention to:
- shared utilities
- auth flows
- DB schema changes
- state management
- caching
- API response shapes

---

## 3. Error Handling
- [ ] Failures handled explicitly
- [ ] No silent failures
- [ ] User sees meaningful errors
- [ ] Logs contain useful debugging info
- [ ] Timeouts/retries handled where needed
- [ ] Async/streaming failures handled cleanly

Check:
- backend endpoints
- frontend fetches
- background jobs
- queues/events
- external API calls

---

## 4. Security
Review ONLY if relevant to the change.

Check for:
- missing auth/permission checks
- injection risks
- unsafe input handling

From zoharp/claude-skills, MIT.

More from zoharp/claude-skills