npx claudepluginhub ghaida/intent --plugin intentThis skill uses the workspace's default tool permissions.
Responsive design is a layout concern. Transposition is a UX concern.
Designs end-to-end user-facing experiences: task flows, workflows, navigation, onboarding, settings, search, collaboration, checkout, dashboards, notifications, error recovery. Handles cross-platform adaptation, accessibility, interaction specs.
Designs iOS/Android mobile app screens via 5-phase process: discovery questions on platform/flows/brand, brief confirmation, and visual specs. For UI, onboarding, flows.
Plans UI/UX for features: user flows, screen inventory, information architecture, navigation, interactions. Use before implementation after brainstorming.
Share bugs, ideas, or general feedback.
Responsive design is a layout concern. Transposition is a UX concern.
When an experience moves from desktop to mobile, from web to TV, from consumer app to kiosk, from visual interface to voice — the interaction model, information priority, and user context all change. A dashboard that works beautifully on a 27-inch monitor doesn't become a mobile experience by reflowing into a single column. A checkout flow designed for keyboard and mouse doesn't become a TV experience by adding focus states.
Transposition means rethinking the experience for each context, not shrinking it to fit. It asks: what would this experience look like if it were designed for this context first? What would we add? What would we never have included? What interaction patterns are native to this platform, and which are we forcing from somewhere else?
When to activate this skill: Moving a product to a new platform, planning multi-device strategy, auditing cross-platform UX, designing for non-standard contexts (TV, kiosk, voice, embedded), or anytime someone says "just make it responsive" and the problem is bigger than layout.
Transpose works alongside the full Intent skill system:
/journey: Your flows need to work across the contexts transpose identifies. A checkout flow on desktop is not the same journey on mobile or voice — journey designs the sequence, transpose ensures it fits the context./organize: Navigation structure may fundamentally change per context. Sidebar navigation on desktop might become bottom tabs on mobile, a hub-and-spoke on TV, or a flat menu on a kiosk. Organize provides the IA; transpose adapts it./include: Cross-context design IS inclusive design. Designing for the constraints of a small screen, a noisy environment, one-handed use, or a 10-foot viewing distance is designing for real human situations. Include ensures accessibility; transpose ensures contextual fit./fortify: Different contexts have different failure modes. Mobile loses connectivity. TV remotes run out of batteries. Kiosks get touched by greasy fingers. Fortify maps the failure modes; transpose maps the contexts where they occur./blueprint: System architecture must support multi-context delivery. APIs need to serve different data shapes. State sync needs infrastructure. Blueprint maps the system; transpose defines what each context needs from it./philosopher: A cross-cutting cognitive mode for sitting with transposition problems before jumping to solutions. Invoke when: you're tempted to copy-paste interaction patterns across platforms, something feels forced, or you need the question: "What if this experience was born on mobile? What would we never have added?"For every source-to-target transposition, systematically analyze what changes. This is not a checklist to glance at — it's a forcing function that makes you confront the real differences between contexts.
Input method:
Attention model:
Screen real estate: Constraints AND opportunities. Small screens force focus — that's a feature, not a bug. Large screens enable overview and comparison — but also invite clutter. Analyze what each size makes possible, not just what it takes away.
Connectivity:
Environment:
Session length:
For each transposition project, fill out this framework explicitly. Do not skip dimensions because they seem obvious.
These are genuine behavioral differences that users have internalized, not arbitrary guidelines to cargo-cult. Violate them only when you have a specific reason.
iOS:
Android:
Web:
TV (10-foot UI):
Kiosk:
Embedded/widget:
Voice:
What's primary changes by context. This is the core of transposition — not just hiding content on smaller screens, but rethinking what matters most.
Desktop — overview + detail:
Mobile — action + essential info:
TV — browse + select:
Kiosk — task + nothing else:
Document priority shifts explicitly for each screen and feature. Create a priority matrix: what's primary, secondary, hidden, and removed per context.
Users switch devices mid-task. This isn't an edge case — it's the normal flow for many tasks. Design for it explicitly.
State preservation:
Handoff patterns:
Context-appropriate notifications:
Session continuity:
The same information architecture may need fundamentally different disclosure strategies per context. This is not about responsive breakpoints — it's about cognitive load management per context.
Mobile: show less, reveal on interaction. Cards that expand, drawers that slide up, tabs that switch content. The user chooses what to see more of. Default to the minimum viable view.
Desktop: show more, group by function. Sidebars, panels, toolbars, multi-column layouts. The user scans and selects. More information is visible simultaneously, reducing the need for navigation.
TV: show categories, drill into detail. Large tiles representing categories or content. Select to enter, back to return. Flat and wide, not deep and narrow.
Kiosk: show the task, nothing else. Strip away everything that isn't the current step. No settings, no account management, no exploration. Just the task.
Voice: reveal through conversation. "Here are your three options. Would you like to hear more about any of them?" Progressive disclosure happens through dialogue turns, not visual hierarchy.
Map disclosure strategy per context for every major feature. Don't assume what works on desktop will work anywhere else with minor modifications.
For each platform/context, document: input method, attention model, screen real estate, connectivity, environment, session length, and their UX implications.
Per platform: which conventions apply, which native patterns to adopt, which source patterns to replace (and with what), which features to add/remove/transform.
For each major screen/feature: what's primary, secondary, on-demand, and removed — per context. Explicitly document what gets cut and why.
For multi-device experiences: where users switch, what state transfers, what handoff mechanisms exist, and where continuity breaks.
Never say "just make it responsive." Transposition requires rethinking, not reflowing. The question is never "how do we fit this on a smaller screen?" The question is "what would this experience look like if it were designed for this context first?"
Be specific about platform conventions. Don't say "follow platform guidelines" — say which guideline, which pattern, and why it matters for this specific design. Challenge assumptions about which features "must" exist on every platform. Sometimes the right transposition is to remove a feature entirely from a context where it doesn't serve users.
Respect the intelligence of each context. Mobile isn't desktop's lesser sibling. Voice isn't a screen without visuals. Each context has strengths that the others lack.
/journey)/organize)/blueprint)/include)