Plan Strict

Forward-design a strict-granularity plan for the active thread. You gather the thread's context, draft an index plus one dispatchable brief per task — each brief carrying explicit substeps, files modified, verification, and acceptance criteria — self-review before emission, create this invocation's plan folder, write the index and the task briefs into it, then confirm the path. Run end-to-end without walking the user task-by-task. Writing the files is where you stop.

Inputs

Gather all of these before drafting; 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 design.
• 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 design the plan implements — the primary input, in one of two accepted forms. The thread's spec.md is the form when the file exists, and it is the plan's authority: its goal, its account of the change, and its constraints drive the task list directly, its acceptance checklist maps onto per-task acceptance criteria, and its degrees-of-freedom section tells the plan which hows are open. It comes in the shape <skill_path>/references/formats/spec.md defines. When the invocation names a referenced artifact instead — a repository path, a GitHub issue (a full https://github.com/<owner>/<repo>/issues/<NNN> URL or the short owner/repo#NNN form), or the user's own prompt when nothing else is named — that reference is the form; it is material, and it carries no authority over a spec.md the thread holds.
• The thread's seed.md — why the thread exists and what triggered it.
• The thread's delta/, when present — the thread's delta of the project layer, which inside the thread takes precedence over the project records. Where a task rests on one, it cites a delta document by its path and a decision record by its stem, rather than restating it; the form each kind is cited by is the one <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.

The emitted plan must be self-contained: a fresh implementer with only the plan and the thread's durable inputs can execute it, with no dependency on the originating chat.