Menu
Use when finishing substantial code changes, before merging, or at natural checkpoints to request an explicit code review pass.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Helps explore ideas before implementation. Use when the user wants to brainstorm features, compare approaches, shape requirements, or discuss tradeoffs before writing code.
Use when you have two or more independent tasks, failures, or investigations that can be worked on concurrently without shared state or sequential dependencies.
Use when receiving code review feedback, before implementing suggestions, especially when feedback is unclear, broad, or may not fit the codebase as-is.
Use when executing a multi-task implementation plan by dispatching one fresh builder agent per task, reviewing each task before moving on, and keeping controller context narrow.
Use when investigating a bug, test failure, build failure, flaky behavior, or unexpected runtime issue before proposing or implementing fixes.
Use when implementing a feature, bug fix, or behavior change where automated tests should drive the implementation before production code is written.
| name | requesting-code-review |
| description | Use when finishing substantial code changes, before merging, or at natural checkpoints to request an explicit code review pass. |
Use this skill to request a focused review before changes continue or ship.
Review early enough to catch issues before they compound, and review with concrete scope.
Use this skill:
For tiny mechanical edits, a separate review pass is optional.
Prepare a tight review scope:
Good review requests are specific. Avoid asking for a vague review of the entire project when only one change matters.
Prefer one of these:
If using commits, gather the relevant base and head SHAs.
Use the code-reviewer agent for read-only code review.
Include:
Example request contents:
Review this change for bugs, regressions, missing tests, and risky assumptions.
Summary: Added a new retry path for transient API failures.
Expected behavior: Requests retry once on network timeout, but not on validation errors.
Scope: diff between <base> and <head>.
Focus: error handling, duplicate side effects, and test coverage.
For larger efforts:
For smaller efforts:
Do not:
Request review with concrete scope, clear expectations, and enough context for someone to find real issues quickly.