Design Phase Supported Flow Beats

Accepted Beat Path

1. Open with the gap: design-phase is a Supported Flow for visual/product design work that needs evidence, artifacts, backlog context, and active delivery.
2. Position the flow between requirements and implementation: too concrete for requirements discovery alone, too unresolved for delivery alone.
3. State the promise: turn existing design evidence and lean constraints into approved artifacts, backlog items, and a started delivery-phase.
4. Name the first principle: design starts from existing product truth, not blank-slate taste.
5. Walk intake as evidence collection: routes, pages, flows, target surfaces, theme CSS, tokens, global styles, components, screenshots, Figma inputs, content, brand constraints, and known decisions.
6. Explain confidence handling: missing screenshots or Figma do not block by default; low-confidence intake asks one concrete clarification or screenshot request.
7. Introduce route-gated execution: entrypoint reads router.md, emits router output, loads exactly one phase, writes a handoff, then stops or re-enters.
8. Clarify direct entry: starting at prototype, approval, backlog, or delivery handoff still routes through prerequisite and staleness checks.
9. Show the phase path: intake -> grill -> prototype -> approval -> backlog -> delivery-handoff.
10. Land the router contract: selected phase, evidence, next file, stop-or-re-enter decision, blockers, and route trace.
11. Land the handoff contract: phase, status, scope, artifacts, validation, open questions, next route, and blockers.
12. Explain staleness as a design safety gate: scope, route, theme, components, content, artifact intent, approval, backlog ids, and target surface can invalidate old evidence.
13. Pivot to grill: the grill is intentionally lean and only asks goals, scope, constraints, conflicts, hard requirements, ownership, target surface, non-negotiables, and artifact intent.
14. Warn against over-grilling: detailed UI choices belong to prototype, where the user can react to visual evidence.
15. Name the scope rule: one branch per user-visible page or flow; section branches only when the section is an independent decision surface.
16. Introduce artifact intent as the prototype fork: the user wants either image references or prototype artifacts.
17. Explain capability fallback: image intent uses imagegen when available and falls back to $prototype only when unavailable; prototype intent activates $prototype directly.
18. Make design directions subordinate: directions are generated as artifact input, not as a standalone proposal phase.
19. Emphasize delegation: $prototype production belongs to subagents so the main thread stays clean for user discussion and validation.
20. Explain approval: approval is explicit and per user-visible scope unit; artifact existence is not approval.
21. Define the approved artifact contract: scope, intent, links, durable visual assets, evidence, accepted constraints, implementation notes, acceptance checks, and staleness risks.
22. State the backlog gate: no approved artifact set means no backlog conversion.
23. Explain backlog conversion: write-backlog receives approved artifact context and preserves visual evidence, constraints, acceptance checks, and fallback blockers.
24. Introduce durable assets: design artifacts must not live only in prose, temp files, or transient browser URLs.
25. Route asset details to repo-asset-management: backlog attachments first, repo-provider attachments as fallback, provider commands outside the page.
26. Close the lifecycle with delivery handoff: delivery-handoff starts delivery-phase with backlog ids, approved artifacts, target surfaces, constraints, validation expectations, frontend taste skills, and before/after PR evidence guidance.
27. Add the delivery boundary: delivery should not reopen design approval unless artifacts are stale or contradicted by implementation evidence.
28. End with terminal outcomes: either approved artifacts become backlog and delivery starts, or the flow stops with a concrete blocker.

Parked Beats

• A detailed provider-by-provider asset hosting explanation belongs in repo-asset-management, not this flow page.
• A long example of generated image versus prototype output may be useful later, but the current source material does not include a real runtime example.
• Skill-reference updates for design-phase and repo-asset-management are adjacent docs work, but not part of this Supported Flows page journey.

Gaps For Shape Pass

• Decide whether the final page needs a Mermaid sequence diagram or a compact phase table.
• Decide how strongly to cross-link Requirements To Backlog, Manual Delivery Flow, repo-asset-management, and Skill Reference.
• Add one short operator example if a real design-phase run exists later.