@harness-engineering/cli 1.23.2 → 1.24.1

package/dist/agents/skills/gemini-cli/design-readability/SKILL.md

@@ -0,0 +1,183 @@
+# Readability
+
+> Optimizing for reading — line length (measure), line height (leading), paragraph spacing, text alignment, hyphenation, and reading patterns (F-pattern, Z-pattern)
+
+## When to Use
+
+- Setting body text styles for any content-heavy page (documentation, blogs, articles)
+- Configuring `max-width` on text containers to control line length
+- Choosing `line-height` values for body text, headings, and captions
+- Deciding between left, center, right, or justified text alignment
+- Debugging layouts where users report text is "hard to read" or "tiring"
+- Designing for screens where sustained reading is the primary activity
+
+## Instructions
+
+1. **Set line length (measure) to 45-75 characters per line.** This is the single most impactful readability setting. The research is unambiguous: lines shorter than 45 characters cause excessive line breaks and choppy reading; lines longer than 75 characters cause the eye to lose its place when returning to the left margin.
+
+   **Concrete values for common body sizes:**
+   | Font Size | Font | Ideal Max-Width | ~Characters |
+   |-----------|------|----------------|-------------|
+   | 16px | Inter | 640-680px | 65-70 |
+   | 16px | Georgia | 600-640px | 62-67 |
+   | 18px | system-ui | 700-740px | 63-68 |
+   | 21px | Georgia | 780-820px | 60-65 |
+
+   **Decision procedure**: Set `max-width` on your text container. Paste a paragraph of real content. Count characters in the longest line. Adjust until you hit 60-70 characters. The exact pixel value depends on font, size, and letter-spacing — there is no universal pixel number.
+
+   **Two-column exception**: When text is set in narrow columns (sidebars, cards, multi-column layouts), 35-45 characters per line is acceptable because the vertical distance between lines is shorter, making the return sweep easier.
+
+2. **Set line-height (leading) based on context.** Leading is the vertical distance between baselines. Too tight and lines collide visually; too loose and the text disintegrates into separate strips.
+
+   | Context              | Line-Height | Rationale                                                              |
+   | -------------------- | ----------- | ---------------------------------------------------------------------- |
+   | Body text (16-18px)  | 1.5-1.65    | Optimal for sustained reading                                          |
+   | Large body (20-24px) | 1.4-1.5     | Larger text needs proportionally less leading                          |
+   | Headings (24-48px)   | 1.1-1.25    | Tight leading keeps multi-line headings cohesive                       |
+   | Display text (48px+) | 1.0-1.1     | Very large text looks disconnected with normal leading                 |
+   | Captions (12-14px)   | 1.4-1.5     | Small text needs generous leading for legibility                       |
+   | Code blocks          | 1.5-1.7     | Programmers scan vertically; generous leading aids line identification |
+
+   **The inverse relationship**: as font size increases, optimal line-height ratio decreases. Stripe demonstrates this: body at 16px uses line-height 1.40, but display headlines at 56px use line-height 1.03. The absolute leading increases (22.4px vs 57.7px) but the ratio tightens dramatically.
+
+3. **Set paragraph spacing to 0.5-1.0em between paragraphs.** Use `margin-bottom` on paragraphs, not double line breaks. The spacing should be large enough to signal "new paragraph" but not so large that the text feels disconnected.
+   - **Standard**: `margin-bottom: 1em` (one blank line's worth) — used by most systems
+   - **Compact**: `margin-bottom: 0.5em` — for data-dense interfaces or when vertical space is premium
+   - **Generous**: `margin-bottom: 1.5em` — for editorial/literary content with wide line spacing
+   - **Rule**: paragraph spacing should be noticeably larger than line-height but smaller than section spacing
+
+4. **Default to left-aligned text for body content in LTR languages.** Alignment choices:
+   - **Left (start)**: Default for all body text. The ragged right edge is natural and provides unique line shapes that help the eye track position. Always use for body text.
+   - **Center**: Only for short text blocks (1-3 lines) — headings, hero text, call-to-action buttons. Never for paragraphs. Centered body text destroys the left anchor the eye uses for line returns.
+   - **Right (end)**: Reserved for specific UI contexts — numeric columns in tables (right-align numbers for decimal alignment), dates, prices. Never for body text.
+   - **Justified**: Creates clean block edges but introduces variable word spacing ("rivers" of white space) unless the browser supports quality hyphenation. Use only when `hyphens: auto` is set AND the language has good hyphenation dictionaries (English, German, French — yes; Japanese, Chinese — not applicable). Even then, prefer left-aligned.
+
+5. **Understand reading patterns to structure content.** Eye-tracking research (Nielsen Norman Group) identified two primary scanning patterns:
+
+   **F-Pattern** (content-heavy pages):
+   - Users read the first line or two fully (horizontal bar 1)
+   - Eyes drop down and read a shorter horizontal segment (horizontal bar 2)
+   - Users scan the left edge vertically, picking up first words of each line/section
+   - **Implication**: put the most important information in the first two lines of each section and at the start of each paragraph. Front-load sentences with key terms.
+
+   **Z-Pattern** (sparse layouts, landing pages):
+   - Eyes move: top-left -> top-right -> diagonal to bottom-left -> bottom-right
+   - **Implication**: place the logo/brand top-left, the CTA top-right, supporting info bottom-left, primary action bottom-right
+
+6. **Optimize the relationship between font size, line-height, and measure.** These three properties are interdependent — changing one requires reconsidering the others:
+   - **Increase font size** -> line-height ratio can decrease, but measure (px) should increase to maintain character count
+   - **Increase line-height** -> measure can increase slightly (more leading makes longer lines easier to track)
+   - **Decrease measure** -> line-height can decrease slightly (shorter lines need less leading because the return sweep is shorter)
+
+## Details
+
+### Readability Configurations from Leading Design Systems
+
+**Stripe Documentation**
+
+- Body: 16px, Inter, line-height 1.625 (26px), max-width ~680px (~70 characters)
+- Why it works: the generous 1.625 line-height compensates for Inter's tall x-height, which can make lines feel cramped at standard 1.5 leading. The 680px max-width keeps lines at exactly 68-72 characters.
+
+**Apple Developer Documentation**
+
+- Body: 17px, SF Pro Text, line-height 1.47 (25px), max-width ~800px (~72 characters)
+- Apple uses a slightly larger body size (17px vs the industry standard 16px) and a moderately generous line-height. The wider max-width is acceptable because the larger font size maintains character count within range.
+
+**Medium / Reading-Optimized Platforms**
+
+- Body: 21px, charter/Georgia fallback, line-height 1.58 (33px), max-width ~680px (~52 characters)
+- Medium uses an unusually large body size with generous leading. The result is a "book-like" reading experience — fewer characters per line (52 vs the recommended 65) creates a faster-paced rhythm appropriate for the platform's short-to-medium article format.
+
+**Material Design 3**
+
+- Body Large: 16px, Roboto, line-height 1.5 (24px)
+- Body Medium: 14px, Roboto, line-height 1.43 (20px)
+- Body Small: 12px, Roboto, line-height 1.33 (16px)
+- Material uses tighter line-heights as sizes decrease — the opposite of best practice for extended reading. This works because Material targets UI labels and short descriptions, not sustained reading.
+
+### The Measure-Leading Interaction
+
+Practical table for common configurations:
+
+| Scenario         | Font Size | Line-Height | Max-Width | Chars/Line |
+| ---------------- | --------- | ----------- | --------- | ---------- |
+| Documentation    | 16px      | 1.6         | 680px     | 68         |
+| Blog/editorial   | 18px      | 1.7         | 720px     | 62         |
+| Literary reading | 21px      | 1.6         | 680px     | 52         |
+| Dashboard text   | 14px      | 1.5         | 480px     | 55         |
+| Card description | 14px      | 1.45        | 320px     | 38         |
+| Code block       | 14px      | 1.6         | 880px     | 100        |
+
+Code blocks are the exception to the 75-character rule — developers expect wide lines and horizontal scroll, and the monospace font provides character-level position tracking that proportional fonts cannot.
+
+### Hyphenation and Justification
+
+Justified text is the default in print because page layout engines (InDesign, TeX) have sophisticated paragraph-level justification algorithms. Web browsers do not — they justify line by line, producing inferior results.
+
+If you must use justified text on the web:
+
+```css
+.justified-text {
+  text-align: justify;
+  hyphens: auto;
+  -webkit-hyphens: auto;
+  word-break: break-word; /* prevent overflow on long words */
+  overflow-wrap: break-word;
+  max-width: 680px; /* justified text requires controlled measure */
+}
+```
+
+Even with these settings, justified web text will have visible rivers in narrow columns. If the container is narrower than 500px, never justify.
+
+### Anti-Patterns
+
+1. **Full-width body text.** Setting body text at `width: 100%` on a 1920px monitor produces lines of 160+ characters. The eye cannot track back to the correct next line after such a long horizontal sweep. This is the most common readability failure on the web. Fix: `max-width: 65ch` or a pixel equivalent based on your font.
+
+2. **Cramped leading.** Line-height of 1.0-1.2 for body text (16px font, 16-19px line-height) causes ascenders and descenders of adjacent lines to collide visually. The text feels dense, claustrophobic, and tiring. Common cause: inheriting `line-height: 1.2` from a CSS reset that was designed for headings, not body text. Fix: set body line-height explicitly to 1.5-1.65.
+
+3. **Justified text without hyphenation.** Justified text distributes extra space between words to fill the line. Without hyphenation, long words force enormous gaps. On narrow columns (300-400px), individual lines can have gaps wider than the words themselves, creating "rivers" of white space that flow vertically through the paragraph. Fix: either add `hyphens: auto` or switch to `text-align: left`.
+
+4. **Centered body paragraphs.** Centering more than 3 lines of text destroys the fixed left edge that the eye uses to locate the start of each new line. Reading speed drops by 10-20% (per Nielsen Norman Group research). Fix: center only headings, short taglines, and CTAs. Left-align all body paragraphs.
+
+5. **Uniform line-height across all sizes.** Setting `line-height: 1.5` globally means a 48px heading gets 72px of leading (excessive, text floats apart) while 12px captions get 18px (possibly too tight). Fix: define line-height per text role, with the ratio decreasing as font size increases.
+
+### Real-World Examples
+
+**Fixing a Documentation Site**
+Before: 14px body, line-height 1.3, full-width (1200px container), justified alignment. Users reported "eye strain" and "losing my place."
+After: 16px body, line-height 1.6, max-width 680px centered in the layout, left-aligned. Bounce rate decreased 15%, average time on page increased 25%. The changes were purely typographic — no content, layout, or color changes.
+
+**Optimizing a Reading App**
+A Kindle-style web reader tested 3 configurations with 500 users:
+
+- **Config A**: 16px, line-height 1.5, 600px width (65 chars) — 4.2 min average reading time
+- **Config B**: 18px, line-height 1.6, 660px width (60 chars) — 3.9 min average reading time
+- **Config C**: 21px, line-height 1.7, 680px width (52 chars) — 4.0 min average reading time
+  Config B won on reading speed. The 18px size with 1.6 leading hit the optimal balance — large enough for comfortable reading without reducing characters-per-line below 55.
+
+## Source
+
+- Bringhurst, Robert. _The Elements of Typographic Style_ — on measure and leading
+- Butterick, Matthew. _Butterick's Practical Typography_ — line length, line spacing, text alignment
+- Nielsen Norman Group — "F-Shaped Pattern for Reading Web Content" (2006, updated 2017)
+- Dyson, M.C. & Haselgrove, M. (2001). "The influence of reading speed and line length on the effectiveness of reading from screen"
+- WCAG 2.1 Success Criterion 1.4.8 — Visual Presentation (recommended line length, leading, alignment)
+
+## Process
+
+1. **Evaluate** — Measure the current line length (characters per line), line-height ratio, and paragraph spacing. Identify the reading pattern appropriate for the page type (F-pattern for content, Z-pattern for sparse layouts).
+2. **Apply** — Set max-width to achieve 45-75 characters per line. Set line-height appropriate to font size (1.5-1.65 for body, 1.1-1.25 for headings). Left-align body text. Add paragraph spacing at 0.5-1.0em.
+3. **Verify** — Count characters per line with real content. Check that the squint test shows clear paragraph separation. Confirm that line-height produces no visual collision between ascenders and descenders.
+
+## Harness Integration
+
+This is a knowledge skill. When activated, it provides readability optimization expertise for text layout decisions. Use these principles when setting `max-width`, `line-height`, `text-align`, `margin-bottom`, and `hyphens` properties. Cross-reference with `design-responsive-type` for viewport-adaptive adjustments and `design-content-density` for information-rich interfaces.
+
+## Success Criteria
+
+- Body text line length is 45-75 characters (measured with actual content, not estimated)
+- Line-height for body text is between 1.5 and 1.65
+- Line-height for headings is between 1.1 and 1.25
+- Body text is left-aligned (not centered or justified without hyphenation)
+- Paragraph spacing is between 0.5em and 1.0em
+- No text container spans full viewport width without a max-width constraint

package/dist/agents/skills/gemini-cli/design-readability/skill.yaml

@@ -0,0 +1,39 @@
+name: design-readability
+version: "1.0.0"
+description: Optimizing for reading — line length, leading, paragraph spacing, alignment, F-pattern/Z-pattern
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - design-typography-fundamentals
+  - design-content-density
+  - design-responsive-type
+  - ux-plain-language
+  - ux-writing-for-scanning
+stack_signals: []
+keywords:
+  - readability
+  - line length
+  - measure
+  - leading
+  - line height
+  - paragraph spacing
+  - alignment
+  - F-pattern
+  - Z-pattern
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/gemini-cli/design-responsive-strategy/SKILL.md

@@ -0,0 +1,157 @@
+# Responsive Strategy
+
+> Responsive as a design decision — content-first breakpoints, progressive disclosure, and treating every viewport as a first-class design target
+
+## When to Use
+
+- Planning a new layout that must work from 320px mobile to 2560px ultrawide
+- Deciding where to set breakpoints and what changes at each one
+- Evaluating whether a responsive implementation degrades gracefully or just shrinks
+- Building a design system that needs consistent responsive behavior across components
+- Deciding what content to show, hide, or reorganize at different viewport sizes
+
+## Instructions
+
+1. **Set breakpoints where the content breaks, not at device widths.** Device-based breakpoints (320px for iPhone, 768px for iPad, 1024px for laptop) create designs that work on today's devices and break on tomorrow's. Content-first breakpoints are future-proof:
+   - **Procedure:** Start with your content at the narrowest viewport (320px). Slowly widen the browser. The moment the layout looks awkward — too much whitespace, lines too long, elements too spread out — that is a breakpoint. Set it at that width.
+   - **Typical results:** Most designs naturally break at 3-5 points, usually around 480-560px (single column exhausted), 720-840px (two-column becomes viable), and 1080-1280px (full desktop layout possible).
+   - **Material Design 3 breakpoints:** Compact (0-599dp), Medium (600-839dp), Expanded (840-1199dp), Large (1200-1599dp), Extra-large (1600dp+). These are content-driven ranges, not device names.
+   - **Stripe's documentation:** Sidebar appears at 768px — not because "that is tablet width" but because below 768px the content area would be too narrow for code examples alongside a sidebar.
+
+2. **Design mobile-first as a constraint exercise.** Mobile-first is not about mobile users — it is about forcing prioritization:
+   - **At 320px, you can fit one idea.** This forces you to decide: what is the single most important thing on this screen? That answer should inform the desktop layout too — the most important thing on mobile should be the most prominent thing on desktop.
+   - **Content priority list:** Before designing any viewport, write a ranked list of every content element on the page. This list is your source of truth for all viewport sizes. Mobile shows items 1-5 prominently. Tablet adds items 6-10. Desktop shows all 15 items but still prioritizes 1-5.
+   - **Airbnb's search results:** Mobile shows listing photo, price, rating, and title (the 4 most important data points). Tablet adds the map view as a side panel. Desktop adds filters, expanded reviews, and host information. The core 4 data points are prominent at every size.
+
+3. **Apply the five responsive patterns.** Every responsive layout change falls into one of these patterns:
+   - **Reflow:** Multi-column becomes single-column. The most common pattern. A 3-card row becomes a single-card stack. Airbnb's listing grid: 4 columns at 1128px+, 3 at 950px, 2 at 550px, 1 below 550px.
+   - **Stack:** Side-by-side elements become vertically stacked. Text + image becomes image on top, text below. Stripe's feature sections: image-left/text-right at desktop becomes image-top/text-bottom on mobile.
+   - **Reveal/Hide:** Content appears or disappears at breakpoints. Navigation: full horizontal nav at desktop, hamburger menu at mobile. Filters: sidebar filters at desktop, modal/drawer at mobile. Vercel's dashboard: deployment details visible at desktop, tap-to-expand on mobile.
+   - **Off-canvas:** Content slides in from the edge on demand. Sidebars, navigation drawers, filter panels. Material Design: navigation rail (visible icon bar) at medium, full drawer (off-canvas) at compact.
+   - **Resize:** Elements scale proportionally. Hero images, videos, embedded content. Percentage widths, max-width constraints, and aspect-ratio preservation.
+
+4. **Define what changes and what stays constant across breakpoints.** Not everything should respond:
+
+   **Changes across breakpoints:**
+   - Column count (4 → 8 → 12)
+   - Navigation pattern (bottom tab bar → side rail → expanded sidebar)
+   - Content visibility (progressive disclosure — more detail at larger sizes)
+   - Macro whitespace (section padding scales: 48px mobile → 64px tablet → 96px desktop)
+   - Component layout (horizontal → vertical stacking)
+
+   **Stays constant across breakpoints:**
+   - Brand identity (colors, typography family, logo)
+   - Content hierarchy (the most important element stays most important)
+   - Core functionality (a mobile user can do everything a desktop user can)
+   - Micro whitespace (button padding, icon gaps, input height)
+   - Touch targets (minimum 44x44px/48x48dp on all devices — this is not just a mobile concern; tablet and touch-laptop users exist at every viewport width)
+
+5. **Avoid layout cliffs.** A layout cliff is a dramatic, jarring change at a single pixel boundary:
+   - **Bad:** At 767px, full sidebar visible. At 768px, sidebar gone, content full-width. The user resizing their browser sees a sudden, disorienting jump.
+   - **Better:** Sidebar progressively narrows from 280px to 200px between 900-768px, then collapses to icons-only at 768px, then moves off-canvas at 600px. Three gradual transitions instead of one cliff.
+   - **Stripe's approach:** Between breakpoints, elements use fluid sizing (percentage widths, clamp(), flex-grow). The layout continuously adjusts, with breakpoints adding or removing elements rather than rearranging everything.
+   - **CSS technique:** Use `clamp(min, preferred, max)` for fluid values. Example: `padding: clamp(48px, 8vw, 96px)` provides smooth spacing adaptation without breakpoint jumps.
+
+6. **Test at the edges, not the centers.** Common mistake: designing for 375px (iPhone), 768px (iPad), 1440px (laptop). These are the centers of each range. Problems appear at the edges:
+   - **Critical test widths:** 320px (smallest viable mobile), 480px (large phone / small tablet boundary), 600px (Material compact/medium boundary), 768px (common tablet), 1024px (tablet/desktop boundary), 1280px (common laptop), 1920px (common desktop), 2560px (ultrawide).
+   - **The 1024px zone:** Many designs break here because it is too wide for a mobile layout but too narrow for a full desktop layout with sidebar. This is where a 2-column layout without sidebar or a collapsible sidebar earns its keep.
+   - **The 320px constraint:** Samsung Galaxy Fold and older Android devices go as narrow as 280-320px. If your layout breaks below 360px, 5-8% of Android users have a degraded experience.
+
+## Details
+
+### Content Priority Matrix
+
+Before responsive design decisions, fill out this matrix for every page:
+
+| Element          | Priority | Mobile           | Tablet           | Desktop          |
+| ---------------- | -------- | ---------------- | ---------------- | ---------------- |
+| Hero headline    | 1        | Full-width, 32px | Full-width, 40px | Contained, 56px  |
+| Primary CTA      | 2        | Sticky bottom    | Below hero       | Inline with hero |
+| Feature overview | 3        | Stacked cards    | 2-column grid    | 3-column grid    |
+| Social proof     | 4        | Hidden (tap)     | Below fold       | Sidebar or below |
+| Secondary nav    | 5        | Hamburger        | Icon rail        | Full sidebar     |
+| Footer links     | 6        | Accordion        | 2-column         | 4-column         |
+
+This matrix replaces guesswork. Every responsive decision traces back to a prioritized content need.
+
+### Responsive vs. Adaptive
+
+- **Responsive:** Fluid layouts that continuously adapt. Uses percentages, flex, grid, clamp(). One codebase, infinite viewport sizes. The standard approach for most web projects.
+- **Adaptive:** Distinct fixed layouts served at specific breakpoints. Uses media queries to swap between complete layout variants. Better for highly controlled experiences (email templates, app-like interfaces).
+- **Hybrid (most common in practice):** Fluid within ranges, with structural changes at breakpoints. Stripe uses this: content width is fluid between 768px and 1200px, but the layout structure (sidebar vs. no sidebar) changes at 768px.
+
+### Breakpoint Naming Convention
+
+Avoid device names. Use size categories:
+
+| Name     | Range       | Column Count | Use Case                            |
+| -------- | ----------- | ------------ | ----------------------------------- |
+| compact  | 0-599px     | 4            | Single-column, stacked layout       |
+| medium   | 600-839px   | 8            | Two-column, side panels possible    |
+| expanded | 840-1199px  | 12           | Full layout, sidebars, multi-column |
+| large    | 1200-1599px | 12           | Generous spacing, wider content     |
+| xlarge   | 1600px+     | 12           | Max-width container, ultrawide      |
+
+Material Design 3 uses this exact naming. Tailwind uses sm/md/lg/xl/2xl at 640/768/1024/1280/1536px.
+
+### Anti-Patterns
+
+1. **Device-width breakpoints.** Designing for "iPhone 14" (390px) and "iPad" (768px) instead of for content needs. New devices launch every year at new widths. Content-first breakpoints (set where the layout breaks, not where a device is) remain stable across device generations. Material Design has used the same breakpoint ranges since 2018 despite dozens of new Android devices.
+
+2. **Hiding critical content on mobile.** Removing features, navigation items, or information on mobile because "the screen is too small." Mobile users have the same goals as desktop users — often with more urgency (on the go, one-handed). Airbnb does not hide any booking functionality on mobile; it reorganizes it. The map, filters, reviews, and host info are all accessible — just through different interaction patterns (bottom sheet, drawer, expandable sections).
+
+3. **Responsive as afterthought.** Designing a complete desktop layout, then "making it responsive" by squeezing everything into a narrower column. This produces layouts where mobile feels like a broken desktop rather than a designed experience. Symptom: horizontal scrolling, text running off-screen, touch targets too small, images larger than the viewport. Fix: design mobile first, then enhance for desktop.
+
+4. **Breakpoint cliffs.** A single media query that changes 5+ properties at once, creating a jarring visual jump. At 767px the page looks one way; at 768px it looks completely different. Users on resizable windows (split-screen, desktop browsers) experience this as broken behavior. Fix: distribute changes across multiple breakpoints, use fluid values between breakpoints, and animate transitions.
+
+5. **Ignoring touch at non-mobile sizes.** Assuming that large viewports mean mouse input. iPad Pro is 1024px wide — a "desktop" width with touch input. Surface tablets, touch laptops, and Chromebooks exist at every viewport size. Minimum touch target (44x44px / 48x48dp) applies to ALL viewports, not just mobile.
+
+### Real-World Examples
+
+**Stripe Documentation:**
+
+- Compact (<768px): Single-column, hamburger navigation, code examples full-width
+- Medium (768-1199px): Sidebar appears (240px), content area takes remaining width
+- Expanded (1200px+): Sidebar + content + right-side "on this page" navigation
+- Breakpoint at 768px chosen because code examples need ~520px minimum to avoid horizontal scroll, and 768px - 240px sidebar = 528px content width
+
+**Material Design 3 Responsive Scaffolding:**
+
+- Compact: Bottom navigation bar (5 items max), no sidebar, single-column body
+- Medium: Navigation rail (icons only, 80dp wide), body content fills remaining width
+- Expanded: Navigation drawer (360dp wide, full labels), body with 2+ columns
+- Each transition point is designed, not just reflowed — the navigation fundamentally changes interaction model
+
+**Apple Product Pages:**
+
+- Hero: Full-bleed image at all sizes, text overlay scales from 32px to 72px via clamp()
+- Feature grid: 1 column at compact, 2 columns at medium, 3 columns at expanded
+- Comparison table: Full table at desktop, swipeable card carousel on mobile
+- The comparison table is not "hidden on mobile" — it is redesigned as a different component that serves the same purpose
+
+## Source
+
+- Ethan Marcotte, "Responsive Web Design" — the foundational text on responsive methodology
+- Luke Wroblewski, "Mobile First" — content prioritization through mobile-first design
+- Material Design 3 responsive layout guidelines (m3.material.io/foundations/layout)
+- Brad Frost, "Atomic Design" — component-level responsive patterns
+
+## Process
+
+1. **Prioritize** content with a numbered list before opening any design tool — mobile forces the ranking
+2. **Set** breakpoints by widening from 320px until the layout breaks, placing breakpoints at the break points
+3. **Validate** by testing at range edges (320px, 480px, 768px, 1024px, 1920px) and on at least one touch device at a "desktop" width
+
+## Harness Integration
+
+This is a knowledge skill. When activated, its content is injected into the system prompt to guide responsive layout decisions. It does not execute code or modify files. Use alongside `design-grid-systems` for column count at each breakpoint, `design-responsive-type` for fluid typography, and `design-content-density` for density adjustments across viewports.
+
+## Success Criteria
+
+- Breakpoints are set where content breaks, not at device widths
+- A content priority list exists and is reflected at all viewport sizes
+- Every responsive change maps to one of the five patterns (reflow, stack, reveal/hide, off-canvas, resize)
+- No content is hidden on mobile without an alternative access path
+- Touch targets meet 44x44px minimum at all viewport sizes, not just mobile
+- Layout transitions are gradual (no single breakpoint changes 5+ properties)
+- The design is tested at edge widths (320px, 1024px, 2560px), not just center widths

package/dist/agents/skills/gemini-cli/design-responsive-strategy/skill.yaml

@@ -0,0 +1,35 @@
+name: design-responsive-strategy
+version: "1.0.0"
+description: Responsive as design decision — content priority, progressive disclosure, design-first breakpoints
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - design-grid-systems
+  - design-responsive-type
+  - design-content-density
+stack_signals: []
+keywords:
+  - responsive design
+  - breakpoints
+  - mobile first
+  - content priority
+  - progressive disclosure
+  - adaptive
+  - viewport
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []