Design

Design phase is the bridge between requirements and implementation for visual product work.

Use it when a page, screen, or flow needs design evidence, artifact iteration, explicit approval, backlog context, and active delivery. The flow starts from existing product truth, not a blank slate: routes, styles, components, content, screenshots, Figma inputs, and brand constraints shape what the agent is allowed to propose.

Use this when: visual or UX work is too concrete for requirements discovery alone, but too unresolved for direct implementation.
It gives you: evidence intake, lean design constraints, generated images or prototype artifacts, explicit approval, backlog context, and delivery activation.
It ends with: approved artifacts converted into backlog and delivery-phase started, or a concrete blocker.
Wrapped phase/skills: $design-phase, $requirements-grill, $prototype, $write-backlog, $repo-asset-management, $delivery-phase, plus frontend taste or imagegen skills during prototype work.

Runtime Graph

Design phase turns existing evidence into approved artifacts, then into delivery. The graph shows the important ownership transfer: design approval is not assumed from artifact existence, and delivery starts only after approved artifact context reaches backlog.

Reading The Design Loop

Intake comes before taste. Existing routes, tokens, global styles, components, screenshots, Figma inputs, content, and brand constraints are product truth.
The router chooses one phase at a time. Direct entry into prototype, approval, backlog, or delivery handoff still runs prerequisite and staleness checks.
The grill is lean. $requirements-grill covers goals, page or flow scope, constraints, conflicts, hard requirements, content ownership, target surface, non-negotiables, and artifact intent. Prototype work starts after it completes.
Artifact production is delegated. $prototype owns prototype artifacts; imagegen frontend skills own image references when available.
Approval is explicit and per user-visible scope unit. Artifact existence is not approval.
Backlog carries the approved artifact set, not only prose.
delivery-handoff starts delivery-phase; it does not merely recommend it.

Entrypoints

$design-phase: run the full route-gated design lifecycle or resume at a requested phase through the router. It is a globally advertised explicit workflow entrypoint, never a scoped primary skill.
$requirements-grill: run only inside the grill phase to close lean design constraints.
$prototype: produce throwaway logic or UI prototype artifacts when artifact intent is prototype, or when image generation is unavailable for image intent.
$repo-asset-management: produce durable visual links for proposed artifacts, backlog attachments, repo-provider fallbacks, and PR evidence.
$write-backlog: convert approved artifact sets into backlog context.
$delivery-phase: start implementation from approved artifacts and backlog ids.

Prototype may also use frontend taste or image skills such as $design-taste-frontend, $gpt-taste, $image-to-code, $imagegen-frontend-web, or $imagegen-frontend-mobile when the selected artifact path needs them.

Route Contract

Every run starts at the router. The router inspects only enough request, repo, design, artifact, backlog, and delivery state to select one next phase.

Router output names the selected phase, evidence, next file, stop-or-reenter decision, blockers, and route trace. Each phase then writes a handoff with status, scope, artifacts, validation, open questions, next route, and blockers.

Evidence can go stale when scope, route, theme, components, content, artifact intent, approval status, backlog ids, or target surface changes. Visual artifacts can go stale when screenshots, Figma inputs, generated images, prototype links, or durable asset links no longer match current code or accepted constraints.

Intake And Grill

Intake collects existing product evidence and classifies confidence.

Missing Figma files or screenshots do not block by default. Low-confidence intake means fewer than routes plus one style, component, or content source; in that case, the agent adds the missing evidence decision to $requirements-grill or requests one screenshot.

The grill closes only what prototype work needs to start safely. $requirements-grill persists stable question ids, prerequisites, current-frontier membership, and answered or unanswered state before each yield and after each response set. It should not ask detailed UI choices that are better discovered through generated images or prototype artifacts. Artifact production begins after $requirements-grill completes.

Prototype And Approval

Prototype starts from artifact intent: image references or prototype artifacts.

Image intent uses image generation plus web or mobile image skills when available. If image generation is unavailable, the flow falls back to $prototype and records the fallback. Prototype intent activates $prototype directly; capability detection only decides whether image intent can stay on the image path.

Design directions are not a standalone phase. They are generated as direct input to the artifact worker. $prototype artifacts follow the research-pack prototype skill: throwaway logic or UI variants that answer the design question, preserve the source evidence, and are deleted or absorbed after the answer is captured.

An approved artifact set includes 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.

Backlog And Delivery

Backlog conversion is blocked until at least one fresh approved artifact set exists.

When backlog conversion runs, $write-backlog receives the approved artifact context: scope, intent, artifact links, constraints, implementation notes, acceptance checks, durable visual assets, and fallback blockers. Backlog attachments are preferred for approved design or prototype assets. Repo-provider attachments are the fallback when backlog attachments are unavailable or unsuitable.

Delivery handoff builds the implementation brief from backlog ids, approved artifact links, target surfaces, scope units, constraints, and acceptance checks. It also names frontend taste expectations, browser or screenshot validation, and before/after PR evidence guidance through durable asset links.

Delivery should not reopen design approval unless the approved artifacts are stale or contradicted by implementation evidence.

Flow

Run the design lifecycle this way:

Invoke $design-phase with the target page, screen, flow, or direct-entry request.
Let the router choose exactly one phase from current evidence.
Run intake when design evidence is missing, incomplete, low-confidence, or stale.
Run the lean grill when accepted constraints or artifact intent are missing.
Run $requirements-grill for lean design constraints and persist its rounds.
After it completes, delegate prototype artifacts to $prototype or image artifacts to imagegen.
Record explicit approval, rejection, or requested changes per user-visible scope unit.
Convert only approved artifact sets into backlog context.
Use durable visual asset links before backlog or PR handoff whenever assets exist.
Start $delivery-phase from backlog ids plus approved artifact context.

Decision Points

If the target surface is unclear, add that decision to the next $requirements-grill round before routing further.
If intake is low-confidence, request the missing evidence in the next grill round or ask for a screenshot instead of inventing a design system.
If artifact intent is missing, include the image-reference versus prototype choice in the next grill round.
If artifacts exist without approval, route to approval instead of backlog.
If assets are not durable, use $repo-asset-management or record the upload blocker.
If implementation evidence contradicts approved artifacts, return to design approval or prototype before delivery continues.

Terminal Outcome

The flow ends when approved design artifacts are attached or linked into backlog and $delivery-phase has started with visual evidence expectations.

If it cannot complete, it stops with a concrete blocker: missing target surface, low-confidence evidence, unresolved constraints, missing artifact intent, stale artifacts, missing approval, failed asset upload, or missing backlog ids.

Validation

Report the route trace, selected phases, intake confidence, accepted constraints, artifact intent, approved artifact sets, durable visual links or blockers, backlog ids, delivery activation brief, and any browser or screenshot expectations carried into implementation.

On this page