# Responsive Breakpoint Check > Reviews a layout's auto layout, constraints, and resizing settings to verify it will adapt correctly across specified breakpoints (e.g. mobile, tablet, desktop) rather than just checking how it looks at one frame size. Use when a design needs to work responsively, especially for Figma Sites or handoff to a responsive web build. - Skill: `qredence/responsive-breakpoint-check` (Agent Skill) - Install (CLI): `npx skillmds@latest add qredence/responsive-breakpoint-check` - Raw SKILL.md: https://api.skillmd.com/api/skills/qredence/responsive-breakpoint-check/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Design & Media - Author: Qredence (https://skillmd.com/u/qredence) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/qredence/responsive-breakpoint-check --- # Responsive Breakpoint Check ## Purpose Verify a layout is actually built to resize well across breakpoints, not just designed once at a single canvas size. ## Operating Role Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. ## Supported Context - Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. - Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. - Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. - Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. ## Activation Boundary - Before handoff for a responsive web build or Figma Sites publish - When a design only exists at one breakpoint and needs to be validated (or extended) for others ## Required Inputs - The breakpoints in scope (e.g. 375px mobile, 768px tablet, 1440px desktop) -- ask if not specified - Whether frames already exist per breakpoint, or only one exists and needs review for how it should adapt - If an input is missing but can be inferred safely from the selection, proceed and label the assumption. ## Fast Defaults - Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. - Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. - Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. - Compare equivalent content across breakpoints and flag where layout behavior, not just visual position, fails. ## Workflow 1. For each top-level frame, check that auto layout is used for the overall structure (rather than fixed absolute positioning), since that's what allows content to reflow. 2. Check resizing settings on key containers: do they hug, fill, or have a fixed size -- and is that the correct choice for how the container should behave at other widths (e.g. a sidebar that should stay fixed-width while content fills the rest)? 3. Check text containers can grow vertically (auto-height) so translated or wrapped text does not get clipped at narrower widths. 4. Check images/media have consistent scaling behavior (fill vs fit) so they do not distort or overflow at different widths. 5. Check constraints on any layers not in auto layout (e.g. decorative background elements) so they stay positioned correctly when their parent frame resizes. 6. If multiple breakpoint frames exist, compare them for structural consistency: is the same content present, just rearranged, or is content unexpectedly missing/duplicated at one breakpoint? 7. If only one breakpoint exists, propose how the layout should adapt at each other breakpoint in scope (what stacks, what hides, what resizes) before building it out. ## Figma Execution Limits - Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. - For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. - For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. - Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. - Preserve intentional exceptions that are labeled, annotated, or explained by the user. ## Guardrails - Flag any layer that will visibly break (clip, overlap, overflow) at a breakpoint; do not just describe general best practice. ## Finding Quality Rules - Lead with the highest-impact issues, not the order discovered. - Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. - Include severity only when it changes priority: Blocker, High, Medium, or Low. - Pair every finding with an exact fix, replacement, or next decision. - Separate confirmed findings from assumptions, recommendations, and unverified areas. ## Output Contract Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. - Skill-specific format: A per-breakpoint findings list: breakpoint -> issues found -> fix, plus a short note on what's working well already.