plan-strict
Plan Strict
Forward-design a strict-granularity plan in its lineage folder under the active thread's plans/, end-to-end, from a single upstream input. Read the input, draft numbered tasks each carrying explicit substeps, files modified, verification, and acceptance criteria, self-review before emission, write the plan, and confirm its path. By default, run end-to-end without walking the user task-by-task, but honor an invocation that asks you to check in or work through the plan interactively; do not commit.
The plan is a disposable compiler-IR: the spec plus its acceptance criteria are the contract a reviewer and the implementation are judged against, and the plan is downstream scaffolding compiled from that contract. This is why the plan is the one versioned-artifact type that carries no stored status latch and no version in its frontmatter — nothing about a plan needs auditing, because the spec it compiles is the audited artifact. It is also why the human may review the implementation but never needs to read the plan: when the spec carries machine-checkable acceptance criteria and a Degrees-of-freedom section, this autonomous mode can produce the plan and a downstream machine adherence review can clear it without the human reading it. See ## Plan Has No Frontmatter.
Inputs
Accept ONE of the following five input forms. Detect which form was passed before drafting:
- A spec artifact path — a spec document on disk, typically
specs/NNN[-<desc>]/spec.mdin the active thread. The spec is the most common upstream input — its semantic-contract elements (intended outcome, expected behavior, constraints, acceptance guidance) drive the plan's task list directly, its acceptance criteria map cleanly onto per-task acceptance criteria, and its Degrees-of-freedom section tells the plan which hows are open. Before drafting from a spec, confirm the spec is approved (its frontmatterstatus:map carries anapprovedlatch); planning from a Draft spec is allowed but flag that the contract is not yet signed. - A proposal artifact path — a proposal document on disk, typically
proposals/NNN[-<desc>]/proposal.mdin the active thread. When the input is a proposal rather than a spec, the plan tasks elaborate the proposal's rough shape into an implementable sequence; treat the proposal's open questions as items the plan either resolves or carries forward. Strict-granularity from a proposal is heavier weight than from a spec — if the proposal is thin, a loose-granularity plan may be a better fit. - A decision-log artifact path — a record carrying one or more settled decisions with sequential
## P<N>: <Title>headings. Each settled decision may map to a task (or constrain one) — cite the source log by path +P<N>where the decision is operative in the relevant task's input/context field (same-thread references thread-relative, e.g.discussions/<UTC>-<slug>-decision-log.md P3; cross-thread references repo-relative,docs/threads/<other>/…). - A GitHub issue URL or identifier. Accepted forms include a full URL (
https://github.com/<owner>/<repo>/issues/<NNN>) or the shortowner/repo#NNNform. The issue body becomes the upstream input; treat the issue title and labels as additional context. - A raw user prompt. When no artifact is referenced, the user's prompt is itself the input — the plan is forward-designed directly from it.
If the input is ambiguous — multiple plausible spec lineages could be meant (specs/001-api/ vs specs/002-cli/), multiple decision logs cover overlapping topics, the issue identifier is incomplete, the prompt references "the spec" with no clear referent — ASK the user which artifact is intended. There is no "highest number" or "most recent" fallback; do not silently pick by recency or by NNN.