Back to list
doanchienthangdev

requesting-code-reviews

by doanchienthangdev

Omega Vibecode Kit

2🍴 1📅 Jan 21, 2026

SKILL.md


name: requesting-code-reviews description: AI agent requests effective code reviews through proper preparation, clear descriptions, and appropriate reviewer selection. Use when creating PRs, requesting feedback, or submitting for review.

Requesting Code Reviews

Quick Start

  1. Self-Review - Review your own diff first, catch obvious issues
  2. Prepare Code - Tests pass, no debug code, documentation updated
  3. Write Description - Clear summary, changes list, testing info, screenshots
  4. Select Reviewers - Match expertise to changes, respect workload
  5. Time Appropriately - Early week, morning hours, avoid Fridays

Features

FeatureDescriptionGuide
Self-ReviewCatch issues before requestingCheck debug code, TODOs, test coverage
PR DescriptionGuide reviewers effectivelySummary, changes, testing, attention areas
Reviewer SelectionMatch expertise to needsCode owner, domain expert, security reviewer
PR SizingOptimal size for review quality<400 lines ideal, split larger PRs
TimingWhen to request reviewsMorning, early week, check availability
Reviewer GuidanceHelp reviewers focusKey areas, skip suggestions, questions

Common Patterns

# PR Description Template
## Summary
[What changed and why - 2-3 sentences]
Resolves #123

## Changes
- [Bullet point each significant change]

## Testing
### Automated Tests
- [x] Unit tests added/updated
- [x] Integration tests pass

### Manual Testing
1. [Step to verify]
2. [Expected result]

## Screenshots
[For UI changes]

## Areas Needing Review
- Security: [specific file/concern]
- Performance: [specific concern]

## Checklist
- [x] Self-review completed
- [x] Tests pass locally
- [x] Documentation updated
# PR Size Guide
| Size | Lines | Review Time | Recommendation |
|------|-------|-------------|----------------|
| Small | <100 | 15-30 min | Ideal for quality review |
| Medium | <400 | 30-60 min | Acceptable |
| Large | <800 | 1-2 hours | Consider splitting |
| Too Large | 800+ | 2+ hours | Split required |

# Reviewer Selection
1. Code owner - maintains affected area
2. Domain expert - knows the technology
3. Security - for auth/crypto changes
4. Architecture - for design changes

Max reviewers: 4 (too many = diffused responsibility)
# Self-Review Checklist
[ ] No console.log/debug statements
[ ] No commented-out code
[ ] No hardcoded values (should be config)
[ ] Error handling appropriate
[ ] All tests pass
[ ] New code has tests
[ ] Complex logic has comments
[ ] Commit messages clear
[ ] Rebased on latest main

Best Practices

DoAvoid
Self-review firstSubmitting PRs without testing
Keep PRs small (<400 lines)Creating massive PRs
Write clear descriptionsLeaving descriptions empty
Highlight key review areasExpecting reviewers to find everything
Choose reviewers wiselyOverloading single reviewers
Be responsive to feedbackIgnoring reviewer availability
Include screenshots for UIRushing reviewers
Test thoroughly firstWasting reviewer time on broken code
  • receiving-code-reviews - Handle feedback professionally
  • finishing-development-branches - Complete PR preparation
  • verifying-before-completion - Pre-submission verification
  • writing-plans - Plan review-ready deliverables

Score

Total Score

60/100

Based on repository quality metrics

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

+10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

0/15
最近の活動

3ヶ月以内に更新がある

0/10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

0/5

Reviews

💬

Reviews coming soon