Unslopyouryour generic UI

Show metrics, testimonials and client logos only from the product's data and with a source; fabricated ones are a finding.

Example: "10,000+ teams", "3x faster" or a row of logos in a template with no data behind it.

Not a finding: a metric from product data with its source; a testimonial with a name and a link.

This extends “No false urgency” and “Only verified claims about competitors” to claims about one's own product.

Do not show machine formats such as cron expressions, ISO 8601 durations or raw timestamps to people; translate them into plain language, for example "daily at 06:30 UTC". Leave an unfamiliar format as it is: an invented interpretation is worse than the raw string.

Interface copy does not create urgency the product does not have, such as an invented deadline or a claim that only a few places are left without data behind it. A real deadline with a date is not a finding.

Production pages of any project do not show the agent's or the process's service notes: verification dates, internal source IDs, blocks such as "Sources, checked" with a date, or lines such as "Sources:" followed by internal IDs. Facts are checked against fresh sources, but that evidence lives in the working records. Sources meant for readers, such as sources in science or medicine, or citations, are not forbidden.

When comparing products or writing promotion, compare what each product is meant to do. Do not use internal version numbers, release states or target/today markers.

State a claim about a competitor only with a verified source; where there is no verified fact, show a dash. Convey the advantage through the wording of your own product's intent.

Before building a comparison or a promotional page, read the product's approved positioning and show its axes. A comparison assembled from technical mechanisms that omits the agreed differentiation is a finding.

Service and temporary text does not reach the visible production interface: template default placeholders, a loading state that never loads, aria-only text shown on screen, notes for developers. An empty field hides its element or stops the build. A real empty state with useful text for the user is not a finding.

Stage must look like a ready candidate for production: what a person sees on stage is exactly what they will see in production. Anything visible on stage that slips through review can be carried into production. Show no commit hashes, preview or stage labels, environment badges or build versions on screen. Identify a build only invisibly: an HTTP header, a build.json file, a meta tag or an HTML comment. The rendered stage and production differ in visible text only by the changes of the release.

On a page that sets display text in capitals, prose gets its own class with text-transform: none and the text typeface. A global text-transform rule on body does not remove the need for that class.

Carry grouping, hierarchy and separation with space, type and alignment first, then with background. Add a line, container, shadow, badge, icon tile or gradient only when the content does not read without it, when it marks a state or an interactive boundary, or when the approved design system defines it. Test by hand: remove the element; if nothing is lost, it is a finding. Replacing one decoration with another (a border with a ring shadow, a card with a tinted box) is the same finding.

Example: a section card holding cards, each with lines between its rows.

Not a finding: an input boundary, a focus state, decoration the approved design system defines.

A border, divider, outline or ring shadow is not the default way to group content: use spacing, type and background first. Remove a line when switching it off changes neither grouping, interactivity nor state, or when two other cues already mark the same edge. Keep lines for input and control boundaries, focus and selection, dense data tables, images that blend into the background, and lines the approved design system defines. A framed box inside a framed box is a finding; input fields and controls inside a frame are not, because their boundaries are among the exceptions above. Any visible line up to 2px counts as a line under this rule: border, outline outside :focus-visible, box-shadow with 0 blur and a positive spread, hr, 1–2px pseudo-elements, divide-x and divide-y. Lines between list rows belong only in dense data where the eye follows a row across columns; when space already separates the rows, the lines are a finding. Check by hand in order: remove, look for a substitute, look for double encoding, apply the exceptions.

Example: a rounded-xl border shadow-sm section holding three rounded-xl border cards, each with divide-y.

Not a finding: a settings group without frames, where spacing separates the groups and inputs have a 3:1 boundary (WCAG 1.4.11).

A container with a border or shadow and with a radius or background, that is a card, is only for a real object: one that is dragged, clicked as a whole or has its own state (a kanban item, a product). A card inside a card is a finding; input fields and controls inside a card do not count as cards.

Example: every section of the page wrapped in a card.

A shadow means a layer above the content. Use it for a real layer or when the approved design system defines it. A shadow on an element that is not a layer is a finding, including a shadow used in place of a border that “Lines only where structure needs them” would remove. Real layers: popovers, menus, modals, sticky elements, dragged objects, and a card that really is a layer above the content.

Example: a shadow on every card and section by default.

Use muted text only for truly secondary meta information and with at least the WCAG text contrast: 4.5:1 for regular text, 3:1 for large text. Muting everything secondary by default is a finding.

Example: every description under headings in regular-size gray text at 3:1.

Not a finding: the date and author under an article at 4.5:1.

Use an eyebrow, kicker, section numbering or a pill above the H1 only as a deliberate element of the brand system or for a real sequence of steps. A label above every heading by default is a finding.

Example: "01 / FEATURES", "02 / PRICING" above every section.

Not a finding: one deliberate kicker in the brand system; real steps of a process.

Three or more identical blocks of an icon in a colored tile, a heading and text give everything the same weight; this template is a finding.

Example: "three features" with icons in squares.

Not a finding: truly equivalent options (pricing tiers, comparisons); iconography the design system defines and that carries meaning.

Gradient text, a purple-to-blue gradient and colored glow on a dark background are allowed only as brand identity fixed in the design system; otherwise they are a finding.

Example: a purple gradient hero heading in a project without such a brand.

Not a finding: a brand gradient defined by design-system tokens.

A details/summary disclosure whose default marker was removed shows a chevron or plus sign that changes state when it opens, so the row does not read as a caption.

Derive nested corner radii from each other instead of picking them by eye: inner radius = outer radius − padding, or outer = inner + padding. An inner radius equal to or larger than the outer one is a finding.

A pressed button responds with scale(0.96); no feedback and a deeper squeeze are both findings.

An icon's stroke width matches the stroke of the text next to it. Calculate it where possible and propose adjusting the icon stroke or slightly changing the font weight; next to bold text, prefer a filled icon instead of adding another stroke width. There is no fixed stroke value.

Use CSS transitions for interactive states where a person can change their mind mid-motion, such as opening and closing a menu. Keep keyframe animations for one-off sequences.

Do not play an entrance animation every time the page loads unless the entrance is intended. An intentional entrance stays as designed.

Give direct feedback a short duration (100–160 ms) and context changes a longer one within the motion budget. One duration for every transition is a finding.

Do not rely on html { scroll-behavior: smooth } when the page scrolls from code: in embedded viewers scrollTo() and scrollIntoView() may not move the page. Implement smoothness in JavaScript and confirm arrival; if scrollY has not changed after 400 ms, jump to the target.

Monospace type is not slop in itself, but AI-generated interfaces overuse it, so treat it as slop by default. Use it only in code blocks and inline code in technical text, in terminal or CLI commands shown for copying, and in diff or patch views. Nowhere else: not for IDs, numbers, labels, tags, headings or interface elements. Numerals in regular text never use monospace digits; code keeps its own digits.

A row or card that changes color on hover must do something on click. Either make it clickable or remove the hover highlight.

On touch screens every interactive element has a hit area of at least 44×44 px, and the hit areas of neighboring elements do not overlap.

On desktop, a 44×44 px hit area is only a recommendation for key actions. Hit areas of 15 px or more inside menus and similar lists are not a finding.

Center asymmetric shapes, such as a play triangle or an icon inside a button, optically, preferably inside the SVG itself. Arithmetic centering that looks off-center is a finding.

Show that a card or popover sits on its own layer with a shadow from the design system's tokens, not with a 1px solid border. Keep borders for states such as focus or selection, and for places that do not read without one. Unlike the source recipe, a 0-blur ring shadow counts as a border; whether an edge is needed is decided by “Lines only where structure needs them”.

Content headings use text-wrap: balance. Content paragraphs use text-wrap: pretty, so no orphan is left on the last line. This applies only to content headings and paragraphs; custom typographic compositions are not a finding.

Choose font smoothing for each typeface and size. Do not set one smoothing value, such as -webkit-font-smoothing: antialiased, on the root for every typeface.

For images that are part of the content, such as images inside an article, a thin low-opacity 1px outline may be offered as an option, never required. An outline around images anywhere else is slop. Transparent images and images the author intentionally integrated with their surroundings are not a finding.

In projects that already have animated icon toggles (menu and close, play and pause, arrows and chevrons), icons of the same shape in another orientation (arrows, chevrons, plus and cross) change by rotation; interpolating coordinates between them bends the lines. Where a transformation is intended, a coordinate morph or a crossfade of two SVGs is a finding. The check is manual: an agent does not notice on its own that a transition looks wrong, so a person sets the boundary. Otherwise a plain crossfade between icons is not slop in itself and requires neither morphing nor an animation library.

Regular text uses the font's ordinary numerals. Do not use tabular figures (tabular-nums, tnum), a slashed zero (slashed-zero, zero) or monospace digits.

On a colored background, such as a brand or accent fill, text is white or black. To mute it, lower the opacity of that white or black, for example rgb(255 255 255 / 0.6); never use a gray token or a gray hex value. Accent-colored text is the only exception. Muted text still meets the contrast in “Muted text needs a role and contrast”.

Example: #aaa text in a purple table cell.

Not a finding: white text at 0.6 opacity in the same cell when it meets that contrast.

A plain prose list that is indented shows visible markers; indentation without markers reads as shifted paragraphs, often after a CSS reset such as ul { list-style: none }. Classed navigation lists without markers by design are not a finding.

Anything a person will see (text, copy, labels, meta rows, blocks, decoration, effects, layers, product claims) ships only if the request or the approved layout contains it. A request covers only its own content: placeholder rows or invented items inside a requested block are unrequested. Approval of a direction, a discussion or a reference unlocks proposals, not implementation. Each unrequested element in a delivered result is a finding; repeating it after a correction raises its severity. Text the user supplied verbatim is not a finding.

Follow the user's current explicit requirements when they differ from general style preferences. Review how well the requested design works and how it uses the project's design system. Do not reject an intentional choice merely because it appears in a generic anti-pattern list.

When the agent believes an element outside the request is needed, it sends a separate proposal with the element's purpose and a preview instead of adding it to the result. Inside the authorized scope, technical steps, checks and fixes of defects against the stated intent are done without asking, and signals such as risks, contradictions or lost elements are raised without asking. Outside that scope, or when a step is irreversible or external, the agent reports and asks first.

Before presenting a revision, verify the actual result against its requirements. Check design-system use, behavior and visual output separately. Reading guidelines or passing a build is not evidence that the interface meets its acceptance criteria. Use an independent reviewer before handoff.

Make a systemic fix in the governing design-system component, token or recipe. Use its existing API or a defined extension, then verify the consuming interfaces. Do not conceal a local override behind a new token name.

A change to the design system does not by itself require renewed permission for work the user has already authorized. Ask when an unresolved product or design choice needs the owner's decision, and stay within the authorized scope.

Keep a project's visual recipes scoped to that project. Reuse the principle of consistency without turning a particular color, shape or treatment into a universal requirement.

Preserve the provenance of examples, references and claimed results. Distinguish a recorded example from a live verified run, and an agent proposal from an owner-approved decision. State missing evidence explicitly.

Preserve approved content, behavior and composition outside the requested change. Compare the original requirement, the baseline and the candidate. Treat unverified areas as unknown rather than passed.

When asked to remove a pattern throughout a product, locate and update every occurrence in the agreed scope. Verify the affected routes and components before handoff instead of fixing only the example that was pointed out.