mcpField
P
phase-plan

phase-plan

github.com/davidleeDevelopment2142 installsUpdated 4d ago
Repository

About phase-plan

phase-plan is a development skill for turning one authored phase into an executable task breakdown immediately before work begins. It grounds tasks and verification in the design, phase criteria, research, and relevant project memory.

Key features

  1. 01Checks phase entrance criteria
  2. 02Reviews design and phase objectives
  3. 03Retrieves subsystem-specific guidance
  4. 04Defines tasks, files, and verification

Use cases

  1. 01Preparing the next phase for execution
  2. 02Mapping verification to exit criteria
  3. 03Planning work after refreshing research

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/davidlee/doctrine --skill phase-plan

After installing, type/phase-planin Claude Code to confirm it loaded.

Details

From the project README

Phase Plan

You are expanding one authored phase into its runtime phase sheet, immediately before executing it. The authored plan (plan.toml) says what the phase must achieve; this skill works out how, in the disposable state tree.

Plan each phase in detail just prior to execution — not all phases up front.

Inputs:

  • the phase's plan.toml entry — its objective, exit_criteria (EX-), and verification (VT-/VA-/VH-)
  • design.md (canonical design reference) and slice-nnn.md (scope)
  • the materialised runtime phase sheet state/.../phases/phase-NN.{toml,md}

Process

  1. Confirm the phase's entrance_criteria (EN-) are met before planning the detail. If they are not, resolve that first (an earlier phase, a design gap).
  2. Re-read design.md and the phase's plan.toml entry — objective, exit criteria, verification expectations.
  3. Run /retrieve-memory against the concrete files and subsystems you expect to touch, so scope-bound gotchas and patterns surface before you commit to a task breakdown.
  4. Check the research advisory — doctrine slice research <id>. Where it reports drift, refresh only the affected thread sections, then re-stamp the baseline; plan the phase against the refreshed artefact, not the stale one.
  5. Fill the runtime phase sheet phase-NN.md (under .doctrine/state/, GITIGNORED and disposable) with:
    • a concrete task breakdown — small, coherent units of work
    • assumptions and constraints carried into execution
    • the verification steps that will satisfy each VT-/VA-/VH- expectation
    • the files / components each task is expected to touch
  6. This is runtime state (lib:reference/using-doctrine.md § Storage tiers) — never write task detail or progress back into the authored plan.toml / plan.md.
  7. If detailing the phase surfaces new design problems, unresolved tradeoffs, or policy ambiguity, stop — /consult, or return to /design if the design itself is the gap. Do not invent your way past it.
  8. When the sheet tells a coherent story, flip the phase to in_progress with doctrine slice phase (see lib:reference/using-doctrine.md), then /execute.

Outcomes

  • The phase has a concrete, executable task breakdown grounded in the design.
  • Verification steps map to the phase's VT- criteria.
  • Authored plan and runtime state stay on their correct sides of the storage rule.

Comments

Markdown supported