메뉴
Enforce pull request best practices: size limits, description templates, testing requirements, and review workflows. Activate whenever the user creates a PR, asks about PR best practices, sets up PR templates, discusses code review turnaround, or mentions PR size, review requirements, or branch protection rules.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Patterns for running independent tasks in parallel using multiple tool calls and Agent invocations. Use when the user has multiple independent operations, asks about fan-out/fan-in, or wants to speed up multi-step workflows.
Patterns for when and how to use Claude Code subagents via the Agent tool. Use when the user needs to delegate research, run parallel investigations, protect the main context window, or asks about subagent types like Explore or Plan.
Patterns for using TaskCreate, TaskUpdate, TaskList, and TaskGet to coordinate multi-step work. Use when the user has a complex project with multiple steps, needs progress tracking, dependency management, or multi-agent task assignment.
Patterns for inter-agent communication including message passing, shared state, event-driven architectures, pub/sub, inbox/outbox, and structured vs freeform messages. Use when the user is building systems where multiple agents need to communicate, share information, coordinate work, or pass data between processing stages.
Strategies for managing AI agent context windows including optimization, summarization, retrieval-augmented generation, progressive disclosure, and pruning. Use when the user is hitting context limits, building long-running agents, implementing RAG, optimizing token usage, or designing systems that need to manage large amounts of information within limited context windows.
Patterns for multi-agent systems including orchestrator, pipeline, consensus, delegation, supervisor, and swarm patterns. Use when the user is building multi-agent workflows, coordinating multiple AI agents, implementing agent delegation or supervision, or designing systems where agents collaborate on complex tasks.
| name | pr-standards |
| description | Enforce pull request best practices: size limits, description templates, testing requirements, and review workflows. Activate whenever the user creates a PR, asks about PR best practices, sets up PR templates, discusses code review turnaround, or mentions PR size, review requirements, or branch protection rules. |
Define and enforce PR best practices to keep reviews fast, thorough, and productive. Small PRs with clear descriptions get reviewed faster and have fewer bugs.
Keep PRs small and focused. Target under 400 lines of meaningful changes.
Size Guidelines:
XS (1-50 lines) - Typo fix, config change, one-liner bug fix
S (51-200 lines) - Small feature, focused bug fix, single-file refactor
M (201-400 lines) - Standard feature, multi-file change
L (401-800 lines) - Large feature (split if possible)
XL (800+ lines) - Too large. Must be split into smaller PRs.
Lines counted: Additions + deletions in application code.
Excluded from count: Lock files, generated code, snapshots, migrations.
Strategies for splitting large PRs:
1. Layer-by-layer: Database schema -> Backend API -> Frontend UI
2. Feature flags: Merge incomplete features behind flags
3. Refactor-then-feature: Separate refactoring PR from feature PR
4. Vertical slices: One complete user story per PR
<!-- .github/pull_request_template.md -->
## Summary
<!-- What does this PR do and why? 1-3 bullet points. -->
## Changes
<!-- List the key changes made. Group by area if helpful. -->
## Testing
<!-- How was this tested? Include commands to reproduce. -->
- [ ] Unit tests added/updated
- [ ] Manual testing performed
- [ ] Edge cases covered
## Screenshots
<!-- If UI changes, include before/after screenshots. -->
## Related
<!-- Link to issue, Jira ticket, or previous PR. -->
Closes #
## Checklist
- [ ] Self-review completed
- [ ] No console.log or debug statements
- [ ] No hardcoded secrets
- [ ] Tests pass locally
- [ ] Documentation updated (if applicable)
Configure branch protection to enforce quality gates.
# Repository Settings -> Branches -> Branch protection rules for "main"
Required checks:
- CI / lint (required)
- CI / test (required)
- CI / build (required)
Review requirements:
- Required approving reviews: 1 (2 for large teams)
- Dismiss stale reviews when new commits are pushed: true
- Require review from CODEOWNERS: true
Other settings:
- Require branches to be up to date before merging: true
- Require linear history: true (encourages rebase over merge commits)
- Restrict who can push: maintainers only
- Do not allow bypassing the above settings: true
Use labels to communicate PR status and type at a glance.
## Type Labels
- `feat` - New feature
- `fix` - Bug fix
- `refactor` - Code refactoring (no behavior change)
- `docs` - Documentation only
- `test` - Test additions or fixes
- `chore` - Build, CI, dependencies
## Size Labels (auto-applied via GitHub Action)
- `size/XS` - 1-50 lines
- `size/S` - 51-200 lines
- `size/M` - 201-400 lines
- `size/L` - 401-800 lines (triggers warning comment)
- `size/XL` - 800+ lines (blocks merge)
## Status Labels
- `needs-review` - Ready for review
- `changes-requested` - Author must address feedback
- `approved` - Ready to merge
- `blocked` - Waiting on external dependency
- `do-not-merge` - Intentionally held
Auto-label PR size with a GitHub Action:
# .github/workflows/pr-size.yml
name: PR Size Label
on:
pull_request:
types: [opened, synchronize]
jobs:
size-label:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: codelytv/pr-size-labeler@v1
with:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
xs_max_size: 50
s_max_size: 200
m_max_size: 400
l_max_size: 800
fail_if_xl: true
message_if_xl: >
This PR exceeds 800 lines. Please split it into smaller,
focused PRs for easier review.
Set expectations for review responsiveness.
## Review SLA (Service Level Agreement)
| Priority | First Review | Follow-up |
|----------|-------------|-----------|
| Critical (P0) | 2 hours | 1 hour |
| High (P1) | 4 hours | 2 hours |
| Normal (P2) | 1 business day | 4 hours |
| Low (P3) | 2 business days | 1 business day |
## Guidelines for Authors
- Request review only when PR is truly ready (CI passes, self-reviewed)
- Tag specific reviewers; avoid "anyone" requests
- Respond to review comments within 4 hours
- Mark conversations as resolved after addressing them
- Re-request review after addressing all comments
## Guidelines for Reviewers
- Acknowledge the PR within the SLA even if full review takes longer
- Distinguish blocking (CRITICAL/HIGH) from non-blocking (MEDIUM/LOW) feedback
- Approve with comments for non-blocking suggestions
- Avoid starting a review you cannot finish within 2 hours
## Author Self-Review Checklist (do before requesting review)
1. Read every line of your own diff in the GitHub UI
2. Verify all tests pass in CI
3. Remove debug statements and TODOs
4. Check for accidental file inclusions (.env, IDE configs)
5. Confirm the PR description is complete
6. Verify the PR is against the correct base branch
7. Check that commit messages follow conventions
8. If UI change: attach screenshots or screen recordings
| Standard | Target |
|---|---|
| PR size | Under 400 lines of application code |
| Description | Summary + changes + testing + related issue |
| Required reviews | 1 minimum (2 for critical paths) |
| CI checks | Lint + test + build must pass |
| Review turnaround | Under 1 business day for normal priority |
| Author response | Under 4 hours for review comments |
| Self-review | Always before requesting review |
| Labels | Type + size applied to every PR |