Verification-first approach to code review feedback. Use when receiving review comments during the implement phase. Evaluate suggestions rigorously before implementing - no performative agreement.
/plugin marketplace add bostonaholic/rpikit/plugin install rpikit@rpikitThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Verify feedback before implementing. No performative agreement.
Code review feedback requires rigorous evaluation, not automatic acceptance. Reviewers may lack context, make incorrect suggestions, or propose changes that conflict with project requirements. This skill enforces verification before implementation.
Evaluate suggestions rigorously before implementing.
Not all feedback is correct. Not all suggestions improve the code. Your job is to verify, not to agree performatively.
Never respond with:
These are performative, not technical. They waste time and signal you're not actually evaluating the feedback.
For each piece of feedback, complete these steps:
Read the entire feedback before reacting:
Restate what the reviewer is asking for:
"The feedback requests: [restatement in your own words]"
If you can't restate it clearly, you don't understand it.
Check whether the suggestion is correct for THIS codebase:
Questions to answer:
- Is the reviewer's assumption about the code correct?
- Does this file/function work the way they think?
- Are there constraints they might not know about?
Evaluate whether the suggestion is technically sound:
Consider:
- Will this change break existing functionality?
- Does it align with project patterns?
- Is the suggested approach better than alternatives?
- What are the trade-offs?
If feedback is valid: Implement it, then respond factually.
"Fixed. [Brief description of what changed]"
"Implemented. Added null check at line 45."
"Done. Extracted helper function as suggested."
If feedback needs clarification: Ask specific questions.
"Clarifying question: Does this apply when [specific case]?"
"Can you elaborate on [specific aspect]?"
If feedback is incorrect: Push back with technical reasoning.
"Pushing back on this suggestion because [reason].
The current implementation handles [specific case] by [explanation].
The suggested change would break [specific behavior]."
Push back when:
Push back format:
"I'm pushing back on [specific suggestion] because:
1. [Technical reason]
2. [Evidence from codebase]
The current approach [explanation of why it's correct].
Alternative consideration: [if applicable]"
When feedback is unclear:
STOP - do not implement anything yet.
Ask for clarification:
"I want to make sure I understand correctly.
Are you suggesting [interpretation A] or [interpretation B]?"
Never guess at unclear feedback. Implementation based on misunderstanding wastes time and may create cascading errors.
When implementing review feedback:
Blocking issues first
Simple corrections next
Complex refactoring last
Test after each fix. Do not batch changes.
Question suggestions that add unused features:
Reviewer: "We should also handle case X"
Response: "Is case X currently needed? The existing usage only
requires [current scope]. Adding X introduces complexity for
a case we don't have yet (YAGNI).
If X becomes necessary, we can add it then."
For reviewers outside the immediate team:
Before implementing, verify:
External reviewers may not know:
This skill activates during code review cycles:
Code review received
→ For each comment:
→ Read completely
→ Restate requirements
→ Verify against codebase
→ Assess technical soundness
→ Respond appropriately
→ Test after each implemented change
→ Request re-review when done
When feedback is correct, use factual acknowledgments:
Correct: "Fixed. Added validation at line 23."
Correct: "Implemented. Refactored to use existing helper."
Correct: "Done. Tests now cover edge case."
Incorrect: "Great catch! You're absolutely right!"
Incorrect: "Thanks so much for pointing that out!"
Incorrect: "I can't believe I missed that!"
Factual, not performative.
Wrong: Accept all feedback without evaluation Right: Verify each suggestion before implementing
Wrong: "You're absolutely right!" Right: "Fixed. [what changed]"
Wrong: Guess at what the reviewer meant Right: Ask for clarification first
Wrong: Implement all feedback, then test once Right: Test after each change
Wrong: Implement everything to avoid conflict Right: Push back when technically justified
Wrong: "I disagree" (no explanation) Right: "Pushing back because [technical reason]"
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.