layout-rules

name	layout-rules
description	A battle-tested avoid-list of 39 structural and interaction defect classes for tool/dashboard UIs (structure, footers/metrics, tables, color/contrast, URL state, JS traps, accessibility/touch, i18n/theming, de-slop), distilled from a real build/audit cycle. Use when designing, building, or reviewing any layout, dashboard, data-dense tool UI, viewer, or admin interface. Triggers on "design a layout", "build a dashboard", "make a viewer/tool UI", "review this UI", "какие правила дизайна", or before writing any HTML/CSS for a tool-like interface.
handoffs	[{"to":"design-tokens","when":"rule 12 flags a text/background pair that must be measured or remediated"},{"to":"ux-writing","when":"a finding is a wording rule (5, 8, 9, 38) and the rewrite is owed"}]
accepts	[{"from":"walkthrough"}]

Layout Rules

Announce at start: "I'm using the humane:layout-rules skill to check this layout against the defect avoid-list."

A defect-class avoid-list for tool/dashboard UIs. Every rule is a bug or design smell actually caught in a real build-and-audit cycle — treat them as hard constraints, not suggestions.

Usage

1. Read the full ruleset: layout-design-rules.md, bundled next to this file (single source of truth — do not duplicate it here).
2. Before designing: apply sections «Structure & hierarchy», «Color & contrast», «De-slop» as constraints in the design plan. Say explicitly which rules shaped the plan.
3. While building: enforce «Footers, metrics, copy», «Tables & lists», «State & navigation», «Interaction correctness», «Accessibility & touch», «i18n & theming».
4. After building: run the post-build checklist below; screenshot-test in a real browser (rule 29) on both themes and on an empty/minimal dataset (rule 30).

Post-build checklist (the ones most often violated)

• Zero left-border accent rails (rule 1); zero eyebrow caps-labels (rule 2)
• Third heading level actually exists and is distinguishable (rule 3)
• Every verdict/summary line adds a conclusion or names a linked entity (rules 5, 8)
• Every metric is informative or clickable-to-filter (rules 6–7)
• Tables sortable + filterable, tabular-nums (rule 10)
• Faintest text token clears 4.5:1 on both themes (rule 12)
• Every app location has a URL; reload restores it exactly (rule 16)
• [hidden]{display:none} for every display-classed component; close/reset logic before early returns in delegated handlers (rules 18–19)
• SVG interactives: focus ring, keyboard activation, tap-tooltips (rules 22–23)
• Both locales key-parity if i18n exists (rule 27)

Conflict precedence

The user's explicit words > this ruleset > project's existing system > personal taste. If a rule conflicts with an existing design system in the repo, flag it, don't silently rewrite.

What this skill does not own

Each rule lives in one place. When a concern crosses a boundary, name the handoff rather than restating the rule here.

Concern	Owner
Measuring a color pair, and changing it	design-tokens (tokens contrast) — rule 12 says that it must clear the bar; the command says whether it does
The source wording of any user-facing string	ux-writing — rules 5, 8, 9, 38 defer to it on wording
Whether the flow is usable at all	nielsen-heuristics
Art direction, palette, and type choice	design-tokens and brandkit
Typography mechanics, motion recipes, ARIA depth	Not covered here. If interfaces (better-typography, better-ui, better-accessibility) is installed, defer to it; otherwise say the domain was not reviewed rather than improvising

Review Output Format

When reviewing an existing UI rather than building one, report findings in this shape so the result composes with the other humane review skills.

Severity	Location	Before	After	Why
MEDIUM	src/Card.tsx:28	border-left: 3px solid var(--accent)	Background tint + leading color dot on the label	Rule 1: left-border accent rails

• Severity — HIGH blocks content or an action, loses state, or breaks a supported viewport; MEDIUM harms hierarchy, adaptability, or correctness; LOW is isolated polish.
• Location — path/to/file:line, or the exact screen and element.
• Why — name the numbered rule.

One root cause is one row, listing every affected location. Cap at 15 findings; never pad — no findings is a valid result. Then:

• Considered but Rejected — 2–5 real candidates you inspected and chose not to report, with the reason (the project's system permits it, the deviation is intentional, the evidence is thin).
• Verification — which rules you actually checked and how. Rule 29 means a real browser screenshot on both themes; rule 30 means an empty dataset too. Anything unchecked is listed as Not verified, never converted into a finding.
• Verdict — Block, Needs changes, or Approve.

Reviews are read-only unless the user also asked for the fixes to be applied.