# Design Responsive Rules

> Trigger: responsive layout, media queries, mobile view, desktop layout, tablet break points, thumb zone. Scope: Multi-device layouts, breakpoints, mobile touch zones. Boundary: Excludes backend API design or database scaling.

- Skill: `coreyone/design-responsive-rules` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add coreyone/design-responsive-rules`
- Raw SKILL.md: https://api.skillmd.com/api/skills/coreyone/design-responsive-rules/raw
- Safety review: PASS (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: coreyone (https://skillmd.com/u/coreyone)
- Updated: 2026-08-19
- Page: https://skillmd.com/skills/coreyone/design-responsive-rules

---


# Responsive Web Design (2025) — Guidelines for Design + Design Engineering

## When to use

Use this skill when the task is primarily about design and this guidance is the most relevant operating rule set.

## When not to use

Do not use this skill as the primary guide when another skill has a tighter domain fit for the requested output.

## Trigger cues

- Request explicitly references `design-responsive-rules` or this source file.
- Request language includes terms like: design, responsive, rules.
- Keywords include: IA, usability, responsive layout, design system, aesthetic direction, motion.

## Routing boundary

- Primary for UX architecture, visual hierarchy, responsiveness, and interface behavior.
- Do not use as primary for backend architecture, threat modeling, or release operations.

## Inputs required

- Goal or task request
- Current constraints (time, scope, platform, risk)
- Existing artifacts (code, docs, screenshots, metrics) when available
- Source of truth: `subagents/rules/design/design-responsive-rules.md`

## Instructions

1. Read [references/source.md](references/source.md) first.
2. Extract the non-negotiable rules and translate them into a short execution checklist.
3. Apply the checklist to the current task, produce concrete outputs, and avoid abstract recommendations.
4. Validate outcomes with evidence (tests, screenshots, logs, diffs, or written audit findings).
5. Record decisions and tradeoffs so another engineer can continue without re-discovery.

## Completion gate

Before reporting completion, verify the applicable binary contracts in `evals/cases.json`: no horizontal scrolling at target widths, core tasks remain usable, breakpoints follow content failure rather than named devices, and reusable components adapt to their containers.

## Output format

- Primary decision/output: User flow clarity, interaction model, and visual system constraints.
- Summary: one-paragraph decision or result
- Actions: compact checklist with owners and status
- Evidence: links/paths to artifacts proving completion