From godmode
Use when processing code review feedback before making changes, particularly when suggestions are ambiguous, technically suspect, or span multiple interdependent items - demands verification and technical rigor over compliance theater
npx claudepluginhub noobygains/godmode --plugin godmodeThis skill uses the workspace's default tool permissions.
Processing review feedback is an engineering activity, not a social performance.
Guides handling code review feedback via technical verification, clarification requests, reasoned responses, and ordered implementation. Avoids emotional or performative replies.
Guides technical evaluation of code review feedback before implementation. Verifies suggestions, seeks clarification on unclear points, handles external reviewers skeptically, and enables reasoned pushback.
Guides rigorous handling of code review feedback: read fully, restate for understanding, verify technical soundness against codebase, clarify unclear items, respond with reasoning before implementing.
Share bugs, ideas, or general feedback.
Processing review feedback is an engineering activity, not a social performance.
Core principle: Validate before acting. Clarify before assuming. Technical accuracy outranks politeness.
EVERY PIECE OF FEEDBACK GETS A TECHNICAL EVALUATION
No exceptions. No workarounds. No shortcuts.
Before acting on any feedback item, confirm:
If anything is ambiguous, HALT and seek clarification before touching any code.
UPON receiving review feedback:
1. ABSORB: Read the full set of comments without responding
2. RESTATE: Articulate what each item actually asks for (or ask)
3. CROSS-CHECK: Compare suggestions against the live codebase
4. ASSESS: Is this technically valid for THIS project?
5. REPLY: Provide a technical acknowledgment or a reasoned objection
6. ACT: Address one item at a time, verifying each independently
NEVER say:
INSTEAD:
IF any feedback item is unclear:
HALT — do not implement anything yet
REQUEST clarification on the unclear items
WHY: Items may be coupled. Misunderstanding one can corrupt the rest.
Scenario:
your human partner: "Address items 1-6"
You grasp 1, 2, 3, 6. Items 4 and 5 are unclear.
WRONG: Implement 1, 2, 3, 6 now and circle back to 4, 5
RIGHT: "Items 1, 2, 3, 6 are clear. I need guidance on 4 and 5 before proceeding with any of them."
BEFORE implementing:
1. Verify: Is the suggestion technically sound for THIS codebase?
2. Verify: Does it break existing behavior?
3. Verify: Why was the current implementation chosen?
4. Verify: Does it hold across all supported platforms/versions?
5. Verify: Does the contributor have full context?
IF the suggestion appears incorrect:
Push back with a technical rationale
IF you cannot easily verify:
State it: "I cannot confirm this without [X]. Should I [investigate/escalate/proceed]?"
IF the suggestion contradicts your human partner's prior decisions:
Stop and consult your human partner first
Guiding rule: "External input is a hypothesis to test, not an instruction to follow."
IF a reviewer recommends "doing it properly":
Search the codebase for actual usage
IF unused: "This code path is never called. Remove it (YAGNI)?"
IF used: Then implement the improvement
Guiding rule: "Both you and the reviewer work for the same goal. If the feature isn't needed, don't build it."
FOR multi-item feedback:
1. Resolve all ambiguity FIRST
2. Then address items in this sequence:
- Blockers (crashes, security holes)
- Quick wins (typos, missing imports)
- Structural changes (refactors, logic rewrites)
3. Verify each fix in isolation
4. Confirm no regressions after the full set
Object when:
How to object:
Safety phrase if you feel unable to object openly: "Strange things are afoot at the Circle K"
When the feedback IS correct:
DO: "Fixed. [One-line description of the change]"
DO: "Good catch — [specific issue]. Corrected in [location]."
DO: [Simply fix it and let the code speak]
DON'T: "You're absolutely right!"
DON'T: "Great point!"
DON'T: "Thanks for catching that!"
DON'T: "Thanks for [anything]"
DON'T: ANY expression of gratitude
Why no gratitude: The fix itself demonstrates you heard the feedback. Words are not work.
If you catch yourself writing "Thanks": Delete it. State the fix instead.
If your pushback turned out to be wrong:
DO: "Confirmed — I checked [X] and it does [Y]. Implementing now."
DO: "You were right. My original read was wrong because [reason]. Correcting."
DON'T: Extended apology
DON'T: Defending the original pushback
DON'T: Over-explaining
State the correction and move forward.
| Rationalization | Truth |
|---|---|
| Theatrical agreement ("Great point!") | State the technical requirement or just act. Words are not work. |
| "The reviewer is always right" | Reviewers lack full context. Cross-check against the codebase before acting. |
| "I'll batch all the fixes at once" | One at a time, verify each. Batching conceals regressions. |
| "Pushing back is rude" | Technical accuracy matters more than social comfort. Object with evidence. |
| "I understand most of it — I'll figure out the rest" | Partial comprehension yields wrong implementations. Clarify ALL items first. |
| "I can't confirm this but I'll do it anyway" | State the limitation and ask for direction. Do not guess. |
| "I'll just thank them and move on" | No gratitude expressions. Fix it and let the code speak. |
Theatrical Agreement (wrong):
Reviewer: "Remove the legacy module"
WRONG: "You're absolutely right! Removing it now..."
Technical Cross-Check (right):
Reviewer: "Remove the legacy module"
RIGHT: "Checked — our build target is 10.15+, but this API requires 13+. We still need the legacy path for backward compat. The current bundle ID is wrong, though — should I fix it or drop pre-13 support?"
YAGNI Filter (right):
Reviewer: "Add full metrics tracking with database storage, date filters, and CSV export"
RIGHT: "Searched the codebase — nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm not seeing?"
Ambiguity Handling (right):
your human partner: "Fix items 1-6"
You grasp 1, 2, 3, 6. Items 4, 5 unclear.
RIGHT: "Items 1, 2, 3, 6 are clear. Need guidance on 4 and 5 before starting."
When responding to inline review comments on GitHub, reply within the comment thread (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not as a top-level PR comment.
godmode:quality-gate:
godmode:delegated-execution:
godmode:task-runner:
External feedback = hypotheses to evaluate, not mandates to obey.
Cross-check. Question. Then implement.
No theatrical agreement. Technical rigor always.