make-practical — build a practical exam set

This skill is an ordered checklist: each step opens when the one before it has produced its result. It is the sibling of make-exam, not a mode of it — a practical is a different chain. There is no item bank of stems and options, no answer key of distractor rationales, and the scoring instrument is the centre of the design rather than a late step. What replaces them is conditions, markers, and a standard.

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.

The folder shape and what the file numbers mean are in the assessment-layout skill; what makes an outcome assessable is in the learning-outcomes skill; what a defective task looks like is in the item-defects skill; how a practical is built is in PRACTICAL-REFERENCE.md — read it before step 5.

Steps

1. Discover the project's conventions — read the host project's agent instructions file (AGENTS.md, or CLAUDE.md) and inspect an existing exam set: folder layout, file naming, available templates, and whether the project carries its own assessment reference. A project's own assessment rules override PRACTICAL-REFERENCE.md and the item-defects skill; its templates override the document shapes below. The institution's constraints on rooms, equipment, marker availability, and sitting times are part of this step, because they decide what design is possible at all. 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. Open the exam set folder — one folder per examination, in the place and under the name the assessment-layout skill gives, unless the vault's own rule says otherwise.
3. Read the course definition, and check the outcomes before building on them — the syllabus or its digest supplies the outcomes, the grade weighting, and the teaching hours; the teaching plan supplies what learners have actually had the chance to practise; the programme outcomes supply what the course owes upward. Then check each outcome against the learning-outcomes skill, over the whole set rather than one outcome at a time. Where an outcome fails any of those checks, stop and put it to the user, then ask whose outcome it is: where the user owns it, it is fixed before any task is designed; where it belongs to an approved syllabus or to another person, report what it would have to become, get the user's acknowledgement to proceed on it as it stands, and record the limitation in the alignment matrix as an open item. A practical is the only instrument that can evidence a create or perform outcome, so an outcome that is compound — one half performable, the other not — splits the examination in two before a single task is written.
4. Research the performance itself — what a competent person actually does, what distinguishes competent from not, and the errors real learners make. Record it in 00-research.md with sources. This is the largest step in a practical and the one most often skipped: a written paper can lean on the course material, but a task, its conditions, and the standard it is scored against all have to come from what the performance is really like.
5. Settle and write the alignment matrix (01-blueprint.md) — This step is a grill point: run the grill-point skill, and build nothing on a decision the grill has not settled. One row per task: what the examinee does, what is observed, the criteria, the outcome it serves, the marks, and the time. This is the practical's blueprint, and it reaches upward: each row names the outcome and, where the project tracks them, the programme outcome behind it. Total marks reconcile with the course's grade weighting, and the whole examination fits the sitting time with the changeovers counted.
6. Design the tasks and state their conditions (03-paper.md, the examinee-facing copy) — one competence per task. Equipment, time limit, permitted references and tools, permitted assistance, and safety constraints are written into the task itself, not left as logistics: the same task under different conditions measures something different. Name every dependency on infrastructure and give it a fallback that earns the same marks. Where the examination runs in more than one sitting, alternate the content between sittings. Where the examinee-facing copy leaves as a Word, PowerPoint, or Excel file carrying Thai text, it is written once that file passes the rendered check in the thai-office-files skill, or that check is recorded as not run the way the skill describes.
7. Build the scoring instrument (05-rubric.md) — a checklist for procedure with a fixed order, a rating scale for judgement, both where a task has both halves; the choice is made per task, from the table in PRACTICAL-REFERENCE.md. Criteria are observable, adjacent levels differ by something a marker can point at, weights sum to the task's marks, with every score traceable to a described level or a stated rule and a rating scale called one, its points anchored; and the examinee's copy shows how each criterion's marks are reached. Write the critical-error rule into the instrument where a safety violation or a critical error voids the attempt.
8. Settle the pass standard — This step is a grill point: run the grill-point skill, and build nothing on a decision the grill has not settled. The standard is set before the examination and by a stated method, from what a candidate who only just meets the standard should be able to do, and recorded in the instrument.
9. Measure the design, and write the table down — before the marker's copy is written, record in the exam set as the next free authoring file (default 06-measurements.md): minutes per mark for every task, marks per outcome, the proportion of marks scored objectively against the proportion needing judgement, the number of independent tasks, and — where alternate forms exist — the result of working each form yourself under exam conditions. Count rather than estimate. Then read the counts against PRACTICAL-DEFECTS.md and COMMON-DEFECTS.md in the item-defects skill, and fix what they find. Report a count for every group including the groups that found nothing: a step that produces no table did not run.
10. Write the marker's copy (04-answer-key.md) — what the marker sets up, what they say, what they observe and score, what counts as a defensible response outside the expected set, and how the attempt is handled when a dependency fails. Include the calibration plan: which shared samples the marking team scores independently before marking starts, which work is double-marked, and where the agreement is recorded. A practical's marks live or die on marker consistency, and nothing else in the set defends it.
11. Verify before finishing, and record what has not happened yet — run the project's check script where one exists, then confirm: every outcome passed the step 3 checks, or was raised with the user and recorded as an open item; the alignment matrix and the pass standard each carry the line their grill wrote, and every task below its outcome's level names its decision record; every task traces to an outcome and every outcome the examination claims has at least one task; marks total to the course's grade weighting; the measurement table is in the exam set and every group reports a count including the empty ones; every task states its conditions; every task has a scoring instrument whose weights sum to its marks; the pass standard was set before the examination; and the marker's copy covers setup, scoring, and the calibration plan. Then close the set by writing into it that this skill produces an exam set and not a cleared one: the binding review runs at the stage the assessment-layout skill numbers 1x, and it is a separate pass by design, because a check run by whoever designed the tasks, in the session that designed them, is the weakest form of the check. Record it as an unticked item in the exam set's own closing check. A review passed on only as a sentence in the session is a step that leaves no evidence, which is the failure every other check in this skill is written to avoid. 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.