just-vibeGeneral · apply by default
/responsive
Fix layouts across screen sizes and input methods
This is an alias of ui-responsive and inherits its full workflow.
Use for layout adaptation, zoom and input differences; responsive is the same canonical workflow.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select responsive from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv responsive, /just-vibe responsive and /jv:responsive in Claude. See shortcut setup and context examples.
/just-vibe:responsive Fix the checkout layout for narrow screens, zoom, and touch input./just-vibe:responsive Repair a table at narrow widths and high zoom without hiding essential actions./just-vibe:responsive Review responsive source and screenshots without claiming real-device interaction coverage.What the agent does
- Reproduce the failure and inspect intrinsic sizes and flow to find the width constraint or overflow source.
- Adjust the layout at content-driven boundaries.
- Test nearby and intermediate widths, long text, keyboard focus and relevant orientation changes.
Inputs
- target layouts, content extremes, and supported input/viewport conditions.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Layout adaptation including touch, pointer, zoom, and keyboard effects.
- Writes
- Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.
- Mode
- Apply; target layouts, content extremes, and supported input/viewport conditions.
- Prerequisites
- Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
Expected output
- Layout fixes with a viewport/content/input matrix and observed reachability and overflow results.
How the work is checked
- Content remains reachable at narrow widths and zoom; hover-only controls have a usable alternate interaction.
When to stop or clarify
- Do not hide required functionality or claim device coverage from a single desktop screenshot.
Handling missing context
- Infer
- Inspect the target flow, existing components/tokens, actual renders or supplied references and current responsive behavior.
- Assume
- Reuse established visual conventions and preserve keyboard behavior; label unrendered changes as visually unverified.
- Ask
- Ask about an unresolved interaction or visual direction only when plausible choices materially differ; do not make a missing screenshot block source inspection.
Technical guidance
- Evidence
- Inspect layout constraints, intrinsic content size, breakpoints, zoom, touch targets and input methods.
- Method
- Repair the constraint causing overflow; choose reflow/order based on task meaning rather than arbitrary device names.
- Pitfall
- Hiding overflow can conceal controls; hover-only affordances fail on touch or keyboard.
- Check
- When no product matrix exists, test at least 320 CSS px width without two-dimensional scrolling (256 px height for vertical scrollers, WCAG 1.4.10), 200% text resize (1.4.4), increased text spacing (1.4.12), both orientations (1.3.4) and 24 by 24 CSS px targets or equivalent spacing (2.5.8); essential content and pointer/keyboard access must remain unclipped.
Situational decisions
When hiding an element would remove required functionality: Reflow or provide an equivalent reachable interaction instead of suppressing it.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.