Check Plan

Check one plan folder against the thread's spec and correct it in place, end to end. You gather the thread's context, walk the plan task by task against the spec, fix every fault whose fix follows from it, hand what it does not settle to a pending-decision bundle, and report what you changed. You work from the gathered inputs alone, without walking the user fault-by-fault. Editing the plan folder is where you stop — do not stage, commit, or push.

Inputs

Gather all of these before checking; everything below works from what you gather here.

• The project's AGENTS.md, when the file exists — the project's standing guidance for agents working in it.
• docs/glossary.md, when the file exists — the project's fixed terms, to be used in everything you write.
• docs/adr/ and docs/pdr/, read via /consult-decisions — the project decisions bearing on the plan.
• The roadmap entry named by the seed frontmatter's roadmap mapping, when the seed carries one — the entry this thread answers: its sketch, its scope boundary and its planned behavior, found as the heading whose text is roadmap.entry in the index at roadmap.path.
• The thread's spec.md — the spec, the sole authority for every correction you make; it comes in the shape <skill_path>/references/formats/spec.md defines. A fault is a fault only because the spec says so, and a fix is available only because the spec settles it. Required: the check does not run on a thread that holds no spec.md.
• The plan folder to check — the edit target, in one of two accepted forms. When the invocation names a folder under plans/, that folder is the form. Otherwise the form is the newest folder under plans/ by stamp. Read everything in it: its index plan.md, and the task briefs under plan-tasks/ when the plan is strict.
• The thread's delta/, when present — the thread's delta of the project layer, which inside the thread takes precedence over the project records; these are the documents the spec cites, by path for a delta document and by stem for a decision record, in the forms <skill_path>/references/instructions/read-and-cite-the-project-layer.md fixes.

Any other thread is history: it records how its own work was understood at the time, not what holds now, so do not read it unless the user or this thread's seed names it.

If the thread holds no spec.md, or the plan folder does not resolve — plans/ is absent or empty, or the invocation names a folder that is not there — that is a preflight failure, not an in-run decision: refuse before editing anything, write nothing, and follow <skill_path>/references/instructions/emit-terminal-outcome.md with REFUSED, naming what is missing and how to supply it.