Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
davidlee avatar

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 plan

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs78
repo stars1
Last updatedAugust 3, 2026
Repositorydavidlee/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

SKILL.mdMarkdownGitHub ↗

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.md is missing or blank, stop and run /design unless you have

been explicitly instructed otherwise.

  • if design.md exists 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 /design to

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:

  • id is PHASE-NN (zero-padded), immutable and never reused — edits

append, they never renumber.

  • name and objective for the phase.
  • entrance_criteria (EN-n), exit_criteria (EX-n), and verification.

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-n row, 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 / requirements stay 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.toml is execution-ready: every phase has an objective and EN/EX

criteria plus verification in an explicit mode (VT/VA/VH).

  • plan.md explains 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.

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.