| name | sdlc-plan |
| description | Phase 2 of the SDLC. Use this to decide HOW a specified feature will be built — architecture, tech choices, data model, API contracts, and trade-offs. Triggers after a spec exists and the user wants a technical plan or design decisions. Produces specs/<feature>/plan.md plus Architecture Decision Records (ADRs). Must read spec.md and memory/constitution.md and respect their constraints. |
Phase 2 — Plan (HOW)
Translate the spec into a technical approach that obeys the constitution.
Preconditions
specs/<feature>/spec.md exists. If not, route to /specify.
Process
- Read
spec.md and memory/constitution.md. List the constraints they impose.
- Recall prior architecture decisions via
memory-manager for consistency.
- For every significant choice (datastore, framework, boundary, protocol), record an ADR
from
templates/adr.template.md in specs/<feature>/adr/. ADR prose in Ukrainian.
- Write
specs/<feature>/plan.md from templates/plan.template.md:
- architecture overview + component boundaries,
- data model / contracts,
- dependencies & versions,
- risks and mitigations,
- test strategy (aligned with constitution's TDD rule).
Discipline
- Invoke
superpowers-core brainstorming before committing to an approach — generate 2–3
options and justify the pick. Single-option plans are a red flag.
- For large/unfamiliar codebases, you may invoke
code-graph to map dependencies first.
Exit
Update .sdlc/state.json (phase=plan). Persist memory checkpoint. Say: "Plan + ADRs ready. Next: /tasks."
Примітка (UK)
План перетворює специфікацію на технічний підхід. Кожне суттєве рішення фіксуємо як ADR
українською мовою, щоб згодом було зрозуміло, ЧОМУ обрали саме так.
