Adapt a Web interface across screen sizes

Adapt an existing Web interface to phone, tablet and desktop while preserving its core task, content and accessible interactions. A compact direction to help the next screen feel deliberate, specific, and easy to remix.

Adapt an existing Web interface for phone, tablet and desktop around the same core task. Change layout and interaction rather than uniformly shrinking desktop UI or hiding necessary content.

INPUT
Existing UI: [screenshots, structural description or code; current width and known issues]
Task/content: [primary action, essential information, secondary content that may be deferred]
Targets: [size ranges, browsers, touch/mouse/keyboard, orientations, network constraints]
Constraints: [tokens, components, stack, routes, business interfaces and protected content]
Deliverable: [adaptation specification; or specification plus minimal changes to supplied code]

METHOD
1. Confirm the existing structure, core task and target environments. Ask up to three blocking questions and wait if essential information is missing. Without images/code, claim no inspection of an actual page. With screenshots alone, mark hidden states, interaction, DOM and breakpoints as unknown.
2. Prioritize essential information, key actions and secondary content. Preserve content meaning, paths and business capabilities. Collapse secondary material only with a clear entry point. Do not remove core functions or hide overflow to fake a clean small-screen layout.
3. Design phone, tablet and desktop layout/navigation separately. Let content determine columns, ordering, maximum widths, spacing and flexible areas; consider tablet orientation and mixed input. Evaluate lists, tables, sidebars and tools individually for reflow, local scrolling, progressive disclosure or preservation. Do not universally replace them with cards or bottom navigation. Keep DOM reading order and visual order coherent.
4. Propose breakpoints where actual content wraps badly, collides or becomes obscured and explain each decision. Cover continuous widths between breakpoints rather than three fixed canvases. Use fluid type/spacing and container queries, clamp or responsive images only when appropriate to the existing stack; claim no untested universal browser compatibility.
5. Adapt interactions to input capability. Make hover information reachable through touch and keyboard, with visible focus, usable touch spacing and feedback. Check fixed controls, soft keyboards, safe areas, long text, zoom and landscape. Respect reduced-motion; animation must not be the sole carrier of meaning.
6. If implementation is requested, reuse existing tokens, components, breakpoints and layout methods with minimal changes. Preserve business interfaces/content. Do not stretch images, truncate essential text or place key actions outside reach. Without code access, label examples clearly rather than claiming the real project was modified.
7. Perform checks within available capabilities. Distinguish viewport-layout checks, actual input/interaction checks and real-device/target-browser checks. Resizing desktop cannot establish touch, soft-keyboard or iOS behavior. Mark unavailable checks unverified; record failure width, impact and minimal remedy.

DELIVER IN ORDER
A. Current issues/evidence: location / triggering environment / task impact / observation or inference.
B. Content-priority and adaptation matrix: region / phone / tablet / desktop / how information and actions remain reachable.
C. Layout rules: content-driven breakpoint reasons, columns, widths, ordering, navigation, tables and fixed controls.
D. Interaction/accessibility: touch, mouse, keyboard, long text, focus, zoom, reduced motion and soft keyboards.
E. Only if requested, minimal code changes and locations.
F. Verification matrix: scenario / action / expected outcome / actual result / unverified reason; narrow/wide screens, orientations, breakpoint edges, long content and core task.

BOUNDARIES
Web adaptation only, excluding native iOS/Android, print and email. Do not redesign branding, alter business APIs or invent performance, compatibility, device results or automated test records.

Independent site adaptation of Paul Bakaus / Impeccable's Web adapt method (Apache-2.0), reduced to a standalone template without its command engine. Not the complete project; adds explicit deliverable and evidence-status requirements: https://github.com/pbakaus/impeccable/blob/778c8a7b71ccd5bfe3ca6ac68c15d9d872d0f87d/skill/reference/adapt.md .

uniformly scaled desktop layouts, hidden essential content, forced one-column or bottom navigation, hover-only actions, stretched images, altered business APIs, desktop resizing presented as real-device tests, invented compatibility