# Adaptive Interface

> Adapt one interface across space, input, content pressure, text scaling, orientation, localization, and reduced motion. Use when designing or reviewing responsive behavior, touch and keyboard support, or layouts that break under real content.

- Skill: `dragoon0x/adaptive-interface` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add dragoon0x/adaptive-interface`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dragoon0x/adaptive-interface/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dragoon0x (https://skillmd.com/u/dragoon0x)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dragoon0x/adaptive-interface

---


# Adaptive Interface

## Mission

Design one product that behaves appropriately across changing contexts. Responsive design is contextual adaptation, not merely resizing.

## Context model

Consider available width/height, pointer precision, touch, keyboard, orientation, text size, zoom, localization, content length, performance constraints, reduced motion, and platform conventions.

## Invariants

Before adapting, define what must remain true: primary task, important content, current location, feedback, essential actions, and keyboard operation where applicable.

## Priority under pressure

Classify elements as must remain, should remain, can collapse, can move, can defer, or can disappear.

Do not let CSS accidentally decide product hierarchy.

## Behavioral breakpoints

A breakpoint exists because behavior changes. Possible changes include sidebar to contextual navigation, toolbar to overflow, columns to stacked groups, persistent controls to contextual controls, or hover affordance to explicit touch affordance.

## Input adaptation

Touch needs tolerant targets and little hover dependence. Pointer can support denser interaction. Keyboard needs visible focus and predictable traversal. Do not create separate products unless the interaction model truly differs.

## Content pressure

Test long labels, translations, large values, long names, multiline content, missing metadata, and user-generated content.

Choose intentionally between wrapping, truncation, scrolling, collapsing, expansion, or resizing.

## Zoom and text scaling

Check clipping, overlap, hidden controls, fixed heights, modal overflow, and navigation collapse.

## Orientation

Consider task continuity, reading order, media, split views, and gesture regions rather than treating orientation as a simple resize.

## Performance adaptation

Where needed, reduce expensive effects or non-critical work on constrained devices without removing important information.

## Reduced motion

Adapt movement while preserving state communication.

## Failure modes

Avoid shrunk desktop layouts, hidden functionality without replacement, breakpoint patchwork, hover-dependent touch behavior, and layouts that only work with ideal content.

## Verification

Test meaningful combinations of space, input, content, and settings rather than only named devices.

## Reference artifact

Use `references/adaptation-matrix.md` to state adaptation invariants and verify high-risk combinations of space, input, content, and settings.

## Completion criteria

The interface preserves its important intent across realistic combinations of space, input, content, and accessibility settings.

## Expert Review Protocol

### First pass: understand

Before changing anything, identify the actual user outcome, the existing system, the relevant constraints, and the evidence available.

Do not begin by choosing a visual treatment.

### Second pass: compare

Ask:

- What is the simplest credible solution?
- What is the strongest alternative?
- What does the current solution cost?
- What behavior does each option teach the user?
- Which decision is easiest to reverse?
- Which failure would be most expensive?

Choose deliberately.

### Third pass: stress

Do not review only the happy path.

Apply pressure through:

- repetition
- interruption
- missing content
- long content
- slow operations
- narrow space
- large text
- keyboard use
- touch use
- focus changes
- error recovery
- restoration

Use only scenarios that are relevant to the surface.

### Fourth pass: inspect the implementation

When code exists, verify that the implementation preserves the interface decision.

Look for:

- duplicated sources of truth
- styling that bypasses the system
- state that can become stale
- behavior that differs from adjacent components
- abstractions that obscure rather than simplify
- dependencies that are not earning their cost
- performance work performed without evidence

### Fifth pass: critique the result

Ask:

> If this were shipped tomorrow, what would users notice that the builder has stopped noticing?

Look for:

- friction
- ambiguity
- inconsistency
- unnecessary movement
- weak recovery
- hidden state
- visual noise
- inaccessible behavior
- fragile edge cases

### Sixth pass: distinguish polish from substance

A useful change improves one or more of:

- understanding
- speed
- confidence
- recovery
- accessibility
- consistency
- maintainability

If a change improves none of these and only adds decoration, treat it as suspect.

### Seventh pass: verify

A claim is complete only when an appropriate form of evidence supports it.

Use:

- direct interaction
- tests
- runtime inspection
- visual comparison
- accessibility checks
- performance measurement
- source inspection

Do not claim a check that did not occur.

### Completion standard

Stop when:

1. the intended outcome is achieved
2. important states are handled
3. meaningful failure modes were considered
4. the interface fits its surrounding system
5. important claims are verified
6. remaining imperfections are lower-value than the risk of further change

The goal is not maximal polish.

The goal is a result that is difficult to improve without changing the underlying decision.