메뉴
When the user says they are ready for review or wants to create a PR. When the user asks to check if code is ready for review. When the task or feature is complete and needs quality validation.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
When the user wants to add a new feature or capability. When the user says "I want to build" or "I'm thinking about". When requirements are unclear and need to be refined.
When the user approves a plan and wants to execute it. When the user says "execute the plan" or "let's go" or "start implementation". When a PLAN.md exists and is ready to be executed task-by-task.
When the user is implementing a new feature or fixing a bug. When the user wants to write tests first before writing code. When the user is refactoring and needs to verify behaviour is preserved.
When the user wants to create an implementation plan. When the user says "let's implement this" or "create a plan". When a design has been approved and is ready to be broken into tasks.
Systematic code review workflow — evaluate changes for correctness, style, security, and test coverage before merging. When the user asks to review code or a pull request. When the user says "check code quality" or "look over this diff". When the user requests feedback on changes before merging.
Restart containers, prune images, tail logs.
| name | requesting-code-review |
| description | When the user says they are ready for review or wants to create a PR. When the user asks to check if code is ready for review. When the task or feature is complete and needs quality validation. |
| tools | ["read","exec"] |
Without a pre-review checklist, it is easy to forget debug statements, skipped tests, or missing context — causing avoidable review cycles and wasted reviewer time. This skill ensures code is genuinely ready before asking for human review.
Run a diff to read every line changed before anyone else does.
git diff main...HEAD
Verify the test suite is clean — reviewers should not discover broken tests.
Catching style issues before review keeps feedback focused on logic, not formatting.
## Code Review Self-Assessment
### Changes Summary
Brief description of what changed and why.
### Checklist
- [✓] All tests pass
- [✓] No debug code
- [✓] Documentation updated
### Risks/Notes
Any concerns or open questions.
### Files Changed
- src/auth.py (+45, -12)
Ready for review: **YES** ✓
❌ Requesting review without running tests ❌ Not reviewing your own code first ❌ Missing context in PR description