Design turns the applicable Product and Architecture foundation into the smallest current experience model that subsequent experience changes can implement and review. Rather than designing every component and screen in advance, publish a foundation that lets the next change proceed without having to reinvent common experience standards.
Before performing this skill, references/communication.mdand apply it to natural language sent to readers or saved in documents during execution. This includes guidance sent when exiting at a gate.
Enter the applicable state
Before starting target-specific actions, references/project-gate.mdand design apply the conditions. Then open the readable .devflow/index.md, the complete Product and Architecture.
If the current member's Sketch state specifies next_route로 design, before writing the file
references/sketch-handoff.mdand complete the landing contract together with the Design publication. If an in-progress adoption has passed on a Design judgment, read the adoption state and the source that judgment points to.
If a judgment received from an in-progress adoption is passed to another route without a Design answer, before leaving, replace the adoption state with one route that will take over that judgment and one scoped next action.
If Design cannot publish the conclusion passed on by the current member's Sketch, do not send it directly to another target.
references/sketch-handoff.mdspecify the reason and one next action according to sketchand send it back to the same member's
If Architecture declares Design non-applicable, do not open another Design reference or modify project documents. If a new user touchpoint has arisen or current evidence conflicts with that declaration, do not decide based on Design preference; send it to
architecture. Otherwise, if a judgment was received from an in-progress adoption, replace the state with
next_route: adoptand one action to continue, and adoptroute to. Otherwise, directroute to.
If there is no applicability determination, or the support surface is open or contradictory, architectureroute to. If Product promises or Domain meaning are insufficient, productroute to.
Only when Design applies, references/project-knowledge.md, references/design-document.mdand open the Domain·Design lineage that the current experience question routed to. Only when creating or replacing a decision document,
references/decision-document.mdopen.
Exploration and review perspectives
Design first constructs a single current experience that the user undergoes within a situation, rather than a list of screens and styles, just as Dewey's experience and inquiry perspective does. When a prototype, the current UI, or a live review surface reveals unexpected facts, it revises the means of expression as in Schön's reflection-in-action, but does not quietly change the product's purpose. From a phronesis perspective, it distinguishes the principles that multiple changes must share from the details that can be implemented and cheaply compared, and does not use taste or experience as unfounded authority.
First create a description of the current experience
Before asking the user for a style list, create a single current experience description from the Product's user and promise, Architecture's supporting surfaces and constraints, the current selection, observable interactions, existing UI, token, and component code if present, the live review surface, and any specified references. Distinguish already established principles, patterns verifiable by evidence, and unfounded taste.
Do not ask in turn about document items, colors, components, or screen lists. Between the current description and the common Design contract, keep as question candidates only the points where the answer actually changes the direction of the experience or the patterns and review criteria that multiple changes must share.
Separate only the questions to decide now
If an empty choice would force the next step to invent a new common experience principle or system pattern, handle it now. Do not pre-fix reversible detail choices that can be implemented on one surface and cheaply compared. If separate investigation, a prototype, or user observation is needed and that context must be preserved even outside the current stewardship interval, send it to
sketch.
If multiple directions are genuinely viable, compare them by Product outcome, consistency, accessibility, supported surfaces, and reversal and review cost, and Design recommends one. Ask only when choices remain that only the user can make, such as brand, aesthetics, or organizational priorities. In the question, explain the current understanding, the recommendation, and the experience that changes depending on the answer.
According to this criterion, only immediately before actually asking for the user's explanation or binding choice, open
references/question-dialogue.mdand apply it to the question wording.
Publish the current Design
references/design-document.mdApply the completion conditions and split/fold determination of project/design.mdand construct it and the necessary children, then replace the existing files. If code, external design sources, and a live catalog are needed, put their roles, selection conditions, and review routes in the Design, but do not duplicate the content.
If the important reason, rejected alternatives, and reconsideration conditions are needed, open references/decision-document.mdand create or replace one current decision document. Do not create it to leave a copy of work facts, component lists, and current rules.
In the same change, .devflow/index.mdhas route UI and interaction questions to the Design root, and has foundation readiness judged from Architecture's application declarations and the Design documents. Do not copy leaves, tokens, and patterns into the index.
If it is a judgment received from an adoption in progress, first publish the canonical Design and decision and the route, then according to the common gate, [the adoption state] next_route: adoptReplace it with one action to continue with. Do not continue as a new independent
foundation flow.
read the current result again and route
Read the Design root and the lineage of the Design or Domain design child selected for the current question. Also check the index and the Product·Architecture·Domain boundaries, as well as the live review surface declared to be used. See whether work state or technical constraints have moved into Design, and whether Design rules have become two different sources of truth alongside code·catalog.
If a judgment received from an adoption in progress has been posted, before any other route adoptroute to. If the result can be observed on the specified
surface and from the currently known state, and the next change does not need to newly create a common experience standard, directroute to. Product boundaries product, support surface·platform questions architecture,
exploration to preserve sketchroute to.
Report the following.
게시한 경로:Design, concern, decision, index path created or replaced. If Design is not applied,none경험:the current experience direction and the expression·interaction·accessibility·state principles shared by multiple changes검토 surface:where and as what the result will be observedRoute와 행동:one next route and one scoped action미검증 또는 열린 항목:experience claims not confirmed by current evidence and the conditions under which to recheck them
Do not write Product or Domain business meaning, Architecture constraints, Work artifacts, implementation, adoption inventory, or verification verdict.