Responsive Design
Guide layout, breakpoints, and input-specific interaction patterns so a solo-built UI works on phones, tablets, and desktops without a separate design team.
Overview
Responsive Design is an agent skill for the Build phase that designs adaptive layouts and interactions across screen sizes and input methods.
Install
npx skills add https://github.com/owl-listener/designer-skills --skill responsive-designWhat is this skill?
- Four strategies: fluid, adaptive, mobile-first, and content-first breakpoint selection
- Breakpoint bands from 375px phones through 1440px+ desktops
- Patterns: column drop, reflow, off-canvas, and priority+ overflow
- Input methods: 44px touch targets, hover, keyboard focus order, voice-friendly structure
- Fluid typography, srcset images, and art direction per breakpoint
- Documents four responsive strategies
- Lists four common breakpoint size bands
- Specifies 44px minimum touch targets
Adoption & trust: 590 installs on skills.sh; 1.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your UI looks fine on a laptop resize but breaks on real phones, tablets, or keyboard-only flows.
Who is it for?
Solo founders shipping SaaS dashboards, marketing sites, or mobile-friendly web apps without a dedicated UX team.
Skip if: Native-only mobile apps where platform HIG replaces web breakpoints, or pure backend API work with no UI surface.
When should I use this skill?
User needs adaptive layouts, breakpoint guidance, or cross-device interaction design while building frontend UI.
What do I get? / Deliverables
You get concrete responsive strategy, breakpoint, pattern, and accessibility choices you can implement in frontend code or design specs.
- Responsive strategy and breakpoint recommendations
- Pattern and input-method checklist for implementation
Recommended Skills
Journey fit
Responsive layout decisions belong in Build when you are implementing or refining the product surface customers actually touch. Frontend subphase is where breakpoints, fluid grids, and touch targets get specified before or alongside component work.
How it compares
Pairs with component libraries as layout philosophy—not a codegen or Figma plugin integration.
Common Questions / FAQ
Who is responsive-design for?
Indie builders and agent-assisted developers who own UI decisions and need breakpoint and pattern guidance while building.
When should I use responsive-design?
During Build frontend when defining layouts, choosing mobile-first versus adaptive approaches, or reviewing touch and keyboard behavior before ship.
Is responsive-design safe to install?
It is advisory design guidance with no prescribed shell or network calls—review the Security Audits panel on this page like any third-party skill.
SKILL.md
READMESKILL.md - Responsive Design
# Responsive Design You are an expert in designing interfaces that adapt gracefully across devices and contexts. ## What You Do You design adaptive layouts and interactions that work across all screen sizes, pixel densities, and input methods. ## Responsive Strategies - **Fluid**: Percentage-based widths, flexible within ranges - **Adaptive**: Distinct layouts at specific breakpoints - **Mobile-first**: Start with smallest, enhance upward - **Content-first**: Let content needs drive breakpoints ## Common Breakpoints - Small: 375-639px (phones) - Medium: 640-1023px (tablets) - Large: 1024-1439px (laptops) - Extra large: 1440px+ (desktops) ## Responsive Patterns - Column drop: reduce columns at smaller sizes - Reflow: stack horizontal elements vertically - Off-canvas: hide secondary content behind toggle - Priority+: show most important, overflow the rest ## Input Method Adaptation - Touch: 44px minimum targets, gesture support - Mouse: hover states, precise targeting - Keyboard: focus indicators, logical tab order - Voice: clear labels, logical structure ## Responsive Typography and Images - Fluid type scaling between breakpoints - Responsive images with appropriate srcset - Art direction: different crops per breakpoint ## Best Practices - Design for content, not devices - Test on real devices, not just browser resize - Consider landscape and portrait - Account for slow connections - Test with accessibility tools at each breakpoint