AgentSkillsCN

Requesting Code Review

请求代码评审

SKILL.md

Requesting Code Review

Description

Workflow for initiating code reviews with clear scope, context, and expectations. Ensures reviewers have everything needed for effective feedback.

When to Use

  • •After completing a task (before proceeding to next)
  • •After implementing a feature
  • •Before merging to main branch
  • •When unsure about implementation approach
  • •After fixing critical bugs

Review Request Components

1. Scope Definition

Clearly state what should be reviewed:

markdown
## Review Scope

**Files changed**:
- src/services/user-service.ts (modified)
- src/services/user-service.test.ts (added)
- src/types/user.ts (modified)

**Lines changed**: ~150 additions, ~20 deletions

**Not in scope** (don't review):
- package.json changes (unrelated dependency update)
- Generated files in dist/

2. Context

Explain why these changes were made:

markdown
## Context

**Task**: Implement user email verification

**Requirements**:
- Users must verify email before accessing features
- Verification link expires after 24 hours
- Users can request new verification email

**Design decisions**:
- Used JWT for verification token (stateless)
- Stored verification status in existing User table

3. Areas of Concern

Highlight where you want focused attention:

markdown
## Areas of Concern

1. **Security**: Is the token generation secure enough?
2. **Error handling**: Are all edge cases covered?
3. **Performance**: Will the verification lookup be efficient?

4. Test Coverage

Show what's tested:

markdown
## Test Coverage

- Unit tests: 8 new tests in user-service.test.ts
- Integration: Manual testing of full flow
- Edge cases: Expired token, invalid token, already verified

**Not tested** (known gaps):
- Load testing with many concurrent verifications

Review Request Template

markdown
## Code Review Request

### Summary
[1-2 sentence description of changes]

### Files Changed
- `path/to/file1.ts` - [Brief description]
- `path/to/file2.ts` - [Brief description]

### Context
[Why these changes were needed]

### Implementation Notes
[Key decisions made and why]

### Areas for Focus
1. [Specific concern 1]
2. [Specific concern 2]

### Testing
- [x] Unit tests added/updated
- [x] Integration tests pass
- [ ] E2E tests (not applicable)

### Checklist
- [x] Code follows project conventions
- [x] No security vulnerabilities introduced
- [x] Documentation updated if needed

What to Include

Always Include

  • •List of changed files
  • •Summary of what changed
  • •Why the change was needed
  • •Test status

Include When Relevant

  • •Design alternatives considered
  • •Performance implications
  • •Security considerations
  • •Breaking changes

Never Include

  • •Unrelated changes
  • •Formatting-only commits
  • •Debug code
  • •TODO comments (resolve first)

Review Types

Quick Review

For small, low-risk changes:

markdown
## Quick Review: Fix typo in error message

**File**: src/errors.ts
**Change**: Fixed "recieved" → "received" in error message
**Risk**: None

Standard Review

For typical feature work:

markdown
## Review: Add user preferences

**Files**: 3 files, ~200 lines
**Context**: Users can now save display preferences
**Focus**: Data validation, storage approach

Critical Review

For high-risk changes:

markdown
## CRITICAL REVIEW: Authentication refactor

**Files**: 12 files, ~800 lines
**Risk**: HIGH - Authentication system changes
**Required reviewers**: Security team
**Focus**: Token handling, session management, encryption

Best Practices

Keep Reviews Focused

markdown
BAD: "Review my last week of work"
GOOD: "Review the user verification feature (3 files)"

Provide Runnable Context

markdown
## To test locally
1. git checkout feature/email-verification
2. npm install
3. npm test -- --grep "email verification"

Be Specific About Concerns

markdown
BAD: "Let me know if anything looks wrong"
GOOD: "I'm unsure about the error handling in lines 45-60"

Include Relevant Links

markdown
Related:
- Ticket: PROJ-123
- Design doc: [link]
- Previous discussion: [link]

After Submitting

What to Expect

markdown
Reviewer will return:
- Critical issues (must fix)
- Important issues (should fix)
- Minor issues (optional)
- Approval/rejection status

How to Handle Feedback

See receiving-code-review skill for detailed guidance.