Implementation Planning

Adapted from obra/superpowers at commit b36e0829c6d0140e93cfef2ca599b1b07d4a7797 (MIT). Verifiable-unit sequencing and migration cleanup are adapted from Cursor's poteto-mode at commit 93b00b89ef425a9c1bac0d0b317dfc49c930ac99 (MIT, Copyright (c) 2026 Cursor). Tracer-bullet slicing and the wide-refactor expand–contract exception are adapted from Matt Pocock's to-tickets at commit 3cca18b368ae95cdbdebbff572ccafa662551015 (MIT, Copyright (c) 2026 Matt Pocock).

Write for an implementer with no conversational context. Specifications own behavior; this plan owns only execution decomposition, per the scoped authority in planning-contract (Contract version: 1). The plan is a compact execution map, not a rewritten specification. If that contract skill is not installed, stop and request installing planning-contract rather than planning on inherited or invented rules; never assume automatic dependency resolution.

Artifact policy

• For one bounded change under one owner, skip a plan file and pass the approved in-chat design directly to orchestrate-implementation; the capture-checkpoint outcome still applies proportionately.
• For architectural or multi-step work, write the smallest plan that exposes dependencies, ownership, integration order, and verification.
• Split independent subsystems into separate plans instead of producing one huge plan.
• When a plan file is needed, use the planning-contract filename convention YYYY-MM-DD-NNNN-slug.md. Reuse the source specification's exact prefix for its plan; otherwise allocate the next number from the shared sequence across the project's specs and plans directories (project/specs/ and project/plans/; legacy docs/specs/ and docs/plans/).
• Create tracker tickets only when the user asks for them, an established tracker requires them, or coordination must outlive the current run. Publish each task as a ticket; tickets own the canonical task bodies, and a thin overview may link to them, but never maintain duplicate editable task definitions.

ADRs explain why, specifications define what, and plans or tickets define the executable next units.

Lean assurance default

Plan the smallest evidence set that establishes the acceptance criteria and addresses concrete material risks. Do not add a test, validation command, reviewer, or review boundary unless it covers a distinct reachable failure mode; if that failure cannot be named, omit the assurance work.