-
Re-read CLAUDE.md and DESIGN.md fresh. For prior-milestone detail, the single log is
MILESTONES.md (CLAUDE.md's "## Completed milestones" carries only a one-line index); the forward
roadmap is DESIGN.md §15 and deferred/remaining decisions are DESIGN.md §14.
-
Confirm this milestone's scope against DESIGN.md §15 (roadmap) and §14 (decisions remaining), and
CLAUDE.md's "out of scope for now" list; confirm it isn't already done per the MILESTONES.md
log; flag if the user's details conflict with any of these.
-
Propose a concrete plan: files to create/modify (name the R wrappers, C++ cores, tests, and docs),
the order of implementation, and testable acceptance criteria in the same style as M1's (see
MILESTONES.md).
-
For any milestone touching a C++ core, the plan must include: a Rcpp::compileAttributes()
regeneration step, a numerical-regression test vs. a reference implementation on sim_dyad
(Invariant 5), and — for efficiency work — a bench/ before/after timing step with a measured
target.
-
Flag any design ambiguity the brief doesn't resolve — do not invent a resolution; if it's a design
decision, it belongs in DESIGN.md, so ask.
-
Do not write any code. This is planning only; implementation happens via /implement-milestone
afterward.
-
Once the user explicitly approves the plan (branch → PR workflow; milestone work never lands
directly on main):
a. Create the milestone's feature branch off an up-to-date main
(e.g. git switch main && git pull && git switch -c m$ARGUMENTS-<short-slug>). All milestone
work — the planning commit and implementation — lands on this branch; main is updated only
by merging a reviewed PR once CI is green (see /implement-milestone).
b. On the branch, update CLAUDE.md's "## Current focus" section to make Milestone $ARGUMENTS active
(with its acceptance criteria), and commit that change on its own (not bundled with any
implementation commit). Commit locally only — do not push the branch or open the PR until
the user asks (respects CLAUDE.md's "push only when asked" cadence).
