Skip to content

plan-spec-implement.md

Latest commit

 

History

History
72 lines (46 loc) · 2.04 KB

plan-spec-implement.md

File metadata and controls

72 lines (46 loc) · 2.04 KB

Workflow: /plan -> /spec -> /implement

Why this flow exists

This repository's default delivery loop is built to prevent two common failures:

  • starting implementation before the requirements are clear
  • losing the thread halfway through because nothing concrete anchors the work

The flow solves that by making the planning artifact and the test anchors explicit.

Phase 1: /plan

Use /plan when the task is non-trivial or the requirements are still fuzzy.

Expected behavior:

  • read relevant code and docs first
  • ask clarifying questions when important details are ambiguous
  • converge on scope, constraints, and success conditions
  • write or update PLAN.md

PLAN.md should include:

  • problem
  • goals
  • non-goals
  • constraints
  • open questions
  • acceptance criteria
  • test plan
  • implementation steps

Phase 2: /spec

Use /spec after PLAN.md is stable.

Expected behavior:

  • read PLAN.md
  • map acceptance criteria to test cases
  • generate or update Vitest skeletons
  • keep the tests skeletal if implementation details are not ready yet

This is the point where planning turns into executable anchors.

Phase 3: /implement

Use /implement once the plan and test anchors exist.

Expected behavior:

  • read PLAN.md before changing code
  • identify the current unchecked step
  • implement against the relevant acceptance criteria
  • add or update tests as part of the same unit of work
  • update PLAN.md as steps are completed

If the plan exists but matching tests do not, the command should stop and ask whether /spec should run first.

Phase 4: /review and /verify

After implementation:

  • /review checks quality, risk, security, and maintainability
  • /verify runs tests, lint, and type-checks, then explains failures

Why this is better than free-form execution

The point of this flow is not bureaucracy. The point is continuity.

PLAN.md keeps the task coherent across long sessions. Acceptance criteria keep the work testable. /spec and /verify stop the implementation from drifting into a pile of half-finished ideas.