Roadmap Conventions

Overview

Cross-project conventions for where roadmaps and their nested docs live. Layered on top of superpowers:writing-roadmaps (authoring process), writing-prd (PRD content/format), and consumed by executing-roadmap-checkpoints (picking and finishing tasks from an existing roadmap).

Workflow Recipe

A roadmap-sized feature moves through three phases, each handled entirely by an existing skill — no separate orchestrator skill exists or is needed:

• Phase 1 — Roadmap: superpowers:writing-roadmaps as-is. Analyzes the feature, decomposes it into checkpoints (Core Principle: the app stays buildable after every step), writes the roadmap and the feature-level PRD.
• Phase 2 — Per-step PRD + spec, validated: batch-plan-validate over the roadmap's checklist, with the per-task drafting skill set to brainstorming, design-only (see batch-plan-validate → Input) — no implementation plan is produced yet. Result: for every step, a validated step-level PRD (writing-prd) and a validated design/spec (brainstorming), both reviewed through the standard EnterPlanMode → ExitPlanMode → Plannotator loop.
• Phase 3 — Implementation plan per step, just-in-time: executing-roadmap-checkpoints as-is, invoked when a step is actually picked up for work. It finds the step's approved PRD+spec and writes the implementation plan (superpowers:writing-plans) at that point — not earlier — so the plan reflects the repo state at the moment work starts, not whatever it looked like when the roadmap was first decomposed.

Do not write every step's implementation plan upfront in Phase 2 — that is what the design-only mode in Phase 2 exists to prevent.

Storage