in progress

Implementation plan

Phase checkpoints and a Decisions ledger for plan specs

feature· high effort· 12 steps· 2026-07-30· agentics

The goal

Long plans have to be implemented in one sitting, because nothing marks a safe stopping point and nothing records the decisions an earlier session already made. Phases add declared checkpoints and a ledger, so a plan can be picked up cold in a fresh context window.

In precise terms Add an optional ### Phase: <name> grouping over ## Steps and an optional ## Decisions section, and turn build's resume-from-first-unmarked-step behaviour into a designed checkpoint loop.

Context

Implementation plans that exceed roughly ten steps consume more context than one session can hold. The repo already reaches this conclusion — guidelines/right-sizing.md tells the author that a plan needing more than ten steps "is probably two plans — split it", then offers no mechanism to split with.

Two capabilities are missing, and only one is about parallelism. The workflow prompt already fans out across subagents, which helps when slices are independent. Context exhaustion bites hardest on long sequential plans, where step seven depends on decisions made in step two — and there, fan-out does nothing. The fix for that shape is checkpointing.

One hazard is already latent. parseSpecMarkdown folds each step to a single line, so a ### Phase: heading placed between steps two and three is appended to step two's Verify text with no parse error at all. Phases are unsafe to author until step 1 lands.

Steps

01Spec format 3 of 3 done

✓

Make parseSpecMarkdown phase-aware by splitting the Steps chunk on ^###\s+Phase: before the numbered-item split.

Why
The current splitter folds a heading between two steps into the preceding step's Verify: text with no error raised.
Verify
Parse a two-phase fixture; both phase names come back in order and no step's verify string contains a #.

✓

Emit phases from buildDigest as a ### Phase: <name> line above the first step of each phase, keeping flat numbering unchanged.

Why
buildDigest is the exact inverse of parseSpecMarkdown, so a phase it does not emit disappears whenever a spec is reconstructed from HTML.
Verify
parseSpecMarkdown(buildDigest(parsed)).phases is deep-equal to parsed.phases.

✓

Read phases back out of rendered HTML in extractSections by matching data-phase, and extend stripHeading to remove the phase <h3>.

Why
An unstripped <h3> would leak the phase name into the first step's extracted action text.
Verify
Phase names come back in document order with no step action containing a phase name.
02Renderer in progress

✓

Add a phaseHeader helper emitting <div class="phase-group" data-phase="…">, and group step cards under it in flat document order.

Why
The progress JavaScript counts .step-card with querySelectorAll, so nesting that breaks the selector would silently zero the progress bar.
Verify
Progress total equals the step count, each phase heading precedes its own steps, no heading level skipped.

05

Add the ## Decisions section end to end — parse, re-emit, extract, add a SECTION_CHROME key, and render it after Context.

Why
A resumed session that cannot see settled choices re-litigates them, and ## Completion Report records gaps rather than decisions.
Verify
Three Decisions bullets render a card, gain a nav entry, and survive the parse-digest-parse round trip.

06

Re-copy the three edited renderer sources over their counterparts under kit/plugins/plan-agent/scripts/, after steps 1–5 and before any test run.

Why
A test asserts the bundled copies are byte-identical to the repo-root sources, so editing one side ships a phase-blind renderer.
Verify
diff reports no differences for all three files.
03Skills & ship 6 steps

07

Rewrite Step 2 of skills/build/SKILL.md as a phase checkpoint loop, with a --continue flag that pushes straight through.

Why
Bounding context is the objective, and stopping is correct by default because the skill's headless contract already stops and reports rather than choosing.
Verify
Grep for --continue and the resume line; the unphased path still reads as one uninterrupted walk.

08

Add the phase boundary offer — compact and continue, stop here, or continue without compacting — printing the /compact command with focus instructions.

Why
/compact is a user-typed CLI built-in rather than a callable tool, so the skill can only recommend it.
Verify
All three options and the printed /compact line appear; the headless path reports rather than chooses.

09

Teach skills/finalize-plan/SKILL.md about phases so it refuses to set status: completed while any phase still holds unmarked steps.

Why
build/SKILL.md line 303 requires the two skills' completion rules to stay consistent, so a phase-blind finalize-plan would close out a plan that stopped at its first checkpoint.
Verify
A phased spec with phase two unmarked stays in-progress with the unfinished phase named in the report.

10

Document both sections in guidelines/section-catalog.md and replace the "probably two plans — split it" sentence in guidelines/right-sizing.md with a phase profile.

Why
Right-sizing currently sends the author to a mechanism that does not exist, which is the specific gap this plan closes.
Verify
The old sentence is gone and both guideline files show a ### Phase: example.

11

Extend the two existing test files with phase and Decisions cases, and add tests/plugins/test-plan-phases.mjs asserting the render-extract-re-render cycle preserves both.

Why
The render-extract-render pair catches a format change applied to one side and missed on the other; the prose-contract grep follows the pattern in test-exitplanmode-guard.sh.
Verify
All three test files exit 0.

12

Bump plan-agent from 7.0.1 to 7.1.0 in .claude-plugin/marketplace.json and add the matching CHANGELOG entry.

Why
Repo convention requires any change under kit/plugins/ to ship a version exceeding the value on main, and a new spec section is a minor bump.
Verify
BASE_REF=main node scripts/check-plugin-versions.mjs exits 0.

Decisions

Settled choices a resumed session must not re-litigate.

  • Phase boundaries are ### Phase: headings rather than a phases: frontmatter range list — headings survive step insertion and reordering, which range lists do not.
  • build stops at a phase boundary by default and takes --continue to push through, matching the skill's existing headless contract.
  • Compaction is safe mid-plan only because durable state lives in the spec — step markers, status:, and the ledger — so a lossy summary costs nothing the next phase needs.
  • Phases are pure grouping over the same flat numbering, so adding them to an in-progress plan keeps every existing [x] marker valid.
  • Parent and child plan files are out of scope; phase boundaries are shaped so they can be extracted into child files later.

Files that change

  • scripts/lib/plan-spec.mjs mod phase-aware splitting, Decisions parsing, digest re-emission
  • scripts/build-plan-html.mjs mod group step cards by phase
  • scripts/lib/plan-shell.mjs mod phase header helper, chrome entry, phase CSS
  • tests/plugins/test-plan-phases.mjs new objective-verification smoke test
  • .claude-plugin/marketplace.json mod plan-agent 7.0.1 → 7.1.0

Definition of done

Acceptance criteria3 / 15