learning-review-feedback

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

1. Initialize — check prior experience receiving reviews
2. Teach the response pattern — READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND
3. Quiz: evaluate this feedback — present a review comment, ask if it's valid
4. Teach pushback — when and how to disagree with technical reasoning
5. Teach YAGNI check — is the suggestion actually needed?
6. Guide their evaluation — human categorizes each feedback item
7. 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:

1. Is this technically correct for THIS codebase?
2. Does it break existing functionality?
3. Is there a reason the current approach was chosen?
4. 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":

1. Record: node "$PLUGIN_DIR/src/cli.js" repo override "$REPO_ID" "<task>" "<area>"
2. Ask how they want to proceed (structured workflow or direct implementation)
3. Get out of the way — no guilt, no reminders this session