layout

layout

!checklist init ${CLAUDE_SKILL_DIR} --force

An atelier is a craftsman's working studio — the space where decisions about form, proportion, and composition happen before the piece leaves the bench. layout is the composition lens of the atelier suite: where the other skills decide what it looks like (color, type, form, motion), layout decides how it is organized — the grid, the hierarchy, the reading measure, the spatial rhythm, and the shape of every application-layer state. Its product is a composed surface: an explicit armature, a quantified spacing system, and an application layer that holds its form when reality provides the actual data. It runs across gated stages and will not advance past a GATE until the checklist tool clears it — order enforced, substance yours.

The governing fact: hierarchy and the grid are decisions, not defaults — and the agent makes neither. The agent places elements in a container, sizes them to fit, and calls it done. It does not ask "what does the eye see first?", does not establish a grid before placing elements, does not consider what happens when a name is sixty characters long or when a table cell contains null. What reads as "amateur layout" is almost always the absence of three things: a decided visual hierarchy (everything at the same weight reads as noise), a consistent spatial system (ad-hoc gaps of 13px, 22px, 7px — the eye detects rhythmic incoherence before the mind names it), and a designed application layer (empty states that are blank divs, error states that are unstyled text, forms where the label disappears when you start typing). These are not polish — they are the substance. A layout without a composed hierarchy is not a draft of a good layout; it is a different artifact.

The boundary with surface:keel: keel owns the CSS mechanism — how Grid and Flexbox distribute space, the cascade, the box model, positioning contexts. layout owns the composition judgment — which grid, which hierarchy model, what density register, how the long tail holds. The questions answered here are design questions that require taste; the questions answered in keel are engineering questions that require correctness. Bring a layout decision here; bring a CSS bug to keel. Cross-reference keel for the mechanism when a stage sends you there for implementation.

This is where the agent era bites:

• The agent does not compose. It fills space. Every element gets a plausible size and a plausible gap; the result is a layout where everything competes equally for attention, nothing reads as the primary entry point, and the eye has no path. Hierarchy must be decided — one primary element, named, placed at the optical center, given dominant size or weight or contrast — before the agent implements it.
• The agent does not design the long tail. It designs the happy path: populated data, English text, a name that is twelve characters. The production surface has names that are sixty characters, numbers that are nine digits, fields that are empty, translations that are forty percent longer. Layout must be stress-tested before it ships, not after the first bug report from production.
• The agent does not design states. An empty state gets a blank div or a developer-default "No data found." An error state gets unstyled red text. A loading state gets a spinner that appears after the content-space has already shifted. The application layer — all states, not just the populated one — must be explicitly designed.
• The agent uses magic px everywhere. padding: 13px, margin-top: 22px, gap: 7px — each value chosen by eye, none derived from a system. The result is rhythmic incoherence that the eye reads as "off" without the viewer knowing why. All spatial values must come from the spacing scale.