adopt-pool — adopt a contributed pool into an exam set

Scope: a contributed pool — written items that someone outside the vault wrote and sent to be used, not yet held to the vault's standard and not yet drawn into a paper. Selected-response, constructed-response, and matching items all enter the same way; each keeps its own format through every step, and a constructed-response item reaches the paper with a rubric. A practical or performance examination belongs to the make-practical skill.

This skill is an ordered checklist: each step opens when the one before it has produced its result. The pool's author taught what the pool asks, and the vault's standard is applied to how it asks it: the run changes wording and selection, and leaves what each item tests to its author unless the user decides otherwise. 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 item looks like, format by format, is in the item-defects skill.

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, except that an approval of items is asked in the approval table the assessment-layout skill gives.

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.

Where the vault keeps a script for a count or a build this run needs, run it rather than writing another; a script written here is saved where the vault keeps its scripts, not in a session's scratch space, so the next run finds it. An item's text is changed where it lives, in the items file, rather than through a script that regenerates the file: such a script carries the paper's text a second time and is lost with the session.

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, the institution's cognitive-level scale, the item rules the project fixes, and the decision records that set the vault's house style. Ask the user which paper already set in the vault the wording should read like; its wording, with those records, is the house style for this run. A project's own assessment rules override the item-defects skill. 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 and keep the pool as received — one folder per exam, in the place and under the name the assessment-layout skill gives. Read the received file in its rendered form, since equations, figures, and marks carried by formatting live outside the text stream, then copy every item into 08-contributed.md word for word: numbered as its author numbered it, with its key, and any rubric, as given, under the path of the file it came from. This file is never edited after; it is what every later item is traced back to, and what a critique matches the paper against.
3. Read the course definition — the learning outcomes, the grade weighting, and the teaching plan or timetable, from the documents rather than estimated, naming any that are missing rather than inferring them. Check the outcomes against the learning-outcomes skill, then ask whose outcome it is. Where the user owns a failing outcome, it is fixed before the blueprint is drawn. 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 carry it into the blueprint as an open item. Note what the teaching plan shows was taught; it bounds every item step 6 writes. Where the course has no teaching plan, what the pool asks is the evidence of what was taught, and the user confirms anything step 6 writes beyond it.
4. Settle and write the blueprint (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. Its questions are the cells — counts, marks, formats, and the level each reaches — drawn from the outcomes' weights and the teaching plan before any contributed item is placed, because a table read off the pool certifies the pool's proportions rather than checking them, and cannot show the level it never reaches. The grill also settles the style budget step 7 rewords to, measured from the paper step 1 named: the median stem and option length in characters excluding spaces, and whether options carry explanations; it is written into the blueprint with the cells. Write it in the shape the assessment-layout skill gives, with the item format in every cell, and marks that total to the course's grade weighting.
5. Place the pool, and let the user select — tag every contributed item with the outcome it serves, the level it reaches as written, and the cell it falls in. This tagging is the inference a critique reports rather than makes, which is why it is made here and put to the user: the tags the user approves are the anchors the review later checks each item against. Then propose a selection that fills each cell to its count. An item that fits no cell — its outcome or level has none, or what it asks was not taught — is proposed for cutting with that reason. Where a cell holds more items than its count, the ones proposed for cutting are those whose level or outcome fits the cell least, each with its reason. A cell short of its count has a gap of the difference. Put the proposal to the user in the approval table, each row carrying its 08-contributed.md number, its cell, its level, and what the proposal rests on; what it was measured on is the item's option lengths in characters, or its length for an item without options. The user decides; an item the user keeps beyond a cell's count, or a gap the user leaves open, is recorded in the blueprint as a decision rather than reconciled away.
6. Fill the gaps (02-items.md) — for each gap the user left to be filled, write an item in the format its cell specifies, inside what step 3 found was taught: for a selected-response item the stem first, then the distractors, then the correct option; for a constructed-response item the task, then its criteria; for a matching item the premises, then the responses. Check each against the item-defects skill file for its format as it is written. Mark each as written by the vault rather than contributed. Show them to the user in the approval table before the next step.
7. Bring the wording to the house style (02-items.md) — each selected contributed item enters the items file reworded to the house style, carrying its 08-contributed.md number and whether its wording changed. The rewording keeps what the item tests and its keyed answer. An item whose repair would change either goes back to the user as a cut, and the gap it leaves returns to step 6. Count option lengths in characters, excluding spaces, against the style budget the blueprint records — a task without options against its stem length — and keep a key's length from standing out among its options. A style rule found here that should hold for every paper is a decision for the vault: put it to the user through the grill-point skill before it is applied. Show the reworded items beside their originals in the approval table.
8. Assemble the paper, the key, and the rubric (03-paper.md, 04-answer-key.md, 05-rubric.md) — the selected items in paper order; every item's key, the contributor's as given or the vault's for an item written at step 6; and for every constructed-response item a rubric with observable criteria whose weights sum to the item's marks, the contributor's where one came with the pool. A key that looks wrong is put to the user to confirm; it is never changed silently. Reconcile the blueprint against exactly the items the paper contains: marks per outcome, the level distribution, and the format of each cell. A printed paper sets out its options as the assessment-layout skill gives.
9. Verify before handing on to review — run the project's check script where one exists, then confirm: 08-contributed.md holds every received item unedited; the blueprint carries the line its grill wrote and the style budget, and its marks total to the course's grade weighting; every item in the paper traces to a contributed number or is marked written by the vault, and matches its cell's format; every reworded item records that it was reworded; every cell holds its count, or the blueprint records the user's decision that it does not; every item has a key, and every constructed-response item has rubric criteria. Then close the set by writing into it that this skill produces an adopted set and not a cleared one: the binding review runs on the assembled paper, at the stage the assessment-layout skill numbers 1x, and it is recorded as an unticked item in the exam set's own closing check, naming critique-mcq for the selected-response items and listing any other format as not yet reviewed. It runs in a new session rather than a sub-agent of this one, because its approval and applying would return to this run's context. End by telling the user, in their language, that the session can be closed and giving the line that starts that review on this folder in a new one. 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.