/antislop-layoutmobile

name: antislop-layoutmobile
description: "Mobile layout skill for antislop. Use for layouts that reflow across screen sizes, phone to desktop: grids, overflow, tap targets. Load with the core."
allowed-tools: Read Write Edit Glob Grep

antislop-layoutmobile

> Anti Slop: Rules for AI Coding Agents. Mobile Layout skill

> Part of the antislop system. Read together with `antislop.md` (the core). This skill deep-dives the responsive layout concern: how a layout must reflow across screen sizes, phone to desktop. Breakpoints, scale, grids, overflow, tap targets, and navigation. It references core rules by number and never duplicates or renumbers them. Load it when the task builds or edits a layout that has to hold up at any screen width.

How to use this skill

• Load together with `antislop.md` whenever the task is mobile or responsive layout work. The core holds the mechanism (the purpose test, the three tiers, the Delivery Gate); this skill holds mobile-layout depth.
• Every entry has the same shape: **Tell** (the pattern), **Why** (why it reads as slop), **Fix** (what to do instead), with the governing core rule cited as R-XX.
• The principle behind this skill: **mobile layout is a different layout, not the desktop layout at a smaller size.** It must reflow: re-stack, rescale, and re-order with intent. Every pattern below is a way a layout fails to reflow.
• The Delivery Gate in the core remains the gate. The "Layoutmobile Skill Checklist" at the end of this file is the mobile-specific supplement to run alongside it.

Breakpoints

Desktop-Only Layout

• **Tell:** one layout state for every screen; the mobile view is the desktop layout squeezed into a phone.
• **Why:** R-03 requires a mobile layout that is perfect, not an afterthought. A page that only shrinks has no mobile design at all: cards that worked side by side overlap, and text meant for a wide canvas crowds into a narrow one.
• **Fix:** define a real mobile state at the breakpoint where the content stops working. The mobile layout reflows: columns stack, sizes drop, and order changes where the content needs it. If the mobile view is just the desktop view at a smaller width, the layout is not done.

Breakpoint Driven by Device List

• **Tell:** breakpoints named after phone widths (375px, 414px, 768px) chosen because "that is the iPhone size", not because the content breaks there.
• **Why:** device widths change every year and every model. A breakpoint is a point where the layout stops holding; forcing it to match a device list makes the layout follow a spec sheet instead of the content (R-03).
• **Fix:** place breakpoints where the content actually breaks: when a column stops being readable, when a row of cards gets too narrow. Test by narrowing the viewport and watching where it snaps, then set the breakpoint there.

Mobile Styled Last

• **Tell:** mobile rules bolted on as a trailing override: a long desktop stylesheet with a small media query at the end fixing one or two things.
• **Why:** an override patch is not a mobile design. It fixes the symptom that got reported and leaves the next one, and the base styles stay tuned for a wide screen (R-03).
• **Fix:** treat mobile as a designed state, not an override. Give the narrow viewport its own deliberate sizes and stacking, and verify the whole layout there, not just the patched spots (R-35).

Two-State Layout

• **Tell:** a layout with exactly two states: a single stacked column below one breakpoint, and a wide multi-column grid above it, with nothing defined in between. A tablet or small laptop width then inherits whichever state is closest: the phone stack stretched absurdly wide, or the desktop grid crammed into a fraction of its intended canvas.
• **Why:** a page is a continuous range of widths, and R-03 demands it hold up at every one of them, not just two chosen breakpoints. Two states leave the whole middle band of the range (roughly 600 to 1024 px, where tablets and small laptops live) as an accident: content that neither stacks with intent nor sits in a grid that fits. The layout reads as designed only at its two sample points and broken everywhere between.
• **Fix:** define real states at the widths where the content stops working, and let them be as many as the content needs. A typical reflow is three states, not two: single column, then a two-column grid when cards get too wide as a single stack, then the full multi-column grid only when it genuinely fits. Verify by dragging the viewport through the whole range, not by checking two widths and calling it done (R-35).

Scale & Sizing

Desktop-Sized Everything

• **Tell:** padding, gaps, hero heights, and card sizes carried unchanged from desktop to mobile, so every section looks blown up on a phone.
• **Why:** an element sized for a 1440px canvas dominates a 375px one. What reads as confident on desktop becomes oversized on mobile: nothing fits, nothing breathes, and the page feels like it was designed for a screen that is not the one in hand (R-03). Spacing and type should follow the design rhythm (R-05), and that rhythm has a smaller register on mobile.
• **Fix:** give mobile its own size step: a smaller type scale, tighter section padding, smaller gaps. Keep tap targets at their minimum size (see Tap Targets), but shrink everything else with intent at the breakpoint.

Fixed Pixel Type

• **Tell:** font sizes in fixed px that never change between desktop and mobile, so headings and body text stay oversized on a phone.
• **Why:** type that does not respond to the viewport is type sized for one screen. R-03 demands the mobile layout hold up, and R-06 requires typography that improves readability. A headline that spans the whole phone width or a body size tuned for a wide line breaks both.
• **Fix:** use fluid type (`clamp()`) so sizes scale with the viewport, or set a smaller type step at the breakpoint. Verify the result at a narrow width (R-35), not just in the desktop prev