Menü
(Mobile-First · Touch-First · Platform-Respectful)
AI-powered presentation generation via the 2slides API — create slides from text, match a reference image style, summarize documents into decks, add AI voice narration, and export pages/audio. Use for any "make slides", "create a deck", or "slides from this document" request.
Diff a live page's accessibility violations against a baseline — by default compares uncommitted changes (stash-based), or pass --branch [<name>] to diff against a branch. Reports only new violations introduced, violations fixed, and pre-existing count. Use `scan` for a full audit with no diffing.
Use the Hugging Face Hub CLI (`hf`) to download, upload, and manage models, datasets, and Spaces.
Plan, orchestrate, and adversarially verify parallel AI coding agents with a dynamic multi-agent workflow engine.
Manage opencode permissions: review always-allow lists, suggest safe read-only commands, configure permission patterns
Generate AI images, videos, and music/audio from agents using the RunAPI CLI.
| name | mobile-design |
| description | (Mobile-First · Touch-First · Platform-Respectful) |
| risk | unknown |
| source | community |
| date_added | 2026-02-27 |
(Mobile-First · Touch-First · Platform-Respectful)
Philosophy: Touch-first. Battery-conscious. Platform-respectful. Offline-capable. Core Law: Mobile is NOT a small desktop. Operating Rule: Think constraints first, aesthetics second.
This skill exists to prevent desktop-thinking, AI-defaults, and unsafe assumptions when designing or building mobile applications.
Before designing or implementing any mobile feature or screen, assess feasibility.
| Dimension | Question |
|---|---|
| Platform Clarity | Is the target platform (iOS / Android / both) explicitly defined? |
| Interaction Complexity | How complex are gestures, flows, or navigation? |
| Performance Risk | Does this involve lists, animations, heavy state, or media? |
| Offline Dependence | Does the feature break or degrade without network? |
| Accessibility Risk | Does this impact motor, visual, or cognitive accessibility? |
MFRI = (Platform Clarity + Accessibility Readiness)
− (Interaction Complexity + Performance Risk + Offline Dependence)
Range: -10 → +10
| MFRI | Meaning | Required Action |
|---|---|---|
| 6–10 | Safe | Proceed normally |
| 3–5 | Moderate | Add performance + UX validation |
| 0–2 | Risky | Simplify interactions or architecture |
| < 0 | Dangerous | Redesign before implementation |
If any of the following are not explicitly stated, you MUST ask before proceeding:
| Aspect | Question | Why |
|---|---|---|
| Platform | iOS, Android, or both? | Affects navigation, gestures, typography |
| Framework | React Native, Flutter, or native? | Determines performance and patterns |
| Navigation | Tabs, stack, drawer? | Core UX architecture |
| Offline | Must it work offline? | Data & sync strategy |
| Devices | Phone only or tablet too? | Layout & density rules |
| Audience | Consumer, enterprise, accessibility needs? | Touch & readability |
🚫 Never default to your favorite stack or pattern.
| File | Purpose | Status |
|---|---|---|
| mobile-design-thinking.md | Anti-memorization, context-forcing | 🔴 REQUIRED FIRST |
| touch-psychology.md | Fitts’ Law, thumb zones, gestures | 🔴 REQUIRED |
| mobile-performance.md | 60fps, memory, battery | 🔴 REQUIRED |
| mobile-backend.md | Offline sync, push, APIs | 🔴 REQUIRED |
| mobile-testing.md | Device & E2E testing | 🔴 REQUIRED |
| mobile-debugging.md | Native vs JS debugging | 🔴 REQUIRED |
| Platform | File |
|---|---|
| iOS | platform-ios.md |
| Android | platform-android.md |
| Cross-platform | BOTH above |
❌ If you haven’t read the platform file, you are not allowed to design UI.
| ❌ Never | Why | ✅ Always |
|---|---|---|
| ScrollView for long lists | Memory explosion | FlatList / FlashList / ListView.builder |
| Inline renderItem | Re-renders all rows | useCallback + memo |
| Index as key | Reorder bugs | Stable ID |
| JS-thread animations | Jank | Native driver / GPU |
| console.log in prod | JS thread block | Strip logs |
| No memoization | Battery + perf drain | React.memo / const widgets |
| ❌ Never | Why | ✅ Always |
|---|---|---|
| Touch <44–48px | Miss taps | Min touch target |
| Gesture-only action | Excludes users | Button fallback |
| No loading state | Feels broken | Explicit feedback |
| No error recovery | Dead end | Retry + message |
| Ignore platform norms | Muscle memory broken | iOS ≠ Android |
| ❌ Never | Why | ✅ Always |
|---|---|---|
| Tokens in AsyncStorage | Easily stolen | SecureStore / Keychain |
| Hardcoded secrets | Reverse engineered | Env + secure storage |
| No SSL pinning | MITM risk | Cert pinning |
| Log sensitive data | PII leakage | Never log secrets |
UNIFY DIVERGE
────────────────────────── ─────────────────────────
Business logic Navigation behavior
Data models Gestures
API contracts Icons
Validation Typography
Error semantics Pickers / dialogs
| Element | iOS | Android |
|---|---|---|
| Font | SF Pro | Roboto |
| Min touch | 44pt | 48dp |
| Back | Edge swipe | System back |
| Sheets | Bottom sheet | Dialog / sheet |
| Icons | SF Symbols | Material Icons |
Rules:
const Row = React.memo(({ item }) => (
<View><Text>{item.title}</Text></View>
));
const renderItem = useCallback(
({ item }) => <Row item={item} />,
[]
);
<FlatList
data={items}
renderItem={renderItem}
keyExtractor={(i) => i.id}
getItemLayout={(_, i) => ({
length: ITEM_HEIGHT,
offset: ITEM_HEIGHT * i,
index: i,
})}
/>
class Item extends StatelessWidget {
const Item({super.key});
@override
Widget build(BuildContext context) {
return const Text('Static');
}
}
const everywhere possibleBefore writing any code, you must complete this:
🧠 MOBILE CHECKPOINT
Platform: ___________
Framework: ___________
Files Read: ___________
3 Principles I Will Apply:
1.
2.
3.
Anti-Patterns I Will Avoid:
1.
2.
❌ Cannot complete → go back and read.
Need OTA + web team → React Native + Expo
High-perf UI → Flutter
iOS only → SwiftUI
Android only → Compose
No debate without justification.
Final Law: Mobile users are distracted, interrupted, and impatient—often using one hand on a bad network with low battery. Design for that reality, or your app will fail quietly.
This skill is applicable to execute the workflow or actions described in the overview.