Plan — the technical blueprint between spec and tasks

The spec says what and why. plan decides how: the components, the contracts between them, the data that flows, how each claim gets proven, and what is most likely to bite. It reads the clarified spec and the constitution, writes ONE artifact — 02-DOCS/wiki/sdd/plans/<slug>.md — and hands off to tasks, which slices it into an ordered, independently-verifiable checklist.

constitution → specify → clarify → [ plan ] → tasks → analyze → implement → verify → review → ship

Decide structure, not syntax

A plan names components, contracts, shapes and flows. It does not write the framework's route decorators, the ORM's session boilerplate or the test runner's flags — those are stack mechanics, owned by the stack skill (../fastapi/SKILL.md, ../nextjs/SKILL.md, ../go/SKILL.md, ../flutter/SKILL.md, ../postgresdb/SKILL.md) at implement time. This altitude is what makes a plan reviewable against intent and slice-able by tasks; drop it and you get code no one approved.