design-course — design a course from its outcomes

This skill is an ordered checklist: each step opens when the one before it has produced its result. The order is the point. A course designed forwards — topics first, then activities, then whatever the topics happen to allow the exam to ask — produces outcomes written afterwards to describe what was already built. They describe it accurately while claiming levels nothing reaches. Designing backwards from the outcomes is what makes the claim true.

Whenever a step puts more than one decision to the user, it asks them in the round shape the grill-point skill gives in its step 3.

A run of this skill can outlast one session's context, so every step the plan marks 🛑 writes a handoff named for this skill, HANDOFF-<skill>.md, into the run's folder, once that folder exists, before it stops: the step to resume at and where inside it, the questions waiting on the user, what the run has learned that none of its files records, and the files to read first. A decision already written into a file is pointed to rather than copied, because two copies of one answer drift apart, and every answer a grill settled is already in this skill's grill log, GRILL-LOG-<skill>.md, where the run has one; a decision settled outside a grill and not yet written anywhere goes into the handoff, or it is lost with the session. The file is rewritten whole at each stop, and the stop ends with one line, in the user's language, saying that the session can be closed here and giving the line, naming the skill and the folder, that resumes the run in a new one. The last step deletes it.

What an outcome has to be, and the two directions alignment is checked in, are in the learning-outcomes skill — read it before step 4. This skill writes the design; make-exam builds assessments on it and re-checks the outcomes before it does.

Where the artifacts go is the host project's decision. Absent a rule, the default is a design/ folder beside the subject's other material, holding outcomes.md, assessment-plan.md, and teaching-plan.md. That is a skill default rather than a shared layout, because no other skill in this set writes these files yet.

Steps

1. Discover the project's conventions — read the host project's agent instructions file (AGENTS.md, or CLAUDE.md) and inspect an existing course design: folder layout, file naming, available templates, the language the project writes in, and whether the project or the institution fixes the form a course design takes. Find too the project's own standard for outcomes — its verb list, its rules on verbs per outcome and on verb level against the curriculum map — by the search the learning-outcomes skill describes; where it is stricter than that skill, it governs step 4. A project's own rules override the defaults here; an institution's mandated form overrides the document shapes below, and the design is recorded in whatever fields that form provides. Where the folder this run writes into already holds this skill's handoff, the run is resuming: read it before the run's other files, read first the files it lists, and take the step it names, checked against the files that exist, since a session can end between stops after its last handoff was written. Another skill's handoff in that folder belongs to that skill's run and is left as it is. Where that folder holds an unfinished run of this skill — one whose last step has not yet written into the folder — but no handoff, infer the step from the files that exist; a finished run's files are read as the steps below direct, not resumed. Where the step was inferred, or the handoff and the files disagree, say so in the line of what could not be found. Either way the plan marks the finished steps ✓. Then show the user the plan for this run — its steps by number with a 🛑 on each one that stops for the user, then one line of what this step found and one of what it could not find, labelled in the user's language — and wait for the user's go-ahead, or take the dispatch as the go-ahead when this run was sent to work without the user, as a sub-agent; name each later step by its number as it starts.
2. Find what the course owes upward — the programme outcomes, the curriculum map naming which of them this course is responsible for, and which revision of the programme is in force for the cohort being taught. Where a course is taught to two cohorts under two revisions, it owes both, separately. Name every one of these that is missing rather than inferring it: outcomes written without the map are the course's own invention, and they will not survive the first programme review.
3. Read the course as it is defined — the official course description, its credits, its contact hours per session, the number of sessions, and any assessment the institution fixes centrally. These are the constraints the design has to fit; take them from the documents rather than estimating.
4. Settle the outcomes, and check them before anything rests on them — draft candidate outcomes, or collect the ones that already exist, then run every check in the learning-outcomes skill: the four ways a verb fails, the level each verb holds against the curriculum map, the count, and the mapping in both directions. This step is a grill point: run the grill-point skill, and build nothing on a decision the grill has not settled. The check results supply its questions — every failure and every proposed exception is one of them, because a compound outcome cannot be repaired downstream, only split, and splitting it after the marks are allocated means reallocating them. Every outcome the grill changes is checked again before its row is written. The step is done when the check table — one row per outcome, in the shape that skill gives, every row describing the outcome as it now stands — is written into the outcomes file, with the project standards found in step 1 named above it. An outcome inherited from an approved syllabus that fails a check is reported with what it would have to become, since changing it may need approval this skill cannot give.
5. Settle how each outcome is evidenced, before the schedule exists — This step is a grill point: run the grill-point skill, and build nothing on a decision the grill has not settled. For each outcome, the assessment that elicits its own verb, in a format whose level it can reach, and its share of the marks. Deciding this after the timetable is what produces a course assessed by whatever fits in the weeks that were left over. The grill's line goes into the assessment plan when step 8 writes it.
6. Settle the teaching plan — This step is a grill point: run the grill-point skill, and build nothing on a decision the grill has not settled. Session by session: the topic, the outcome it serves, and the activity through which learners actually perform that outcome's verb — an activity this course's room, equipment, and learners can actually carry. Every outcome gets sessions; every session names its outcome, or is marked explicitly as serving none. A session serving no outcome is not automatically wrong — an orientation or a review is legitimate — but it is stated rather than left to be noticed later. The grill's line goes into the teaching plan when step 8 writes it.
7. Reconcile the alignment table — one row per outcome: outcome, teaching hours, activity, assessment, marks, programme outcome. Then apply the three rules in the learning-outcomes skill: the verb is the same all along each row, every block of marks has an outcome that owns it, and no high-level outcome carries trivial weight. This table is what the assessment work reads afterwards, and what an institution's own form is filled from.
8. Write the artifacts — the outcomes, the assessment plan, and the teaching plan, in the project's templates where it has them and in the project's language. Record which programme revision the outcomes map to, and the date the mapping was checked, since a curriculum map goes out of date without the course changing at all.
9. Verify before finishing — run the project's check script where one exists, then confirm: the outcomes file holds the step 4 check table with a row for every outcome and a result of pass, fail, or exception in each; every exception has its record; every outcome that failed a step 4 check was a question at its grill point, and its row records the answer; every assessment below its outcome's level names its decision record; the outcomes, the assessment plan, and the teaching plan each carry the line their grill wrote; every outcome maps to a programme outcome and every programme outcome the course is assigned is reached; every outcome has teaching hours, an assessment whose format reaches its level, and a share of the marks; every session names its outcome or is marked as serving none; the marks sum to the course total; and no row of the alignment table changes its verb along the way. Last, delete this skill's handoff and its grill log, GRILL-LOG-<skill>.md, from the run's folder, once anything still open in them is written into the run's own files: a handoff left behind makes the next run on this folder resume one that is finished, and a grill log left behind is a second copy of answers that drifts from the artifact, against which the next run would check its drafts.