---
name: material_to_self_study_course
description: Turn any source material into a self-study course: inventory the source, map it to observable capabilities, order modules by what the practice tasks actually use, write practice before answers with the answers in separate hidden files, and set a spaced review schedule with tutor checkpoints. Ships a capability mapper, a review schedule script, and a worked course built from OpenStax Introductory Statistics. Use when someone has a book, handbook, manual, course notes, docs, or a pile of articles and wants to learn from it on their own, asks to build a self-study plan or curriculum from material they already have, or has a summary and notes but no course.
---

# Material to Self-Study Course

## Purpose

Convert source material a learner already has into a course a single learner can run alone: capabilities they can practise, modules in an order that works, practice with answers kept out of sight until the attempt is written, and reviews scheduled far enough apart to still be there in a month.

This skill builds the course. It does not tutor the learner through it, and it does not write an outline for a taught class. A taught course can lean on a teacher to fill gaps live. A self-study course has to carry the sequencing, the checks, and the corrections inside its own files, because nobody is in the room when the learner gets stuck.

The design rests on findings that held up under review. Dunlosky and colleagues (2013) reviewed ten common learning techniques and gave only two a high utility rating: practice testing and distributed practice. Rereading and highlighting got low ratings. Roediger and Karpicke (2006) found the same pattern in direct experiments: restudying won on a test five minutes later, testing won after two days and after a week. So this skill spends its effort on practice, spacing, and feedback, and treats reading as the input, never as the proof of learning.

## Workflow

### 1. Fix the scope and the entry point before touching content

- Name the source exactly: title, edition or version, and where it lives. A course built on the wrong edition has wrong page and section references everywhere.
- Cut the scope to what the learner can finish. State what is in, what is out, and what becomes a later course. A finished three chapter course beats a thirteen chapter course abandoned at chapter four.
- Set the retention goal in days: how long after finishing the material still has to be usable. This number drives the review schedule in step 6. Ask if it is missing. Exam in six weeks and skill needed for a year are different courses built from the same book.
- Write an entry check: the small set of things a learner must already be able to do on day one, drawn from what the first module actually uses. A learner who fails it gets a short repair task first. Do not hide prerequisite gaps inside module 1 and call it teaching.

### 2. Inventory the source, section by section

- Walk the source in order and list every section, worked example, procedure, table, and end problem set. One row per unit, with its source reference. Do not work from the table of contents alone if the body adds or drops material the contents page hides.
- Mark each unit with what it gives the learner: a term, a concept, a procedure, a judgement call, or a worked example of one of those. Units that give nothing the learner will ever do, like a historical preface in a procedures manual, get marked background and stay out of the capability map.
- Note where the source itself supplies practice and answers. Many textbooks pair a worked example with an immediate practice problem. That pairing is an asset: keep it, and build the rest of the course to the same pattern.

### 3. Map units to observable capabilities

- Rewrite each teachable unit as one or more capability statements in this shape: observable verb, what the learner acts on, the condition it happens under, and the standard it has to meet. Full verb lists and translations of weak statements live in `references/capability-verbs.md`.
- Reject verbs nobody can watch: know, understand, learn, appreciate, grasp, master, cover. If a syllabus line says the learner will understand a topic, translate it into what the learner will produce, choose, calculate, or defend once they do.
- Set each capability's level from the revised Bloom taxonomy, Remember through Create, based on the hardest thing its practice task will demand. Most self-study material sits at Remember, Understand, and Apply. Do not inflate levels to make the course sound advanced.
- Put the inventory in a CSV with columns module, source_ref, capability, verb, level, depends_on, and run the mapper:

```
python3 scripts/capability_map.py inventory.csv
python3 scripts/capability_map.py inventory.csv --check-only
```

- Fix every error the mapper reports before moving on: vague verbs, unknown prerequisites, duplicate capabilities, and prerequisite cycles. A cycle means the sequencing judgement is wrong somewhere, not that the tool is fussy.

### 4. Order modules by what the practice tasks use

- Draw each module's prerequisites from its practice tasks, not from chapter order. Ask of each task: what must the learner already be able to do to attempt this honestly? Those abilities are the prerequisites, even when the source teaches them later or assumes them silently.
- Use backward design order inside each module: capability first, then the evidence that would prove it, then the reading and example study that prepare for that evidence. Wiggins and McTighe's three stages, Identify desired results, Determine acceptable evidence, Plan learning experiences, work at module size as well as course size.
- When your order departs from the source's order, write one line saying why. The worked course in `references/worked-course.md` shows a case where task order and chapter order agree, and says how to tell.
- Keep modules small enough to finish in one to three sittings. A module the learner cannot finish gets split at a capability boundary, never in the middle of a procedure.

### 5. Write practice before answers, and keep the answers apart

- Write the practice set first, one or more tasks per capability, before writing any answer file. Writing answers first bends the questions toward what is easy to mark.
- For novices, build each set as example and problem pairs: study a worked example from the source, then do a near copy with the numbers, case, or wording changed, then a problem that mixes in an earlier capability. Sweller and Cooper's worked example research found this pairing teaches novices faster than unaided problem solving, because unaided search burns the attention the learner needs for the method itself. Fade the support across the set: full example, partial example with steps missing, bare problem.
- Put answers in separate files, named to match the practice file, in an answers folder or with an answers suffix. The learner's rule, printed at the top of every practice file: write every answer, with a confidence note of sure, half sure, or guessed, before opening the answer file. An answer read before an attempt is made turns a test back into rereading, the low utility technique this whole design avoids.
- Write answers that teach: the result, the step or fact that decides it, and the correction for the most common wrong answer when there is one. A bare letter or number gives the learner no way to fix a miss.
- Set a pass rule per module in capability terms, not averages: for example at least three of four tasks right and no capability with zero right answers. A failed capability sends the learner back to that capability's section and example only, then to fresh tasks on it alone. Retaking the whole module wastes the parts that held.

### 6. Schedule spaced reviews with tutor checkpoints

- Record each module's learn date as it is planned, in a CSV with columns module and learn_date, and generate the schedule:

```
python3 scripts/review_schedule.py plan.csv --retention-days 90
```

- The default ladder is 1, 3, 7, 14, 30, and 60 days, cut off at the retention goal. Present it honestly as a practical starting schedule. Cepeda and colleagues (2006), reviewing 317 experiments, found the gap that works best grows with how long the material has to be retained, so no single ladder is right for every goal. A 30 day goal wants shorter gaps than the default. A one year goal wants the ladder stretched, not more reviews crammed into the first month.
- Every review is a recall attempt first: redo two or three practice tasks from the module closed-book, or write the module's capabilities from memory and perform one. Only then open the answer file. A review session spent rereading the chapter does not count and does not get logged as done.
- Run the adaptive rule and say it in the course: a failed review pulls that module's next review to the next day and restarts its ladder, which the learner records by adding a new row with the restart date. A review passed with no hesitation can skip one rung. Without this rule a printed schedule rots the first time life moves a date.
- Mark the review nearest seven days as the tutor checkpoint. The learner brings every failed item from that module to a tutor, a peer, a study partner, or, if truly alone, a written self-check done a day later against the answer file. The checkpoint record names the failed item, the cause in the learner's words, the fix applied, and the retest result. A checkpoint with no failures still samples two capabilities cold, because a module passed on its learn day is not yet evidence it survived a week.

### 7. Assemble the course pack and test it cold

- Deliver one folder per course: the capability map, one module file per module in order, practice files, answer files in their own folder, the review schedule, and a one page start sheet that says where to begin, what the entry check is, and what to do when stuck.
- Test the pack the way a learner hits it: pick the middle module, follow only its own instructions, and try its practice set. Any place you need knowledge the pack has not supplied, in an earlier module or in the source at the stated reference, is a defect. Fix the pack, not the test.
- Check the answer separation mechanically: no practice file contains its own answers, no answer appears in a worked example copied into a practice file, and file names do not leak answers.
- Run both scripts one last time on the shipped inventory and plan, and record their output in the delivery note. A course whose map has errors was not finished, whatever the files look like.

## Output Contract

For a course built from source material, produce:

- The source statement: title, edition or version, scope in and out, retention goal in days, and the entry check with its repair task.
- The capability inventory CSV and the mapper output: modules in prerequisite order, every capability with its level and source reference, zero errors.
- One module file per module: reading references, the worked examples to study and how to study them, and the pass rule for the module.
- One practice file per module and matching answer files kept separate, with the attempt-before-answers rule printed on each practice file.
- The review plan CSV and the generated schedule, with checkpoints marked, the adaptive restart rule stated, and the checkpoint record format.
- A worked example of the whole method when the course is the first one for this learner or source type, following `references/worked-course.md`.

## Operating Rules

- Reading is input, never evidence. Every claim that a learner knows something rests on a written attempt made before the answer was visible.
- One capability, one observable verb, one pass rule. Split any statement that needs two verbs to describe.
- Prerequisites come from what practice tasks use, not from chapter order, habit, or the author's preface.
- Answers never live in the same file as their questions, and never get written before the questions.
- The review ladder is a starting schedule adjusted by results, never a promise. State the retention goal it was built for wherever the schedule is printed.
- A failed capability gets narrow rework: its section, its example, fresh tasks on it alone. Whole module repeats are a last resort.
- Do not invent facts the source does not contain. If a practice task needs a case, a data set, or a standard the source lacks, build it, label it as course-built, and keep its answers verifiable by hand.
- Respect the source's licence and the learner's rights in it. Quote short passages for practice where that is allowed, point to section references for the rest, and never copy a paid text wholesale into course files.
- If the source is too thin to support practice, say so and stop at a reading guide. Calling a summary a course is the failure this skill exists to prevent.