Menu
Use when receiving code review feedback, before implementing suggestions. Requires technical rigor and verification -- not performative agreement or blind implementation.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | receiving-code-review |
| description | Use when receiving code review feedback, before implementing suggestions. Requires technical rigor and verification -- not performative agreement or blind implementation. |
Code review requires technical evaluation, not emotional performance.
Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.
1. READ — Read complete feedback without reacting
2. UNDERSTAND — Restate the issue in plain language
3. VERIFY — Check against the actual codebase
4. EVALUATE — Technically sound for THIS codebase?
5. RESPOND — Fix it, or push back with technical reasoning
6. IMPLEMENT — One item at a time, test each fix
If an issue cannot be explained clearly, understanding is incomplete — return to step 2. Why: implementing on shaky understanding is how reviewer-suggested fixes introduce new bugs.
IF any item is unclear:
STOP — do not implement anything yet
ASK for clarification on the unclear items
WAIT until clear before implementing anything
Items may be related. Partial understanding leads to wrong implementation.
Example: Feedback says "Fix items 1-6". Items 1, 2, 3, 6 are clear; 4 and 5 are not.
Before implementing any reviewer suggestion, verify it is needed:
grep -r "function_name\|ClassName\|method_name" --include="*.py" .
Push back when:
How: technical reasoning, reference working tests/code, ask specific questions.
Test each fix individually. Verify no regressions after each one.
DO: "Fixed. [Brief description of what changed]"
DO: "Good catch -- [specific issue]. Fixed in [location]."
DO: [Just fix it and show the change in code]
DON'T: "You're absolutely right!" / "Great point!" / "Thanks for catching that!"
DON'T: Any performative agreement or gratitude expression
Actions speak. The fix itself shows the feedback was heard.
After pushing back and turning out to be wrong:
DO: "Checked [X] and it does [Y]. Implementing now."
DON'T: Long apology, defending the original pushback, over-explaining.
State the correction factually. Move on.
| Anti-Pattern | Fix |
|---|---|
| Performative agreement | State the requirement or just act |
| Blind implementation | Verify against codebase first |
| Batch without testing | One fix at a time, test each |
| Assuming reviewer is right | Check if it breaks things |
| Avoiding pushback | Technical correctness > comfort |
| Partial implementation | Clarify ALL items first |
Review feedback = suggestions to evaluate, not orders to follow. Verify. Question. Then implement. No performative agreement.
Use before any creative work — features, components, changes, or modifications. Guides structured design through collaborative dialogue before implementation. Triggers: "brainstorm", "design", "think through", "explore approaches", ambiguous requests, or requests with multiple valid interpretations.
Use after a problem has been solved and the solution verified working — captures the lesson as categorized documentation in docs/solutions/ with YAML frontmatter so future sessions can find it. Triggers: "compound", "capture learning", "document solution", "that worked", "it's fixed", "working now", "problem solved", "that did it", "doc-fix".
Use for extended multi-agent review with 14+ agents including conditional and language-specific reviewers. Appropriate for large changes, architectural shifts, migrations, or when standard review is not thorough enough. Triggers: "deep review", "thorough review", "full review", "extended review", "review everything", "maximum coverage".
Use to review brainstorm or plan documents before proceeding to the next workflow step. Applies structured self-review for completeness, clarity, consistency, feasibility, and YAGNI.
Use when implementation is complete and all tests pass — guides branch completion by presenting structured options for merge, PR, or cleanup.
Use when performing multi-agent code review after implementing features, before merging, or when reviewing PRs. Runs 5 core review agents in parallel plus a learnings researcher. Produces prioritized findings (P1/P2/P3) with todo files for tracking and resolution. Triggers: "review", "code review", "check before merge", "review PR", "run reviewers", "catch issues".