build-ui

<visual_direction> $ARGUMENTS </visual_direction>

If <visual_direction> is empty, stop and ask for it in one sentence. Do not invent one.

If it names a file or a design-handoff archive, unpack it to your scratchpad and read it before anything else. A handoff usually contains two kinds of document and they are not equal:

• A decision sheet ("pick one from each row") is a menu of options that may never have been answered. It is not the direction.
• A resolved system ("locked system: …", a logo-construction page, exported assets) carries the picks that were actually made. That is the direction. Where the two disagree, the resolved system wins.

Read the exported assets too — an .svg mark tells you the final geometry and which element owns the accent. A handoff may quote values from the current Theme.swift. Those are the appearance you are blind to. Take the system (which hue, which ground, which face, which element carries the accent) and discard any literal value it attributes to today's build.

<why_this_replaces_build_skin> The previous attempt used /build-skin, which scoped the work to the skin seam and told the agent that the container's furniture — report control, project badge, note pane — was "palette only", and that the shipped prose renderer had to be reused. Those components are most of the pixels on a body-heavy surface. The result was a careful palette swap on somebody else's layout, and it was correctly rejected.

UI-RENDERING-BOUNDARY.md is the correction. Read it in full before writing anything. It moves the seam, lists exactly what you keep and what you write, and carries the behaviour embedded in each component you are replacing. Everything below assumes you have read it. </why_this_replaces_build_skin>

Treat the blindfold as a rule, not just a wall:

• Do not read, search, reconstruct, or ask about the current appearance. If a tool call is denied, that is the system working. Move on — never route around it with a different tool, a shell command, or git history.
• The deny-list is not airtight and you must not lean on it. Theme/, Components/, Dialogs/ and the existing skins hold the current appearance. If you find yourself about to open one, the answer is in UI-BEHAVIOUR-SPECIFICATION.md or in UI-RENDERING-BOUNDARY.md §4 — go read that instead.
• Services/ and Models/ are not blocked and you will need them: the key router, the focus manager, the cooldown gate, the request and response models. Read those freely. They hold no pixels.
• Never run a dialog without DIALOG_SKIN set to your own id. The default renders the current UI.
• Screenshot only the window id returned by test-cases/capture-dialog.swift, never the screen or another window. Do not open the built app's other windows, the docs site, or any image in the repo.
• Build output quotes source from files you must not read. Filter it — print only error headlines from your own paths. Write the filter into a script rather than reading raw build logs.

If you catch yourself reasoning from "how it probably looks today", stop.