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).

Write for an implementer with no conversational context. The specification remains authoritative; the plan is a compact execution map, not a rewritten specification.

Artifact policy

• For one bounded change under one owner, skip a plan file and pass the approved in-chat design directly to orchestrate-implementation.
• 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.
• 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 and treat that ticket set as the plan; do not maintain a duplicate full plan.

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

Preflight