
Plan
- 78 installs
- 1 repo stars
- Updated August 3, 2026
- davidlee/doctrine
Turns a locked slice design into an executable phase plan, authoring plan.toml and plan.md and materializing the runtime phase sheets.
About
Converts locked design intent into an executable phase plan, refining each phase's objective and entry/exit/verification criteria and re-grepping the design's premises against the current tree. A developer uses it once a slice's design is locked and it needs a phase plan.
- Refuses to substitute planning for unresolved design
- Re-greps design references against the current tree before scaffolding
Plan by the numbers
- 78 all-time installs (skills.sh)
- Ranked #1,460 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/davidlee/doctrine --skill planAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 78 |
|---|---|
| repo stars | ★ 1 |
| Last updated | August 3, 2026 |
| Repository | davidlee/doctrine ↗ |
What it does
Turns a locked slice design into an executable phase plan, authoring plan.toml and plan.md and materializing the runtime phase sheets.
Files
Plan
You are turning design intent into an executable phase plan.
Inputs:
slice-nnn.md(scope)design.md(canonical design reference)- existing
plan.toml/plan.md(when present)
Process
1. Read the slice scope and design.md together. 2. Confirm planning is not getting ahead of design:
- if
design.mdis missing or blank, stop and run/designunless you have
been explicitly instructed otherwise.
- if
design.mdexists but is stale relative to the current ask or slice
scope, reconcile the design first. Clarify with the user if ambiguous.
- you MUST NOT treat plan or phase creation as a substitute for unresolved
design.
- if planning surfaces substantive new design problems, run
/designto
revise or append to the design before continuing.
- re-grep before you trust the design's premises. The design was locked
at author-time; the tree has moved since. Scan design.md for concrete, grep-pable references — file paths, function/type names, constants, config keys — and resolve each against the current tree (grep, ls, git show). A missing path, moved file, or renamed symbol means the design rests on a stale premise: STOP and run /design to reconcile it before scaffolding phase sheets against wrong paths. (A design that names nothing concrete has nothing to check — this costs only what the design asserts.) 3. Scaffold the plan: doctrine slice plan <ID> writes plan.toml + plan.md (refuses to clobber existing files). The tool reads these but never rewrites them — hand-edit freely. 4. Author plan.toml — one [[phase]] per ordered phase:
idisPHASE-NN(zero-padded), immutable and never reused — edits
append, they never renumber.
nameandobjectivefor the phase.entrance_criteria(EN-n),exit_criteria(EX-n), andverification.
Verification ids carry their mode: VT-n verified by test, VA-n by agent, VH-n by human — use VA/VH when a test cannot judge the criterion, so it is still checked downstream rather than silently skipped. These ids are local to the phase and equally immutable.
- For each
VT-nrow, populate the structured mandate so the S3 gate can
check it: test_file (path that must exist) + keywords (raw substrings that must appear in it). doctrine slice verify-vt <id> gates every VT carrying a mandate; one lacking it renders UNCHECKABLE (visible, non-halting) at the dispatch handover. Optional patterns are line-anchored regex for a stronger language-agnostic shape assertion. Matching is raw substring — no host-language comment/string stripping (POL-002).
specs/requirementsstay empty in v1 (no registry yet). When a slice
does carry relations, they are written with doctrine link (not typed keys here) — see using-doctrine.md § Relating entities. 5. Author plan.md — the rationale and sequencing prose: why these phases, in this order, with these boundaries. Honour the storage rule: no queried or derived data in `plan.md`; the structured criteria live in plan.toml, and runtime progress lives under .doctrine/state/, never here. 6. Commit. 7. Consider plan critically: what's under-specified, assumed, ambiguous, oversized, optimistic, requires verification, or presents implementation risk? For each of these, decide what new information is needed, or what mitigations to put in place. Ground the plan in known details of the implementation. 8. Plan the revision; print a summary of it for the user. Then work through it. 9. Revise the plan; commit again. Summarise what changed. 10. Materialise phase tracking: doctrine slice phases <ID> creates the per-phase sheets in the state tree from plan.toml. --prune removes orphan tracking whose plan phase is gone (destructive — only when you meant to drop a phase). 11. Hand off to /phase-plan to expand the next phase's runtime phase sheet just before execution — then /execute. Do this only after slice scope, design.md, and the plan tell the same story. Record the lifecycle move on handoff: doctrine slice status <id> ready (bare number).
Outcomes
plan.tomlis execution-ready: every phase has an objective and EN/EX
criteria plus verification in an explicit mode (VT/VA/VH).
plan.mdexplains the rationale and sequencing.- A runtime phase sheet exists per phase with clear done criteria.
- If plan complexity or policy ambiguity emerges, STOP and
/consult.