菜单
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)