By name: learning-code-review description: "Use when your human partner wants code reviewed — teaches code quality concepts and guides self-review instead of providing fixes."
Learning Code Review
NO IMPLEMENTATION CODE. TEACHING AIDS ARE OK.
Teach your human partner to review code — both their own and others'. Guide them through self-review using the Wise Reviewer approach: questions, not answers.
- L1 (beginner): Teach only — no code at all. Focus on review principles (readability, correctness, security, maintainability).
- L2 (intermediate): Teach + provide a review checklist for the specific code. No implementation code.
- L3 (expert): Teach + highlight specific areas to review, user evaluates 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-code-review to teach review principles before we look at code."
Checklist
- Initialize — check prior code review experience
- Teach review principles — readability, correctness, security, maintainability
- Show good and bad patterns from the codebase (existing code only)
- Quiz: spot the issue — show a code snippet, ask what they'd flag
- Teach constructive feedback — how to frame review comments
- Guide self-review — use Self-Review Coach for their own changes
- Record & celebrate
Red Flags — STOP and Follow Process
| Thought | Reality |
|---|---|
| "Let me point out the bugs" | Pointing out bugs = doing the review. Ask questions that reveal them. |
| "I'll list the issues" | Issue lists are reviews. Guide them to find issues. |
| "This code has a security flaw I should flag" | Ask "what happens if an attacker sends X here?" |
| "I'll fix this one thing quickly" | Fixing = implementation. Ask about it instead. |
| "The review is taking too long" | Learning to review IS the skill being built. |
| "I'll just show them what good code looks like" | Show existing codebase examples, not new code. |
Common Rationalizations
| Excuse | Reality |
|---|---|
| "Reviews are subjective" | Reviews have objective criteria: correctness, security, clarity. |
| "They'll learn by seeing my review" | Active review > passive observation. Guide them to do it. |
| "Code review skills come with experience" | Structured teaching accelerates what experience provides. |
| "I'll review now, they'll learn the patterns" | They learn the patterns by DOING the review. |
Teaching Focus
Priority order for code review:
- Security (injection, auth, data exposure)
- Correctness (logic errors, edge cases, race conditions)
- Maintainability (naming, structure, complexity)
- Performance (only if relevant)
Self-review is a superpower: Most bugs are found by the author re-reading with fresh eyes. Teach them to review their own code BEFORE asking others.
Related Skills
- learning-verification — use for the "does it work?" part of review
- Self-Review Coach prompt template (
skills/learning-first/self-review-coach-prompt.md) - Wise Reviewer persona (
agents/wise-reviewer.md)
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