lesson-review-board

Lesson Review Board

Spawns multiple Agent subagents in parallel — each with a distinct review lens — and consolidates their critiques into a single approve/revise/reject decision. The board is a quality gate between content production (planner / researcher / builder) and content delivery (professor).

When to use this skill vs. others

• Plan modules → curriculum-planner
• Gather refs → lesson-researcher
• Build files → lesson-builder
• Critique drafts before student sees them → this skill
• Live delivery → professor

What the board reviews

Any of these artifacts (run the board on whichever just changed):

• Curriculum plan (CURRICULUM_PLAN.md) — before research begins
• Research dossier (research/<module>.md) — before building begins
• Lesson draft (lessons/, exercises/, solutions/) — before live delivery
• Assessment — before scoring matters

Panel composition

Spawn these reviewers as parallel Agent calls (single message, multiple tool uses):

1. Pedagogy reviewer

Lens: Does this teach effectively, given the learner's stated style?

• Are objectives demonstrable and testable?
• Does difficulty ramp without cliffs?
• Is the exercise solvable from the lesson alone (or does it secretly need outside knowledge)?
• Are hints graded — re-frame → concept-pointer → pseudocode — not all-or-nothing?
• Is composite material built from sub-components first?

2. Technical accuracy reviewer

Lens: Is what's being taught actually true?

• Spot-check claims against the research dossier and (when in doubt) re-verify with context7 / docs.
• Catch version skew (lesson teaches v2 idiom, codebase uses v4).
• Catch outright errors, broken code, wrong complexity bounds, wrong API signatures.
• Note any claim with no citation in the dossier.

3. Learner-fit reviewer

Lens: Does this match THIS learner's profile and prior preferences?

• Read auto-memory + course PROGRESS.md for the learner's stated style and gaps.
• Flag tone mismatches (over-hinting when the learner asked for minimal hints; under-hinting when they're new to the area).
• Confirm Pen-and-Paper Work / explicit docs-dive conventions are honored when applicable.

4. Exercise difficulty reviewer

Lens: Is the exercise the right size?

• Estimate solo solve time. Compare to plan estimate.
• Identify the one concept the exercise actually exercises. If it's testing five concepts at once, recommend splitting.
• Check that the test harness FAILs cleanly on empty skeleton and PASSes on the supplied solution.

5. Prerequisite-gap reviewer

Lens: Does this assume something never taught?

• Walk every concept used in lesson + exercise + solution.
• Verify each appears earlier in the course (or in a known prereq).
• Flag any "magic" concept that shows up unintroduced.

You can run a subset (3 reviewers) for small drafts; run the full panel for major artifacts (capstone, full module, curriculum plan).

How to invoke (template for parallel Agent calls)

In a single assistant message, emit one Agent tool call per reviewer with a self-contained prompt. Each prompt must include:

• The artifact to review (paths, not contents — let the agent read them)
• Pointers to the curriculum plan and the research dossier (if relevant)
• Pointers to the learner profile (auto-memory MEMORY.md, course PROGRESS.md)
• The reviewer's lens (paste the bullet list from above)
• A required output format (see below)
• A tight word cap ("under 300 words")

Use the Explore subagent_type for read-only review work; use general-purpose if the reviewer needs to run code (e.g., the difficulty reviewer running the test harness).

Required reviewer output format

Each reviewer must return:

VERDICT: approve | revise | reject
TOP ISSUES (max 5, in priority order):
1. <file:line> — <issue> — <suggested fix>
2. ...
NICE-TO-HAVES (max 3):
- ...
WHAT WORKS (1–2 lines):
- ...

approve = ship as-is. revise = fix the top issues then re-review. reject = fundamental problem; go back to planner/researcher/builder.

Consolidation (after all reviewers return)

You (the orchestrator) consolidate, do not re-judge:

1. Aggregate verdicts: if any reviewer says reject, the board verdict is reject. If any says revise, the board verdict is revise. Only unanimous approve ships.
2. Deduplicate issues: if multiple reviewers flagged the same thing, consolidate into one entry crediting all reviewers ("flagged by pedagogy + difficulty").
3. Resolve contradictions explicitly: if pedagogy says "more hints" and learner-fit says "fewer hints", surface the disagreement to the user — don't pick a side.
4. Order by impact: top issues first, nice-to-haves last.
5. Write the report to reviews/<artifact>-<YYYY-MM-DD>.md next to the artifact.

Consolidated report template

# Review Board — <artifact path>

**Date**: <YYYY-MM-DD>
**Verdict**: approve | revise | reject
**Reviewers convened**: <list>

## Top issues
1. <issue> — flagged by <reviewer(s)> — <suggested fix>
2. ...

## Nice-to-haves
- ...

## Disagreements (require human call)
- <issue A says X / issue B says Y — recommend …>

## What works
- ...

## Next step
- If approve: hand to `professor`.
- If revise: <which skill to re-run with which scope>.
- If reject: return to `curriculum-planner`/`lesson-builder` with <specific concern>.

Anti-patterns to avoid

• Single reviewer — defeats the purpose; always run at least three lenses.
• Reviewers seeing each other's reports — keep them independent; bias-free critiques diverge usefully.
• Prompts that bias the verdict — don't tell a reviewer "this is mostly fine, just sanity-check"; let them find what they find.
• Acting on the report yourself — the board reports; the user (or lesson-builder on the next pass) fixes. Don't silently rewrite based on critique.
• Skipping the gate — the temptation to skip review on "small" changes is what introduces drift over time.

After review

State the verdict and the recommended next skill. If revise, name the specific files and the specific issues — don't make the user re-read the full report to act.