// How to handle code review feedback with technical rigor. Use when receiving review comments from code-reviewer agent, PR reviews, or external feedback. Triggers on: 'review feedback', 'address review', 'fix review comments', 'code review response'.
MUST be used for ANY git workflow that involves committing code. This includes explicit commit requests AND implicit ones like 'ship it', 'wrap it up', or finishing implementation work. Handles staging, message generation, validation, and commit execution with conventional commit format.
Systematic TDD methodology for writing tests first. Use when implementing features or fixes with OMC_TDD_MODE enabled, when unsure how to structure tests, or when test-first discipline needs reinforcement. Triggers on: 'tdd', 'test first', 'test driven', 'red green refactor'.
Evidence-based verification methodology before claiming work is complete. Use when about to claim work is done, before committing, before creating PRs, or when verification-reminder hook fires. Triggers on: 'verify', 'verification', 'is it done', 'complete', 'ready to merge'.
Methodology for creating effective skills using TDD principles. Use when creating new skills, editing existing skills, or authoring plugin components. Triggers on: 'create skill', 'write skill', 'new skill', 'skill authoring'.
Systematic debugging methodology for diagnosing failures and root cause analysis. Triggers on: 2+ failed fix attempts, 'ultradebug', 'uld', debugging in circles, complex system failures, intermittent bugs.
Initialize or migrate to nested CLAUDE.md structure for progressive disclosure. Claude auto-loads CLAUDE.md from any directory it reads, enabling true contextual guidance. Triggers on: '/init-deep', 'deep init', 'initialize deeply', 'setup claude deeply', 'refactor claude.md', 'migrate claude.md', 'nested claude', 'progressive disclosure'.
| name | receiving-code-review |
| description | How to handle code review feedback with technical rigor. Use when receiving review comments from code-reviewer agent, PR reviews, or external feedback. Triggers on: 'review feedback', 'address review', 'fix review comments', 'code review response'. |
How to handle review feedback with technical rigor, not performative agreement.
READ -> UNDERSTAND -> VERIFY -> EVALUATE -> RESPOND -> IMPLEMENT
Read the full review. Don't skim, don't react immediately. Take in every comment before acting on any of them. Later comments may contradict or contextualize earlier ones.
For each issue, understand what's actually being flagged. Restate in your own words: "This comment is about X because Y." If you can't restate it, you don't understand it yet.
Check if the reviewer's claim is factually correct. Read the code they reference. Don't assume they're right or wrong -- look at the actual code at {file}:{line}.
Is this a real issue? Does the suggested fix actually improve things? Is the effort justified given the impact? Not all feedback requires action.
Technical response only:
{file}:{line} shows Y handles this case."Fix in order: clarify unclear items -> blocking issues -> simple fixes -> complex fixes. Test each fix independently before moving to the next.
These responses indicate you're people-pleasing, not engineering:
Instead: "The review identifies X. Checking... [evidence]. This is correct because [reason]. Fixing."
Or: "The review suggests X, but [counter-evidence]. Keeping current approach because [reason]."
| Source | Trust Level | Response Style |
|---|---|---|
| Human partner | High context | Clarify intent, implement thoughtfully |
| External reviewer | Medium context | Verify claims against code, ask about unknowns |
| code-reviewer agent | Systematic but no context | Cross-reference with requirements, verify specifics |
{file}:{line} shows Y"Pushing back is not adversarial. It's quality control. Reviewers benefit from knowing when their feedback misses context.
| Mistake | Why It's Wrong | Do This Instead |
|---|---|---|
| Fix everything without reading all comments | Later comments may contradict earlier ones | Read ALL comments first |
| Performative agreement | Hides misunderstanding | Respond with technical reasoning |
| Batch all fixes in one commit | Can't isolate if something breaks | One logical change per commit |
| Skip re-testing after fixes | Fixes introduce new bugs | Test after every change |
| Ignore minor issues | They accumulate | Fix or explicitly defer with reason |
Review feedback is data, not judgment. Evaluate it technically, respond with evidence, implement with discipline.