adapt

Overview of adapt skill

What adapt skill does

The adapt skill helps you redesign an existing interface for a new context: different screen sizes, devices, input methods, platforms, or usage situations. In practice, adapt is for UI/UX Design teams and AI-assisted designers who need to turn a desktop-first concept into mobile, tablet, print, TV, touch, keyboard, or low-bandwidth variants without treating responsiveness as only a breakpoint exercise.

Who should use adapt

Use adapt if you already have a design direction, screen, flow, or component set and need to make it work somewhere else. It fits product designers, frontend designers, UX engineers, and agents handling responsive design, mobile adaptation, cross-device compatibility, or context-specific layout decisions.

Real job-to-be-done

Most users do not need a generic “make this responsive” prompt. They need help answering harder questions: what should stay, what should collapse, what interaction patterns break on touch, what becomes secondary, and which assumptions from the original context no longer hold. The adapt skill is valuable because it frames adaptation as a context shift, not just a CSS change.

What makes adapt different

The main differentiator is its required preparation step. adapt explicitly depends on broader design context from /frontend-design, and if that context is missing, it instructs you to run /teach-impeccable first. That makes it more structured than ordinary prompting, but also means adapt install is only worth it if you want guided adaptation thinking rather than a one-off responsive rewrite.

Best-fit and misfit cases

Best fit:

• Desktop-to-mobile redesign
• Web-to-tablet or touch adaptation
• Keyboard, mouse, or touch interaction changes
• Print or constrained-context variants
• Fast evaluation of what must change across contexts

Misfit:

• Net-new product ideation with no existing design direction
• Pure implementation tasks with no UX decisions needed
• Visual polish requests that do not involve context changes

How to Use adapt skill

Install context before using adapt

This skill lives at .claude/skills/adapt in the pbakaus/impeccable repository. There is no standalone package workflow exposed in the skill itself, so adapt install is mainly about adding the repository skill and making sure the dependent design skills are also available in your environment.

If your tool supports remote skill install, use the repository path/URL for pbakaus/impeccable and select the adapt skill. After installation, confirm that /frontend-design and /teach-impeccable are also accessible, because the skill expects them.

Read this file first

Start with:

• SKILL.md

This skill is compact and self-contained. There are no extra rules, references, scripts, or resource folders surfaced in the repository evidence, so most of the usable logic is in that single file. That is good for quick adoption, but it also means your prompt quality matters more.

Required dependency: frontend design context

Before calling adapt, run /frontend-design and follow its context-gathering protocol. If you do not yet have enough design context, run /teach-impeccable first. This is the most important adoption detail because skipping it weakens the output more than any phrasing tweak.

In plain terms, do not ask adapt to solve responsive design in a vacuum. Give it the design principles, product context, and current interface assumptions first.

What input adapt needs

A strong adapt usage prompt should include:

• the current design or source context
• the target context
• the main tasks users need to complete
• the constraints that change across contexts
• the interaction model that must still work

Useful specifics from the skill:

• device type
• input method
• screen size or orientation constraints
• connection quality
• usage mode, such as quick glance vs focused session
• platform expectations

How to phrase an adapt request well

Weak prompt:

• “Make this responsive.”

Stronger prompt:

• “Use adapt for UI/UX Design. Source context: desktop web analytics dashboard optimized for mouse and large screens. Target context: mobile web on touch devices, portrait orientation, intermittent 4G, quick check-ins during commutes. Preserve top KPIs, recent alerts, and one-tap drilldown. Identify what to remove, collapse, reorder, or defer.”

Why this works:

• it tells adapt what the original design assumed
• it defines the target environment
• it clarifies user priorities
• it gives the skill permission to change hierarchy, not just shrink layouts

Use the argument hint as a shortcut

The skill exposes an argument hint:

• [target] [context (mobile, tablet, print...)]

That means concise invocations can work when the surrounding thread already contains design context. Example:

• adapt checkout flow mobile
• adapt analytics dashboard tablet
• adapt settings page print

Use this only when the session already contains enough source-context detail.

Suggested workflow for real projects

A practical adapt guide workflow is:

1. Gather product and design context with /frontend-design
2. Clarify the original screen or flow assumptions
3. State the target platform and usage context
4. Ask adapt to identify breakpoints, hierarchy shifts, and interaction changes
5. Review what should be preserved, removed, merged, or deferred
6. Convert the result into component specs or implementation tasks

This sequence is better than jumping straight to layout changes because many adaptation failures come from preserving too much.

What adapt focuses on during evaluation

Based on the skill content, adapt assesses:

• source-context assumptions
• target-device and platform constraints
• input changes such as mouse to touch
• usage-context changes such as desk to on-the-go
• user expectations in the new environment

That makes it useful for more than classic responsive design. It can also support platform adaptation where behavior, not just spacing, must change.

Practical examples of good adapt usage

Good use cases:

• desktop data table to mobile summary-and-detail flow
• sidebar-heavy admin UI to tablet split-view design
• desktop hover interactions to touch-safe alternatives
• print-friendly version of content-heavy pages
• kiosk or TV adaptation with larger targets and simplified navigation

In each case, ask adapt what assumptions break first. That usually produces better output than asking for visual tweaks.

Common blockers before adoption

The main blockers are not technical install issues but missing context:

• no clear source design to adapt from
• no explicit target platform
• no input-method details
• no prioritization of key tasks
• expecting implementation-ready CSS from a UX adaptation skill

If you need code, use adapt to make the design decisions first, then hand the result to implementation-focused workflows.

adapt skill FAQ

Is adapt skill just a responsive design prompt?

No. adapt goes beyond breakpoints and fluid layouts. It is designed for context adaptation, including device, input method, connection, and usage pattern changes. That makes it more useful than a generic “make it mobile-friendly” prompt when behavior and information hierarchy need to change.

Is adapt good for beginners?

Yes, with one caveat: beginners benefit from the structured thinking, but only if they provide enough context. If you are new to UI adaptation, adapt can help surface hidden assumptions. If you provide only a screenshot and “make it mobile,” the output will be much less actionable.

When should I not use adapt?

Do not use adapt when you need:

• a greenfield product concept
• pixel-level visual refinement only
• direct frontend code without design reasoning
• a design-system audit unrelated to context shifts

In those cases, another skill or a direct implementation prompt is a better fit.

How is adapt different from ordinary prompts?

Ordinary prompts often stop at layout compression. The adapt skill pushes you to define source assumptions, target constraints, and usage context first. That extra structure is the main reason to install it instead of improvising.

Does adapt require other skills?

Effectively, yes. The skill explicitly requires /frontend-design context and may require /teach-impeccable first if no design context exists. If your environment only installs adapt without those supporting skills, expect weaker results or manual setup work.

How to Improve adapt skill

Give adapt the source assumptions explicitly

The fastest way to improve adapt output is to state what the current design assumes:

• large screen
• precise pointer
• long session length
• stable connection
• dense information display

These assumptions tell the skill what is likely to break in the new context.

Specify what must survive the adaptation

Do not ask for a full redesign unless you want one. List the 2-4 things that must remain excellent in the target context, such as:

• complete checkout in under a minute
• monitor alerts at a glance
• compare two products quickly
• approve requests with one hand

This helps adapt for UI/UX Design preserve the right workflows.

Describe the target context like a real environment

Better inputs produce better adaptation decisions. Include details such as:

• portrait vs landscape
• touch vs keyboard
• indoor desk use vs outdoor quick access
• low bandwidth vs reliable Wi‑Fi
• accessibility expectations
• native platform conventions

These details materially affect hierarchy, controls, and navigation choices.

Ask for tradeoffs, not just solutions

A high-value adapt guide prompt asks:

• what should be removed
• what should be deferred to a secondary screen
• what interaction pattern should change
• what becomes the primary action in the new context

This improves output because adaptation usually requires subtraction and prioritization.

Iterate after the first pass

After the first adapt usage result, refine with targeted follow-ups:

• “Now adapt only the filtering workflow.”
• “Preserve comparison capability on tablet.”
• “Reduce thumb reach issues for one-handed use.”
• “Keep expert shortcuts for keyboard users.”

Small follow-up passes are usually better than one overloaded request.

Watch for common failure modes

Common weak outputs happen when:

• the source design is not described
• the target context is too vague
• the prompt asks for implementation before UX decisions
• all current features are treated as equally important
• platform norms are ignored

If the result feels generic, the fix is usually stronger context, not a longer prompt.

Use adapt as a decision tool before implementation

The best way to improve outcomes is to treat adapt as a design decision layer. Let it produce the adaptation logic first, then turn that into wireframes, specs, or frontend tasks. That separation keeps the skill focused on what it does best: deciding how a UI should change across contexts.