القائمة
Use when receiving code review feedback — requires technical verification of each suggestion before implementing, not blind agreement
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when a structured PRD document is needed for the ralph loop — generates prd.json and progress.txt
Use when task scope exceeds one context window and decomposes into independent pass/fail stories with clean iteration boundaries
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work — merge, PR, or cleanup
Use when starting feature work that needs isolation from the current workspace or before executing plans that could leave the branch in a broken state
Use when a hard problem was just solved and the solution should be captured as a learning for future reference
Use when 3+ distinct occurrences suggest a skill should be updated with a new trigger, anti-pattern, or verification step
| name | receiving-code-review |
| description | Use when receiving code review feedback — requires technical verification of each suggestion before implementing, not blind agreement |
| tags | ["review","discipline","quality"] |
| triggers | ["review feedback","PR comments","code review response","reviewer says","feedback received"] |
| chains_to | ["verification-before-completion"] |
| priority | core |
| gate | false |
When receiving review feedback: verify each suggestion technically before implementing. Don't blindly agree. Don't blindly reject. Understand, verify, then act.
requesting-code-review)Read every comment/finding before responding to any. Understand the full picture — some comments may relate to each other.
For each piece of feedback:
| Category | Action |
|---|---|
| Clearly correct (bug, security issue, missing test) | Fix it. No discussion needed. |
| Technically sound suggestion | Verify the suggestion works, then implement. |
| Debatable (style, approach, taste) | Understand the reasoning. If it improves the code, do it. If not, explain why. |
| Incorrect (misunderstood the code, wrong assumption) | Explain politely with evidence. Show the code that proves your point. |
For each suggestion you plan to implement:
Never implement a suggestion you don't understand. Ask for clarification instead.
For items you implement:
Done. [Brief description of the change.]
For items you disagree with:
[Technical explanation with evidence — file:line, test output, docs reference.]
For items that need clarification:
I want to make sure I understand: are you suggesting [interpretation]? Because [context].
After all changes:
verification-before-completion| Anti-Pattern | Why It's Wrong |
|---|---|
| "Good point, fixed!" without verifying | The "fix" might introduce new bugs |
| Implementing every suggestion blindly | Some suggestions are wrong. Verify first. |
| Rejecting all feedback defensively | Review is about the code, not you |
| Bulk-fixing without understanding | You'll miss the learning opportunity |
| "I'll fix it later" | You won't. Fix it now. |
| Performative agreement | Saying "great catch" when you disagree helps nobody |
Technical rigor over social compliance. Verify the suggestion. If it's right, implement it. If it's wrong, explain why with evidence. Never agree just to be agreeable.
REQUIRED: syntaxninja-dojo:verification-before-completion (after all fixes applied)