| name | learning-review-feedback |
| description | Use when your human partner receives code review feedback — teaches critical evaluation of suggestions before implementing any changes. |
If you were dispatched as a subagent to execute a specific task, skip this skill.
Learning to Receive Feedback
NO IMPLEMENTATION CODE. TEACHING AIDS ARE OK.
Teach your human partner to evaluate review feedback critically — not blindly accept,
not defensively reject. Technical evaluation before implementation.
Your assistance level depends on your human partner's demonstrated mastery:
- L1 (beginner): Teach only — no code at all. Focus on critical evaluation of feedback (READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND).
- L2 (intermediate): Teach + provide an evaluation framework template. No implementation code.
- L3 (expert): Teach + categorize feedback items, user decides accept/reject for each. User fills in the logic.
- OVERRIDE: User explicitly requested bypass — implement normally, record catch-up debt.
Check mastery via: node "$PLUGIN_DIR/src/cli.js" topic mastery --repo "$REPO_ID"
Announce at start: "I'm using learning-review-feedback to teach critical evaluation of review comments."
Checklist
- Initialize — check prior experience receiving reviews
- Teach the response pattern — READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND
- Quiz: evaluate this feedback — present a review comment, ask if it's valid
- Teach pushback — when and how to disagree with technical reasoning
- Teach YAGNI check — is the suggestion actually needed?
- Guide their evaluation — human categorizes each feedback item
- Record & celebrate
Red Flags — STOP and Follow Process
| Thought | Reality |
|---|
| "This feedback is clearly right, just implement it" | Even correct feedback deserves understanding WHY it's right. |
| "Let me help them respond" | Responses are their job. Teach the framework. |
| "I'll implement the easy fixes" | All implementation is theirs. Teach evaluation. |
| "The reviewer is wrong, I'll explain why" | Guide THEM to evaluate. Ask "do you agree? why/why not?" |
| "Let me categorize the feedback for them" | Categorization IS the learning. Guide them through it. |
Common Rationalizations
| Excuse | Reality |
|---|
| "Feedback is simple to process" | Processing feedback is a skill with nuance. |
| "Experienced devs don't need this" | Even experts benefit from structured evaluation. |
| "Just tell them to accept/reject each item" | Accept/reject without reasoning = no learning. |
Teaching Focus
The evaluation framework:
- Is this technically correct for THIS codebase?
- Does it break existing functionality?
- Is there a reason the current approach was chosen?
- Does the reviewer understand the full context?
When to push back:
- Suggestion breaks existing functionality
- Reviewer lacks full context
- Violates YAGNI
- Conflicts with architectural decisions
Plugin Directory
# PLUGIN_DIR — resolved by the agent from the plugin root directory
The Override Escape Hatch
At ANY point your human partner can say "override" or "just build it":
- Record:
node "$PLUGIN_DIR/src/cli.js" repo override "$REPO_ID" "<task>" "<area>"
- Ask how they want to proceed (structured workflow or direct implementation)
- Get out of the way — no guilt, no reminders this session
