| name | review-submission |
| description | Reviews the user's solution to an exercise. Analyzes correctness, functionality, and quality without rewriting the code. Pass the topic path as argument. |
| argument-hint | <block/topic/subtopic> |
| disable-model-invocation | true |
| allowed-tools | Read Glob |
Goal
Review the user's current solution to an exercise across three dimensions — in order. Point out what is good before pointing out what to improve. Never rewrite the code.
Step 1 — Resolve paths
The topic path is $ARGUMENTS (e.g. block1-base/01-memory/01-stack-vs-heap).
Read both files:
$ARGUMENTS/README.md — understand what was asked and what concept is being tested$ARGUMENTS/Exercise.java — read both the original scaffold AND the user's written code
If Exercise.java has no user code (only TODOs remaining), stop and tell the user: "No solution found yet. Complete at least part of the exercise before requesting a review."
Step 2 — Analyze in three dimensions
Evaluate in this order:
Dimension 1 — Conceptual correctness
Is the user applying the right Java concept for this topic?
- Is the core concept (e.g. stack vs heap, equals contract, stream pipeline) understood and applied?
- Common mistakes to check: using
== when equals is needed, mixing checked/unchecked exception semantics, ignoring immutability, etc.
Dimension 2 — Functional correctness
Does the code actually work?
- Are there compile errors, logic bugs, or missing return statements?
- Are edge cases handled (null, empty collections, division by zero, etc.) when the README implies they should be?
Dimension 3 — Code quality
Is there a cleaner or more idiomatic Java way?
- Only raise this if there is a meaningfully better approach, not cosmetic preferences.
- Examples: using
Map.getOrDefault instead of null check + put, using Optional instead of null return, using enhanced for instead of index loop where applicable.
Step 3 — Write the review
Structure the output:
## Review: <topic name>
### What's working
<1–3 bullet points on what the user got right — be specific, not generic praise>
### Dimension 1 — Conceptual correctness
<Finding or ✓ if correct>
### Dimension 2 — Functional correctness
<Finding or ✓ if correct>
### Dimension 3 — Code quality
<Finding or ✓ if no significant improvement needed>
### Next step
<One concrete, actionable suggestion — only if there is something to fix>
Rules:
- Never paste a corrected version of the code.
- Never say "here's how it should be done" followed by a full implementation.
- You may show a single line or expression as a hint if a quality improvement is genuinely non-obvious.
- Keep the tone balanced — a junior dev should not feel crushed by this review.
