Purpose
Provide structured, constructive review of a learner's project at a milestone or completion checkpoint. Combines technical evaluation with learning-outcome assessment. Uses Praise-Critique-Grow to maintain learner motivation while surfacing real issues.
Activation
- Milestone reached in
build-with-me. Feature or project completed. Learner asks for feedback on their work. Pre-submission review (assignment, portfolio, interview take-home).
- Skip if: project hasn't started. Learner needs concept help →
teach-concept. Active debugging in progress → debug-teacher.
- Routing: issues found → use
challenge-generator for targeted practice. Concept gaps → teach-concept. Design issues → architecture-review. Log weak areas to weak-area-tracker.
Inputs
- Project/feature code and documentation, original requirements/scope, learner's stated goals, relevant assessment criteria.
Review Dimensions
- Scope: does it meet stated requirements? Scope creep? Missing features?
- Correctness: does it produce correct results? Edge cases handled?
- Code Quality: readability, naming, structure, DRY, separation of concerns.
- Testing: test coverage, test quality, edge case testing.
- Learning Outcomes: what did the learner demonstrate they understand? What gaps remain?
Workflow
- Self-Assessment — Ask learner first: "What do you think went well? What would you change?" This surfaces their self-awareness before external feedback.
- Review — Evaluate across all 5 dimensions. Note strengths and issues with specific code/design references.
- Praise — Start with 2–3 specific strengths. Reference actual decisions/code, not generic compliments.
- Critique — List issues priority-ordered. Each: dimension, description, severity, specific code reference. Max 5 issues per review — more overwhelms.
- Grow — For each major issue: one concrete next action. Frame as growth opportunity, not failure. Include a learning recommendation (skill or concept to revisit).
- Retrospective — Ask one synthesis question: "What's the most important thing you learned from building this?" Record answer for
learning-memory.
Rules
- DO: require self-assessment before giving feedback.
- DO: praise specific decisions, not generic effort.
- DO: limit critique to top 5 issues — prioritize by impact.
- DO: frame growth actions as opportunities, not failures.
- DO: end with a retrospective question and record the answer.
- DON'T: start with criticism — always Praise first.
- DON'T: give vague feedback ("good job" / "needs work").
- DON'T: rewrite the learner's code — point to issues and let them fix.
- DON'T: skip the self-assessment — it builds metacognitive skill.
Output
Responses should contain: self-assessment prompt, praise (2–3 specific strengths), critique (issues with dimension + severity + code reference), grow (next actions + learning recommendations), and retrospective question. Format naturally.
Checklist
1---2name: project-review3description: Use when evaluating a completed or in-progress project across scope, correctness, quality, testing, and learning outcomes using structured Praise-Critique-Grow feedback.4---56# Purpose78Provide structured, constructive review of a learner's project at a milestone or completion checkpoint. Combines technical evaluation with learning-outcome assessment. Uses Praise-Critique-Grow to maintain learner motivation while surfacing real issues.910# Activation1112- Milestone reached in `build-with-me`. Feature or project completed. Learner asks for feedback on their work. Pre-submission review (assignment, portfolio, interview take-home).13- **Skip if**: project hasn't started. Learner needs concept help → `teach-concept`. Active debugging in progress → `debug-teacher`.14- **Routing**: issues found → use `challenge-generator` for targeted practice. Concept gaps → `teach-concept`. Design issues → `architecture-review`. Log weak areas to `weak-area-tracker`.1516# Inputs1718- Project/feature code and documentation, original requirements/scope, learner's stated goals, relevant assessment criteria.1920# Review Dimensions2122- **Scope**: does it meet stated requirements? Scope creep? Missing features?23- **Correctness**: does it produce correct results? Edge cases handled?24- **Code Quality**: readability, naming, structure, DRY, separation of concerns.25- **Testing**: test coverage, test quality, edge case testing.26- **Learning Outcomes**: what did the learner demonstrate they understand? What gaps remain?2728# Workflow29301. **Self-Assessment** — Ask learner first: "What do you think went well? What would you change?" This surfaces their self-awareness before external feedback.312. **Review** — Evaluate across all 5 dimensions. Note strengths and issues with specific code/design references.323. **Praise** — Start with 2–3 specific strengths. Reference actual decisions/code, not generic compliments.334. **Critique** — List issues priority-ordered. Each: dimension, description, severity, specific code reference. Max 5 issues per review — more overwhelms.345. **Grow** — For each major issue: one concrete next action. Frame as growth opportunity, not failure. Include a learning recommendation (skill or concept to revisit).356. **Retrospective** — Ask one synthesis question: "What's the most important thing you learned from building this?" Record answer for `learning-memory`.3637# Rules3839- DO: require self-assessment before giving feedback.40- DO: praise specific decisions, not generic effort.41- DO: limit critique to top 5 issues — prioritize by impact.42- DO: frame growth actions as opportunities, not failures.43- DO: end with a retrospective question and record the answer.44- DON'T: start with criticism — always Praise first.45- DON'T: give vague feedback ("good job" / "needs work").46- DON'T: rewrite the learner's code — point to issues and let them fix.47- DON'T: skip the self-assessment — it builds metacognitive skill.4849# Output5051Responses should contain: self-assessment prompt, praise (2–3 specific strengths), critique (issues with dimension + severity + code reference), grow (next actions + learning recommendations), and retrospective question. Format naturally.5253# Checklist5455- [ ] Self-assessment requested before external feedback.56- [ ] Praise references specific code/decisions.57- [ ] Critique limited to top 5 issues, priority-ordered.58- [ ] Retrospective question asked and answer recorded.