← ClaudeAtlas

planlisted

Turn a framed problem into an implementation approach (stack/architecture as ADRs), a feature breakdown, and GitHub issues plus a milestone. Use to decide the stack, break work into issues, or scope a milestone after `ideate`. Not for framing the problem (`ideate`) or implementing it (`codify`).
jwogrady/spark · ★ 0 · Code & Development · score 66
Install: claude install-skill jwogrady/spark
# plan — Stage 2 of the Spark lifecycle `Ideate → Plan → Codify → Validate → Ship` Plan converts a confirmed problem statement into a milestone `codify` can execute. It reasons in a deliberate internal order — **model, then shape, then design** — so technology is chosen as an answer to the domain and the shaped outcome, never before them. The public lifecycle stays five stages; these are reasoning steps inside Plan, not new verbs. ## Do this 1. **Read the problem statement.** Look at `docs/problem-statement.md` first — that's where `ideate` persists it. If it's not there and the user hasn't pointed at one, run [`ideate`](../ideate/SKILL.md) first. 2. **Model the domain — enough to name what is load-bearing.** Identify the concepts, roles, relationships, lifecycles, invariants, and ownership boundaries the implementation must satisfy ("a Zone exists independently of a VM"; "the serial must never regress"). Small projects may record "no deeper model needed" and move on — never force ceremony. Persist material invariants where later work will cite them (the problem statement, or the Context of the ADRs step 4 produces): later steps must be able to point at an invariant as the reason for a decision. 3. **Shape the milestone and its issues.** A milestone is a coherent working state good enough to ship, named by its observable outcome ("authoritative DNS survives one nameserver failing"), not a ticket bucket. Derive issues from the capabiliti