chill-agent 1.5.0 → 1.6.1

package/skills/antislop-human/references/A11Y-PATTERNS.md

@@ -0,0 +1,249 @@
+# Accessibility Code Patterns
+
+> Reference for antislop. Adapted from the MIT-licensed web-quality-skills by Addy Osmani (https://github.com/addyosmani/web-quality-skills); see LICENSE-web-quality-skills in the skill folder.
+
+Practical, copy-paste-ready patterns for common accessibility requirements. Each pattern is self-contained and linked from the main [SKILL.md](../SKILL.md).
+
+---
+
+## Pointer cursor base layer
+
+Set once, in the base CSS layer, so no component has to remember it (R-39). A CSS reset such as Tailwind preflight sets `button` to `cursor: default`, so this layer comes after the reset.
+
+```css
+a[href], button, summary, select, label[for],
+label:has(> input[type="checkbox"], > input[type="radio"]),
+[role="button"], [role="link"], [role="tab"], [role="menuitem"], [role="option"], [role="switch"],
+input[type="checkbox"], input[type="radio"], input[type="file"],
+input[type="submit"], input[type="button"], input[type="reset"], input[type="range"], input[type="color"] {
+  cursor: pointer;
+}
+:disabled, [aria-disabled="true"] { cursor: not-allowed; }
+```
+
+Text inputs keep `cursor: text`, and drag handles use `grab` / `grabbing`. An implicit label that wraps a checkbox or radio is included, since clicking it toggles the control.
+
+## Modal focus trap
+
+Trap keyboard focus inside a modal dialog so Tab/Shift+Tab cycle through its focusable elements and Escape closes it.
+
+```javascript
+function trapFocus(modal, onClose) {
+  const focusable = modal.querySelectorAll(
+    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
+  );
+  if (focusable.length === 0) return () => {};
+
+  const first = focusable[0];
+  const last = focusable[focusable.length - 1];
+
+  function onKeydown(e) {
+    if (e.key === 'Escape') return onClose();
+    if (e.key !== 'Tab') return;
+    if (e.shiftKey && document.activeElement === first) {
+      e.preventDefault();
+      last.focus();
+    } else if (!e.shiftKey && document.activeElement === last) {
+      e.preventDefault();
+      first.focus();
+    }
+  }
+
+  modal.addEventListener('keydown', onKeydown);
+  first.focus();
+  return () => modal.removeEventListener('keydown', onKeydown);
+}
+```
+
+Call the returned function when the dialog closes, or a second open stacks a second listener:
+
+```javascript
+const release = trapFocus(dialog, () => dialog.close());
+dialog.addEventListener('close', release, { once: true });
+```
+
+The native `<dialog>` element handles focus trapping automatically, prefer it when browser support allows.
+
+---
+
+## Skip link
+
+Allows keyboard users to bypass repetitive navigation and jump straight to main content.
+
+```html
+<body>
+  <a href="#main-content" class="skip-link">Skip to main content</a>
+  <header><!-- navigation --></header>
+  <main id="main-content" tabindex="-1">
+    <!-- main content -->
+  </main>
+</body>
+```
+
+```css
+.skip-link {
+  position: absolute;
+  top: -40px;
+  left: 0;
+  background: #000;
+  color: #fff;
+  padding: 8px 16px;
+  z-index: 100;
+}
+
+.skip-link:focus {
+  top: 0;
+}
+```
+
+---
+
+## Error handling
+
+Announce errors to screen readers and focus the first invalid field on submit.
+
+```html
+<form novalidate>
+  <div id="error-summary" tabindex="-1" hidden></div>
+  <div class="field" aria-live="polite">
+    <label for="email">Email</label>
+    <input type="email" id="email"
+           aria-invalid="true"
+           aria-describedby="email-error">
+    <p id="email-error" class="error" role="alert">
+      Please enter a valid email address (e.g., name@example.com)
+    </p>
+  </div>
+</form>
+```
+
+```javascript
+const form = document.querySelector('form');
+const summary = document.getElementById('error-summary');
+
+form.addEventListener('submit', (e) => {
+  const invalid = [...form.querySelectorAll('[aria-invalid="true"]')];
+  if (invalid.length === 0) return;
+
+  e.preventDefault();
+  summary.textContent =
+    `${invalid.length} errors found. Please fix them and try again.`;
+  summary.hidden = false;
+  invalid[0].focus();
+});
+```
+
+This handler reports what the validation already marked: set `aria-invalid="true"` and the field's error text before submit runs.
+
+---
+
+## Form labels
+
+Every input needs an associated label, either explicit (`for`/`id`) or implicit (wrapping `<label>`).
+
+```html
+<!-- ❌ No label association -->
+<input type="email" placeholder="Email">
+
+<!-- ✅ Explicit label -->
+<label for="email">Email address</label>
+<input type="email" id="email" name="email"
+       autocomplete="email" required>
+
+<!-- ✅ Implicit label -->
+<label>
+  Email address
+  <input type="email" name="email" autocomplete="email" required>
+</label>
+
+<!-- ✅ With instructions -->
+<label for="password">Password</label>
+<input type="password" id="password"
+       aria-describedby="password-requirements">
+<p id="password-requirements">
+  Must be at least 8 characters with one number.
+</p>
+```
+
+---
+
+## Dragging movements
+
+Any action triggered by dragging must offer a single-pointer alternative (WCAG 2.5.7).
+
+```html
+<!-- ❌ Drag-only reorder -->
+<ul class="sortable-list" draggable="true">
+  <li>Item 1</li>
+  <li>Item 2</li>
+</ul>
+
+<!-- ✅ Drag + button alternatives -->
+<ul class="sortable-list">
+  <li>
+    <span>Item 1</span>
+    <button aria-label="Move Item 1 up">↑</button>
+    <button aria-label="Move Item 1 down">↓</button>
+  </li>
+  <li>
+    <span>Item 2</span>
+    <button aria-label="Move Item 2 up">↑</button>
+    <button aria-label="Move Item 2 down">↓</button>
+  </li>
+</ul>
+```
+
+Also applies to sliders, map panning, colour pickers, and similar drag-based widgets, always provide an equivalent click/tap or keyboard path.
+
+---
+
+## ARIA tabs
+
+Tabs require `role="tablist"`, `role="tab"`, and `role="tabpanel"` with proper `aria-selected`, `aria-controls`, and keyboard support.
+
+```html
+<div role="tablist" aria-label="Product information">
+  <button role="tab" id="tab-1" aria-selected="true"
+          aria-controls="panel-1">Description</button>
+  <button role="tab" id="tab-2" aria-selected="false"
+          aria-controls="panel-2" tabindex="-1">Reviews</button>
+</div>
+<div role="tabpanel" id="panel-1" aria-labelledby="tab-1">
+  <!-- Panel content -->
+</div>
+<div role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>
+  <!-- Panel content -->
+</div>
+```
+
+Arrow keys should move focus between tabs; the active tab receives `tabindex="0"` while inactive tabs use `tabindex="-1"`.
+
+---
+
+## Live regions and notifications
+
+Use `aria-live` to announce dynamic content changes to screen readers without moving focus.
+
+```html
+<!-- Status updates (polite, waits for pause in speech) -->
+<div id="polite-announcer" aria-live="polite" aria-atomic="true" class="status">
+  <!-- Content updates announced to screen readers -->
+</div>
+
+<!-- Urgent alerts (assertive, interrupts) -->
+<div id="assertive-announcer" role="alert" aria-live="assertive">
+  <!-- Interrupts current announcement -->
+</div>
+```
+
+```javascript
+function showNotification(message, type = 'polite') {
+  const container = document.getElementById(`${type}-announcer`);
+  container.textContent = '';
+  requestAnimationFrame(() => {
+    container.textContent = message;
+  });
+}
+```
+
+Clear the container before writing to ensure the same message triggers a new announcement.

package/skills/antislop-human/references/WCAG.md

@@ -0,0 +1,127 @@
+# WCAG 2.2 Quick Reference
+
+> Reference for antislop. Adapted from the MIT-licensed web-quality-skills by Addy Osmani (https://github.com/addyosmani/web-quality-skills); see LICENSE-web-quality-skills in the skill folder.
+
+## Success criteria by level
+
+### Level A (minimum)
+
+| Criterion | Description |
+|-----------|-------------|
+| **1.1.1** Non-text Content | All images, icons have text alternatives |
+| **1.2.1** Audio-only/Video-only | Provide transcript or audio description |
+| **1.2.2** Captions | Video with audio has captions |
+| **1.2.3** Audio Description | Video has audio description |
+| **1.3.1** Info and Relationships | Information conveyed through presentation is available programmatically |
+| **1.3.2** Meaningful Sequence | Reading order is logical |
+| **1.3.3** Sensory Characteristics | Instructions don't rely solely on shape, color, size, location, orientation, or sound |
+| **1.4.1** Use of Color | Color is not the only visual means of conveying information |
+| **1.4.2** Audio Control | Audio playing automatically can be paused/stopped |
+| **2.1.1** Keyboard | All functionality available via keyboard |
+| **2.1.2** No Keyboard Trap | Keyboard focus can be moved away from any component |
+| **2.1.4** Character Key Shortcuts | Single-key shortcuts can be turned off or remapped |
+| **2.2.1** Timing Adjustable | Time limits can be extended |
+| **2.2.2** Pause, Stop, Hide | Moving/blinking content can be paused |
+| **2.3.1** Three Flashes | Nothing flashes more than 3 times per second |
+| **2.4.1** Bypass Blocks | Skip link or landmark navigation available |
+| **2.4.2** Page Titled | Pages have descriptive titles |
+| **2.4.3** Focus Order | Focus order preserves meaning |
+| **2.4.4** Link Purpose | Link purpose clear from link text or context |
+| **2.5.1** Pointer Gestures | Multi-point gestures have single-pointer alternatives |
+| **2.5.2** Pointer Cancellation | Down-event doesn't trigger action (use up-event or click) |
+| **2.5.3** Label in Name | Accessible name contains visible label text |
+| **2.5.4** Motion Actuation | Motion-triggered functions have alternatives |
+| **3.1.1** Language of Page | Default language specified in HTML |
+| **3.2.1** On Focus | Focus doesn't trigger unexpected changes |
+| **3.2.2** On Input | Input doesn't trigger unexpected changes |
+| **3.2.6** Consistent Help | Help mechanisms appear in the same relative order across pages |
+| **3.3.1** Error Identification | Input errors clearly described |
+| **3.3.2** Labels or Instructions | Form inputs have labels or instructions |
+| **3.3.7** Redundant Entry | Information previously entered is auto-populated or available to select |
+| **4.1.2** Name, Role, Value | UI components have accessible names and correct roles |
+
+### Level AA (standard)
+
+| Criterion | Description |
+|-----------|-------------|
+| **1.2.4** Captions (Live) | Live audio has captions |
+| **1.2.5** Audio Description | Pre-recorded video has audio description |
+| **1.3.4** Orientation | Content doesn't restrict orientation |
+| **1.3.5** Identify Input Purpose | Input purpose can be programmatically determined |
+| **1.4.3** Contrast (Minimum) | 4.5:1 for normal text, 3:1 for large text |
+| **1.4.4** Resize Text | Text can be resized to 200% without loss of functionality |
+| **1.4.5** Images of Text | Text used instead of images of text |
+| **1.4.10** Reflow | Content reflows at 320px width without horizontal scroll |
+| **1.4.11** Non-text Contrast | UI components have 3:1 contrast |
+| **1.4.12** Text Spacing | Content adapts to text spacing changes |
+| **1.4.13** Content on Hover/Focus | Additional content is dismissible, hoverable, persistent |
+| **2.4.5** Multiple Ways | Multiple ways to find pages |
+| **2.4.6** Headings and Labels | Headings and labels are descriptive |
+| **2.4.7** Focus Visible | Focus indicator is visible |
+| **2.4.11** Focus Not Obscured (Minimum) | Focused element is not entirely hidden by author-created content |
+| **2.5.7** Dragging Movements | Dragging actions have single-pointer alternatives |
+| **2.5.8** Target Size (Minimum) | Interactive targets are at least 24×24 CSS pixels (with exceptions) |
+| **3.1.2** Language of Parts | Language changes are marked |
+| **3.2.3** Consistent Navigation | Navigation is consistent across pages |
+| **3.2.4** Consistent Identification | Same functionality uses same labels |
+| **3.3.3** Error Suggestion | Error corrections suggested when known |
+| **3.3.4** Error Prevention (Legal) | Actions can be reversed or confirmed |
+| **3.3.8** Accessible Authentication (Minimum) | No cognitive function test for login unless an alternative or assistance is provided |
+| **4.1.3** Status Messages | Status messages announced to screen readers |
+
+### Level AAA (enhanced)
+
+| Criterion | Description |
+|-----------|-------------|
+| **1.2.6** Sign Language (Prerecorded) | Pre-recorded video has a sign language interpretation |
+| **1.2.7** Extended Audio Description (Prerecorded) | Video pauses long enough for audio description to convey the visuals |
+| **1.2.8** Media Alternative (Prerecorded) | A text alternative covers everything the pre-recorded media shows |
+| **1.2.9** Audio-only (Live) | Live audio-only content has a text alternative |
+| **1.3.6** Identify Purpose | Icons and regions have a programmatically determined purpose |
+| **1.4.6** Contrast (Enhanced) | 7:1 for normal text, 4.5:1 for large text |
+| **1.4.7** Low or No Background Audio | Speech stays understandable over background sound |
+| **1.4.8** Visual Presentation | Foreground/background colors can be selected |
+| **1.4.9** Images of Text (No Exception) | No images of text |
+| **2.1.3** Keyboard (No Exception) | All functionality keyboard accessible |
+| **2.2.3** No Timing | No time limits |
+| **2.2.4** Interruptions | Interruptions can be postponed |
+| **2.2.5** Re-authenticating | Data preserved on re-authentication |
+| **2.2.6** Timeouts | Users warned about data loss from inactivity |
+| **2.3.2** Three Flashes | No content flashes more than 3 times |
+| **2.3.3** Animation from Interactions | Motion animation can be disabled |
+| **2.4.8** Location | User location within site is available |
+| **2.4.9** Link Purpose (Link Only) | Link purpose clear from link text alone |
+| **2.4.10** Section Headings | Sections have headings |
+| **2.4.12** Focus Not Obscured (Enhanced) | No part of the focused element is hidden by author-created content |
+| **2.4.13** Focus Appearance | Focus indicator has sufficient area, contrast, and is not obscured |
+| **2.5.5** Target Size (Enhanced) | Interactive targets are at least 44×44 CSS pixels |
+| **2.5.6** Concurrent Input Mechanisms | Content does not restrict which input modality a person uses |
+| **3.1.3** Unusual Words | Definitions available for unusual words |
+| **3.1.4** Abbreviations | Abbreviations expanded |
+| **3.1.5** Reading Level | Alternative content for complex text |
+| **3.1.6** Pronunciation | Pronunciation available where needed |
+| **3.2.5** Change on Request | Changes initiated only by user |
+| **3.3.5** Help | Context-sensitive help available |
+| **3.3.6** Error Prevention (All) | All form submissions can be reviewed |
+| **3.3.9** Accessible Authentication (Enhanced) | No cognitive function test for login (no object or personal content recognition exceptions) |
+
+## What changed from 2.1 to 2.2
+
+| Change | Criterion | Level |
+|--------|-----------|-------|
+| **Removed** | 4.1.1 Parsing | A |
+| **Added** | 2.4.11 Focus Not Obscured (Minimum) | AA |
+| **Added** | 2.4.12 Focus Not Obscured (Enhanced) | AAA |
+| **Added** | 2.4.13 Focus Appearance | AAA |
+| **Added** | 2.5.7 Dragging Movements | AA |
+| **Added** | 2.5.8 Target Size (Minimum) | AA |
+| **Added** | 3.2.6 Consistent Help | A |
+| **Added** | 3.3.7 Redundant Entry | A |
+| **Added** | 3.3.8 Accessible Authentication (Minimum) | AA |
+| **Added** | 3.3.9 Accessible Authentication (Enhanced) | AAA |
+
+## Sources
+
+- [WCAG 2.2 W3C Recommendation](https://www.w3.org/TR/WCAG22/)
+- [WCAG 2.2 Quick Reference](https://www.w3.org/WAI/WCAG22/quickref/)
+- [What's New in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)

package/skills/antislop-layoutmobile/SKILL.md

@@ -0,0 +1,170 @@
+---
+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 preview.
+
+### 100vh Sections
+
+- **Tell:** hero and section heights set to `100vh`, so a section fills the whole phone screen and pushes everything else below the fold.
+- **Why:** a full-viewport section designed for a desktop monitor becomes a giant slab on a phone, and `100vh` includes the browser chrome, so it overflows the visible area on mobile browsers. It dominates the layout instead of introducing it (R-03).
+- **Fix:** let sections size to their content (`auto`), or use the dynamic viewport unit (`dvh`) where a real full-height section is intended. Nothing below the fold should be an accident of viewport units.
+
+### Huge Empty Padding
+
+- **Tell:** desktop-scale section padding (96px, 128px) kept on mobile, creating tall empty gaps between sections on a phone.
+- **Why:** padding tuned for a large canvas turns into wasted vertical space on a small one. The page scrolls through emptiness, and the rhythm R-05 calls for becomes a void between every section.
+- **Fix:** reduce section padding at the breakpoint to a mobile register (roughly half or less), and check that the page scrolls at a natural density instead of through deserts of space.
+
+## Grids & Stacking
+
+### Columns That Don't Collapse
+
+- **Tell:** a multi-column grid keeps its side-by-side columns on mobile, so the columns shrink, the text wraps awkwardly, and elements collide.
+- **Why:** a grid is a promise about how much width is available. When the viewport narrows and the grid does not re-stack, every column gets a sliver, text becomes unreadable, and cards overlap (R-03). This is the collision failure: desktop's side-by-side becomes mobile's pileup.
+- **Fix:** collapse the grid to a single reflowing column at the breakpoint. Side-by-side becomes stacked, and each item gets the full width again. Re-verify at a narrow width (R-35).
+
+### Fixed-Width Grid
+
+- **Tell:** `grid-template-columns` set in fixed px, or grid areas that cannot reflow, so the grid stays rigid when the viewport shrinks.
+- **Why:** a fixed-px track does not care about the viewport; it keeps its width and forces overflow or collision. The layout was built for one canvas and cannot change shape (R-03).
+- **Fix:** size tracks with `minmax()` or `auto-fit` and `auto-fill` so columns shrink and wrap with the content, and define grid areas that collapse at the breakpoint. The grid should be fluid by default, rigid only where a fixed size is deliberate.
+
+### Forced 12-Column
+
+- **Tell:** a 12-column grid forced onto mobile content that needs one or two columns, so spans look arbitrary and the math fights the layout.
+- **Why:** a 12-column system is for a wide canvas with many columns of content. Forcing it on a phone makes every element a fraction of an invisible grid the user never sees, and the content gets fitted to the grid instead of the grid to the content (R-03).
+- **Fix:** let columns follow the content. On mobile the content usually wants one column, or two at most; the 12-column span only makes sense where the layout genuinely has that many things side by side.
+
+## Overflow
+
+### Horizontal Scroll Leak
+
+- **Tell:** the page scrolls sideways because some element is wider than the viewport: a table, a code block, an image, a long unbroken string.
+- **Why:** horizontal scrolling is a broken promise on mobile. The user cannot see where the page ends, and the layout visibly spills off the screen (R-03). It is the most common overflow slop because the offender is off-screen in the desktop preview and goes unnoticed until a phone opens it.
+- **Fix:** find the element wider than the viewport (a table that needs a reflow layout or a scroll container, a code block that wraps, images with `max-width: 100%`), then contain or reflow it. Verify the whole page has zero horizontal scroll at the narrowest target (R-35).
+
+### Overflow Hidden Clipping
+
+- **Tell:** `overflow: hidden` on a container that clips content at narrow widths, hiding text or controls instead of letting them fit.
+- **Why:** clipping is hiding a failure. When a container cuts off its content because the layout cannot fit it, the user loses information and interaction (R-03). The zoom and text-resize angle on this is covered by `antislop-human`.
+- **Fix:** let the content reflow instead of clipping: allow the container to grow, wrap its content, or collapse it at the breakpoint. Clip only where cropping is the design intent (like a thumbnail), never where it hides content.
+
+### Fixed-Width Children
+
+- **Tell:** flex or grid children with a fixed px width or `min-width` that burst out of their parent on a narrow screen.
+- **Why:** a child sized in absolute px does not care how much room its parent has. On mobile the parent shrinks and the child stays wide, so it overflows the container and the page (R-03).
+- **Fix:** size children with relative units and let them wrap (`flex-wrap`, fluid widths, `min-width: 0` on grid children). A child should be allowed to shrink with its container, not hold a desktop size.
+
+## Tap Targets
+
+### Under-Sized Targets
+
+- **Tell:** buttons, links, and controls smaller than about 44 x 44 px, easy to hit on desktop with a cursor but hard to hit with a thumb.
+- **Why:** a desktop cursor has pixel accuracy; a thumb does not. A target that is fine at 16px becomes an exercise in frustration on a phone, and it fails the promise that the UI is usable on mobile (R-03).
+- **Fix:** give interactive targets a minimum touch area of 44 x 44 px, using padding or a larger hit box even when the visual is smaller. Verify the whole set of controls at a phone width (R-35).
+
+### Targets Too Close
+
+- **Tell:** 44px targets packed together with no gap, so a thumb tap hits the wrong one.
+- **Why:** target size matters only with target spacing. Two large controls touching each other behave like one large control: the user cannot reliably pick either (R-03).
+- **Fix:** leave a clear gap between adjacent interactive targets, at least a few px and ideally enough that the finger press area does not overlap. Spacing is the other half of tappability.
+
+### Hover-Only Interactions
+
+- **Tell:** menus, reveals, and tooltips that exist only on hover, so a touch user can never open them.
+- **Why:** there is no hover on a touchscreen. An interaction that only responds to hover simply does not exist for mobile users, and any control that relies on it is a dead end (R-03).
+- **Fix:** give every hover-only interaction a tap equivalent: a menu that opens on hover also opens on tap, a reveal also shows on click, and interactive elements show visible `:active` feedback so a tap registers. Test by using the UI with touch alone (R-35).
+
+## Mobile Navigation
+
+### Nav That Stays Desktop
+
+- **Tell:** the desktop top bar with its row of links kept side by side on mobile, so the links crowd, wrap into two rows, or spill past the viewport.
+- **Why:** a desktop nav is sized for a wide canvas. Kept as a row on a phone it becomes a mess of cramped links, and it is the first thing a mobile user meets (R-03). Navigation is where reflow matters most: the user has to find where to go before they can go anywhere.
+- **Fix:** collapse the nav into a mobile pattern at the breakpoint: a bottom nav for the handful of primary destinations, or a menu for the rest. The links reflow out of the row, and the primary destinations stay one thumb tap away. Verify it holds at a narrow width (R-35).
+
+### The Bare Hamburger
+
+- **Tell:** everything hidden behind a hamburger icon with no label and no hint, so a user never realizes the menu exists or cannot tell what it opens.
+- **Why:** a bare hamburger assumes the user already knows what the icon means and that a menu hides behind it. That is knowledge the mobile user may not have, and on mobile the hidden menu can hold the only way around the app (R-03).
+- **Fix:** keep the menu discoverable: label the hamburger ("Menu"), or keep the primary destinations visible and hide only the secondary ones. If a menu is the only way to reach something important, that reachability has to be obvious.
+
+### Bottom Nav That Eats Content
+
+- **Tell:** a fixed bottom nav bar that sits over the content, covering the last list items, the final button, or the form the user was trying to finish.
+- **Why:** a fixed bar takes real space on a small screen. If nothing reserves that space, the content scrolls under it and the user cannot reach what is hidden, especially at the very bottom of the page (R-03).
+- **Fix:** reserve the bar's height for the content: scroll padding on the page and safe-area insets where the device needs them, so nothing important is ever hidden behind it. Verify at a narrow width that the last item is reachable (R-35).
+
+### Sticky Nav Steals the Screen
+
+- **Tell:** a sticky header or tall bottom bar that holds a large fixed height, so a big slice of the phone screen is always taken by navigation.
+- **Why:** on a small viewport every fixed pixel of chrome is a pixel of content lost. A tall sticky header turns the visible area into a letterbox and the content into a sliver (R-03).
+- **Fix:** keep fixed nav compact: small enough that the content stays dominant, and collapse or shrink it on scroll where appropriate. Navigation should be present, not the main occupant of the screen.
+
+## Layoutmobile Skill Checklist
+
+Run these alongside the core Delivery Gate when the task is mobile or responsive layout work. All answers must be **yes**:
+
+- [ ] Does the layout reflow into a distinct mobile state rather than a squeezed desktop? (R-03)
+- [ ] Are there defined states across the width range, not just phone and desktop, so tablet and small-laptop widths are never a stretched stack or a crammed grid? (R-03, R-35)
+- [ ] Do sizes (type, padding, gaps, section heights) use a mobile scale, not desktop sizes unchanged? (R-03, R-05)
+- [ ] Do multi-column grids collapse and stack instead of colliding? (R-03)
+- [ ] Is there no horizontal overflow and nothing clipped? (R-03)
+- [ ] Are interactive targets at least 44 x 44 px with spacing between them? (R-03)
+- [ ] Do hover-only interactions have a tap equivalent with visible feedback? (R-03)
+- [ ] Does the navigation reflow into a mobile pattern (bottom nav or menu) instead of a squeezed desktop row? (R-03)
+- [ ] Do fixed nav bars (bottom nav, sticky headers) never cover content and respect safe areas? (R-03)
+- [ ] Is the layout verified at mobile breakpoints? (R-35)

package/skills/antislop-ui/LICENSE-web-quality-skills

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Addy Osmani
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.