Design Phase Supported Flow Fragments
Design Phase Supported Flow Fragments
design-phase is the missing Supported Flows page for design work that has to move from evidence to approved artifacts, then into backlog and active delivery.
The page should not present design as a blank-slate taste exercise. The first move is intake: read existing routes, pages, flows, target surfaces, theme CSS, tokens, global styles, components, screenshots, Figma inputs, content sources, brand constraints, and known decisions.
Existing product design evidence is product truth. New taste work adapts to it unless the user explicitly asks to replace it.
Missing Figma or screenshots should not block by default. Absence is still evidence: record the gap, classify confidence, and continue unless the intake is too thin.
Low-confidence intake means fewer than routes plus one style, component, or content source. In that state the agent asks one concrete clarification or requests one screenshot. It should not invent a design system silently.
design-phase is route-gated. The entrypoint reads router.md, inspects enough evidence to choose exactly one phase, emits router output, loads that one phase file, writes a phase handoff, then stops or re-enters routing.
Direct entry does not mean skipping the router. If the operator asks to start at prototype, approval, backlog, or delivery handoff, the router still checks prerequisite evidence and staleness before loading that phase.
The phase list is intentionally small: intake, grill, prototype, approval, backlog, delivery-handoff.
The router output is part of the workflow, not debug noise: selected phase, evidence, next file, stop-or-re-enter decision, blockers, and route trace.
The phase handoff is the resume contract: phase, status, scope, artifacts, validation, open questions, next route, and blockers.
Staleness is not only file age. Scope, route, theme, components, content, artifact intent, approval status, backlog ids, and target surface can all make previous evidence stale.
Visual artifacts go stale when screenshots, Figma inputs, generated images, prototype links, or durable asset links no longer match current code, accepted constraints, or the user-visible scope.
The grill step should be lean. It asks about goals, user-visible page or flow scope, constraints, conflicts with existing system evidence, hard requirements, content ownership, target surface, non-negotiables, and artifact intent.
The grill should not ask detailed UI choices that prototype work should discover. Prematurely grilling visual minutiae creates false certainty before there is something to look at.
Default grill branch: one user-visible page or flow. Section-level branches are exceptional and only make sense when the section has independent conversion, product, or interaction meaning.
Artifact intent comes before capability detection. The user wants either image references or prototype artifacts. Image generation availability only matters as fallback from image intent to prototype artifacts.
If the user wants images and image generation is available, prototype uses imagegen plus web or mobile frontend image skills. If image generation is unavailable, it falls back to $prototype and records the fallback.
If the user wants a prototype, activate $prototype. Do not fall back to images.
Design directions do not live as their own phase. They are generated as direct input to artifact production.
Prototype work belongs to subagents. The parent thread stays focused on orchestration, user discussion, and validation instead of filling itself with artifact-generation detail.
Prototype may activate $prototype, design-taste-frontend, gpt-taste, image-to-code, imagegen-frontend-web, or imagegen-frontend-mobile, but only after the router selects prototype. Child-skill delegation is phase-local.
Approval is per user-visible scope unit. Artifact existence is not approval.
An approved artifact set needs a contract: scope unit, artifact intent, artifact links or files, durable visual asset links when available, evidence summary, accepted constraints, implementation notes, acceptance checks, and staleness risks.
No approved artifact set means no backlog conversion for that scope unit.
Backlog conversion activates write-backlog only after approved artifact context exists.
Backlog bodies should carry the design implementation context: scope, intent, artifact links, constraints, implementation notes, acceptance checks, durable visual assets, and fallback blockers.
Design artifacts must not become prose-only memory. Generated images, prototype URLs, screenshots, and inspectable artifacts should be linked or attached so implementation can inspect them later.
repo-asset-management owns durable visual asset guidance. The design page should say design-phase uses it, not duplicate provider-specific upload commands.
Backlog attachments are preferred for approved design/prototype assets. Repo-provider attachments are the fallback when backlog attachments are unavailable or unsuitable.
Local temp files and transient browser URLs are not final visual evidence.
Delivery handoff starts delivery-phase. It is not a suggestion to maybe run delivery later.
The delivery brief should include backlog ids, approved artifact links, target surfaces, scope units, constraints, acceptance checks, expected frontend taste skills, browser or screenshot validation expectations, and before/after PR evidence guidance.
Delivery should not reopen design approval unless the approved artifacts are stale or contradicted by implementation evidence.
The flow is useful when the operator has design-ish work that is too concrete for requirements discovery alone but too unresolved for implementation: redesign a page, create a new screen, reshape a user flow, align UI work to an existing design system, or carry approved visual artifacts into delivery.
This page should sit beside Requirements To Backlog and Manual Delivery Flow. Design Phase is a bridge flow: it accepts existing design evidence and lean constraints, creates approved artifacts, then hands trusted backlog context to delivery.
Reader promise: use this when visual work needs evidence, iteration, explicit approval, durable assets, and implementation handoff without turning the whole run into an unbounded design chat.
Terminal outcome: either approved design artifacts are converted into backlog and delivery is activated, or the route stops with a concrete blocker such as missing target surface, low-confidence evidence, unresolved constraints, stale artifacts, missing approval, failed asset upload, or missing backlog ids.