メニュー
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