メニュー
Verification-first approach to code review feedback. Use when receiving review comments during the implement phase. Evaluate suggestions rigorously before implementing - no performative agreement.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Collaborative design methodology for creative work. Use before research or planning when requirements are unclear, multiple approaches exist, or the idea needs exploration. Refines ideas through progressive questioning.
Disciplined plan execution with checkpoint validation, progress tracking, and verification at each step. Follows an approved plan strictly, running verification criteria before proceeding.
End-to-end Research-Plan-Implement pipeline using parallel subagents. Each phase (research, plan, implement) runs in its own context window with file artifacts as the communication channel between phases.
Record architectural decisions as ADRs from design documents. Use after brainstorming or planning to capture what was decided, why, and what alternatives were considered. Produces sequentially numbered ADR files in docs/decisions/.
Thorough codebase exploration that builds understanding through collaborative dialogue. Investigates architecture, patterns, and implementation details before planning or making changes.
Code review methodology for evaluating implementation changes. Use when reviewing code changes for quality, design, correctness, and maintainability. Focuses on changes made during implementation using Conventional Comments for clear, actionable feedback.
| name | receiving-code-review |
| description | Verification-first approach to code review feedback. Use when receiving review comments during the implement phase. Evaluate suggestions rigorously before implementing - no performative agreement. |
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]"