Curriculum planner

Skill geopopos/teaching-pipeline-plugin/skills/curriculum-planner

Design the structure of a technical course or major curriculum revision — modules, ordering, prerequisites, learning objectives, time estimates. Use when the learner asks to "plan a course on X", "design a curriculum for Y", "outline modules for Z", "what should we cover", or when adding a multi-module unit (not a single lesson) to an existing course. Stops at the plan — does not research links (use lesson-researcher) or generate lesson files (use lesson-builder).From its SKILL.md

Install

npx -y skills add geopopos/teaching-pipeline-plugin --skill curriculum-planner

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.9 KB, as published. Nobody here has run it

Curriculum Planner

Plans the shape of a course: which modules exist, what order they go in, what each module's learning goals are, and how they depend on each other. Output is a curriculum plan, not lesson content.

When to use this skill vs. others

Plan the whole course or a major redesign → this skill
Find authoritative docs/links for a planned module → lesson-researcher
Generate the actual lesson.md / exercise / solution files → lesson-builder
Get a draft plan reviewed before committing → lesson-review-board
Deliver the lessons interactively → professor

Inputs to gather before planning

Ask the user (concisely — don't interrogate):

Topic and end-state: "By the end, the learner can ___" (one sentence).
Learner profile: existing skills, gaps, language preferences, comfort with math/systems.
Constraints: language, runtime, target depth (overview vs. deep mastery), time budget per week.
Style preferences: hint level, pen-and-paper component, build-from-scratch vs. SDK-driven, preferred file layout.

If the user already has prior courses with a similar structure, mirror those conventions rather than inventing new ones. Read one of their existing PROGRESS.md and README.md files to calibrate.

The conventions this pipeline assumes by default are documented in CONVENTIONS.md.

Planning workflow

Phase 1 — End-state & spine

Write the terminal capability in one sentence ("Build a working CLI coding agent from scratch"). Then list 5–20 capabilities a learner must have to reach it. Group related capabilities into candidate modules.

Phase 2 — Module sequencing

Order modules so each only depends on earlier ones. For each module, record:

Number + title
Prerequisites (specific earlier modules, not "general programming")
Learning objectives (3–6 bullets, each starting with a verb the learner can demonstrate: implement, explain, trace, debug, derive)
Key concepts introduced
Concrete exercise idea (one line — what they'll build)
Estimated time (a range — "3–5 hours")
Notes (e.g., "needs Python generators refresher first" if the learner profile flags a gap)

Phase 3 — Identify mini-courses / prereq inserts

Look for objectives that assume background knowledge the learner doesn't have. Promote those to a short prerequisite mini-course rather than burying them inside another module. Common examples: a generators refresher before async/streaming modules, a subprocess refresher before tool-running modules.

Phase 4 — Capstone

End with an integration project that forces the learner to use most prior modules together. The capstone is the proof the course delivered the terminal capability.

Phase 5 — Output the plan

Produce a single markdown plan file with:

# [Course Name] — Curriculum Plan

**Terminal capability**: <one sentence>
**Learner profile**: <summary>
**Total modules**: N
**Estimated total time**: X–Y hours

## Module Map
1. <Module 1 title> — <one-line purpose>
2. ...

## Module Details
### Module 01 — <Title>
- Prereqs: <list>
- Objectives:
  - <verb> ...
- Concepts: ...
- Exercise: ...
- Estimated time: ...

[repeat per module]

## Prerequisite mini-courses
- <Name> — inserted before Module XX because <reason>

## Capstone
<description>

## Open questions for the learner
<list — anything you couldn't decide alone>

Save the plan to the course directory as CURRICULUM_PLAN.md (or update an existing one). Do not generate lesson files yet — the plan is the deliverable.

Anti-patterns to avoid

Module sprawl: 30+ tiny modules. Combine adjacent objectives if they share an exercise.
Hidden prerequisites: a module that secretly assumes a concept never taught. Walk the prereq chain explicitly.
Overlapping objectives across modules: each concept should have a single home; later modules apply it, not re-teach it.
Time estimates without ranges: always use a range; learners vary.
Designing for a hypothetical advanced learner when the actual learner is at a different level — calibrate to this learner.
Skipping the capstone: without it, the course has no ending.

After the plan exists

Recommend the next step explicitly: "Plan ready at CURRICULUM_PLAN.md. Next: run lesson-researcher per module to gather authoritative refs, then lesson-review-board on the plan before building any files."