review

name	review
description	Review the learner's build exercise implementation against acceptance criteria. Use this skill when the learner says /review, pastes code, or describes what they built. Evaluates against the build-exercise.md acceptance criteria and gives specific feedback tied to exam concepts.

Review

Purpose

Evaluate the learner's build exercise work against the acceptance criteria and give actionable feedback tied to exam concepts.

---

How to run this

Step 1 — Identify the domain

Ask: "Which domain's build exercise should I review? (1-5)"

Or infer from context if the learner just finished a build exercise.

Step 2 — Load the criteria

Read modules/domain-N/build-exercise.md for the acceptance criteria checklist.

Step 3 — Get the work

Check workspace/domain-N/ for the learner's implementation files. If files exist there, read them directly.

If no files are found, ask the learner to share their implementation. They can:

• Paste code snippets
• Describe their architecture
• Walk through what they built

Step 4 — Evaluate against acceptance criteria

Go through each acceptance criterion:

1. Ask about or review evidence for each item
2. Mark as met or not met
3. For items not met, explain:
   • What's missing
   • Why it matters (tie to exam concept)
   • How to fix it (guidance, not code)

Step 5 — Give feedback

Structure feedback as:

Criteria Met:

• List what they got right, with brief positive note

Criteria Not Met:

• List what's missing, with specific feedback on each

Exam Connection:

• Connect their implementation choices to exam concepts
• Point out any anti-patterns they may have implemented
• Highlight what would be tested on the exam about their approach

Step 6 — Update progress

If all criteria are met:

• Set domains.N.build.status to "completed" in state.json
• Set domains.N.build.criteria_met to the full criteria list

If some criteria are not met:

• Update criteria_met with what they've completed so far
• Keep status as "in_progress"

Step 7 — Next steps

If all criteria met:

"Your Domain [N] build exercise is complete! Run /progress to see your overall readiness."

If some criteria not met:

"You're [X/Y] criteria away from completing this exercise. Address the items above and run /review again when ready."

---

Review principles

• Be specific — "Your error handling returns plain text instead of structured metadata with errorCategory and isRetryable fields" is better than "error handling needs work."
• Tie to the exam — "The exam tests whether you distinguish access failure from valid empty result — your implementation treats them the same."
• Guide, don't solve — Point to what's wrong and why, but let the learner fix it.
• Acknowledge good work — If something is well-implemented, say so. Learning needs positive reinforcement too.

---

Common failure modes to avoid

• Being too lenient — If a criterion isn't met, it isn't met. Don't pass them for effort.
• Being too harsh — They're learning. Focus on what they need to fix, not what they did wrong.
• Writing code — Review skill reviews. It does not write implementation code.
• Not connecting to exam concepts — Every piece of feedback should tie back to what the exam tests.