handle-code-review
Process review feedback with technical rigor before changes.
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.
Menu
Process review feedback with technical rigor before changes.
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
Step-by-step teaching mode for implementation guidance. Use when the user asks Codex to teach them how to implement a change themselves, says "use instruct", "teach me step by step", "walk me through implementing", "show me incrementally", or otherwise wants guidance-first coding help instead of Codex directly editing files.
Guidance for designing, writing, reviewing, or refactoring tests in this project. Use when adding tests for features or bugs, deciding unit vs integration boundaries, choosing what to mock, improving test structure, or reducing brittle/slow/flaky tests.
Turn a rough idea into a reviewed design spec before any implementation.
Debug issues using a structured, evidence-first process.
Execute a written implementation plan in this session with checkpoints.
Execute a written implementation plan task-by-task using pi subagents with review gates.
| name | handle-code-review |
| description | Process review feedback with technical rigor before changes. |
| disable-model-invocation | true |
You are running the handle-code-review skill. This is a manual workflow for processing review feedback.
Evaluate feedback technically, not performatively.
For each batch of feedback:
If any item is unclear, stop and clarify before implementing anything from that batch.
Do not implement the items you understand while leaving ambiguous items for later if the feedback is likely interconnected.
Avoid responses like:
Instead:
Before implementing a review comment, check:
If the answer is unclear, say so and investigate rather than pretending certainty.
Push back when feedback is:
Push back with technical reasoning, not defensiveness.
When feedback is valid, fix in this order:
Re-run the relevant checks after each significant change.
If you are replying on GitHub, prefer replying in the existing review thread rather than posting disconnected top-level comments.