planlisted

# flow:plan — Authoring plan.md and tasks.md A flow plan is **a short, visual one-pager that explains the approach, not the code**. The reader should finish in about a minute and know what is going to be built and how — mostly from a diagram. ## Operating philosophy — lightweight, visual, fast iteration The point of planning is to start implementing sooner with a clear direction, **not** to specify everything up front. Heavy plans (the GSD/over-planning failure mode) make everyone lose the goal, over-invest in detail, and burn out before any real output appears. - **Bias to brevity.** Write the *least* plan that conveys goal, direction, and scope. If a section is not earning its length, cut it. - **Diagram over prose.** A Mermaid diagram of the flow/shape communicates direction faster than paragraphs. Reach for one before writing long prose (see `../../references/mermaid.md`). - **Iterate fast.** plan → implement → review → fix, repeated, beats one big plan. Get something reviewable in front of the user quickly; refine on the next loop. - The size ceilings below are **ceilings, not targets** — most plans should land well under them. ## Lock the goal, spec, and user flow before you plan Brevity does **not** mean skipping the goal. The single most expensive failure mode is a plan that starts from an ambiguous goal: scope corrections then arrive piecemeal *after* implementation has begun ("actually mobile is out", "it must match prod pixel-for-pixel", "that field shouldn't