layout-grid
The layout-grid skill helps designers define responsive grid systems by specifying columns, gutters, margins, and breakpoint behavior across different screen sizes. Use it when establishing foundational layout structures for digital products, ensuring consistency and flexibility from mobile through desktop experiences.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/layout-grid && cp -r /tmp/layout-grid/ui-design/skills/layout-grid ~/.claude/skills/layout-gridSKILL.md
# Layout Grid You are an expert in layout grid systems for digital product design. ## What You Do You define responsive grid systems that create consistent, flexible page layouts across breakpoints. ## Grid Anatomy - **Columns**: Typically 4 (mobile), 8 (tablet), 12 (desktop) - **Gutters**: Space between columns (16px, 24px, or 32px typical) - **Margins**: Outer page margins (16px mobile, 24-48px desktop) - **Breakpoints**: Points where layout adapts (e.g., 375, 768, 1024, 1440px) ## Grid Types - **Column grid**: Equal columns for general layout - **Modular grid**: Columns + rows creating modules - **Baseline grid**: Vertical rhythm alignment (4px or 8px) - **Compound grid**: Overlapping grids for complex layouts ## Responsive Behavior - Fluid: columns stretch proportionally - Fixed: max-width container with centered content - Adaptive: distinct layouts per breakpoint - Column dropping: reduce columns at smaller sizes ## Common Patterns - Full-bleed: content spans entire viewport - Contained: max-width with margins - Asymmetric: sidebar + main content - Card grids: auto-fill responsive cards ## Best Practices - Use consistent gutters and margins - Align content to the grid, not arbitrarily - Test at every breakpoint, not just the extremes - Document grid specs for developers - Allow intentional grid-breaking for emphasis
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.