[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NPJW6SD9CA2PS45XEE9NQB":3,"skill-same:01M6NPJW6SD9CA2PS45XEE9NQB":93},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":14,"repositoryHtmlUrl":64,"repositoryHomepageUrl":65,"ownerHtmlUrl":66,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":67,"install":68,"resources":81},"01M6NPJW6SD9CA2PS45XEE9NQB","mobile-app-design",null,"Mobile app UX — touch targets, navigation, platform conventions, accessibility. Use when designing mobile interfaces, reviewing mobile UX, adapting web designs for mobile, or reconciling iOS and Android conventions.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fdesign\u002Fmobile-app-design\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"app design","app","mobile app","design","mobile","mobile app design","navigation","for","targets","touch","mobile ux","platform","conventions","use","work","ios","ux","accessibility","web","android","2026-11-10 10:12:30",false,"---\nname: mobile-app-design\ndescription: |\n  Mobile app UX — touch targets, navigation, platform conventions, accessibility. Use when designing mobile interfaces, reviewing mobile UX, adapting web designs for mobile, or reconciling iOS and Android conventions.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv2\n    id: SKILL-mobile-app-design\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: design\n---\n\n# Mobile App Design\n\n## Intro\n\nMobile UX is shaped by finger-sized touch targets, one-thumb reach,\nplatform conventions, and flaky connectivity. Start with the smallest\nsupported screen, respect platform idioms for navigation and\ncomponents, and design for offline-first use from the beginning.\n\n## Overview\n\n### Touch target sizing\n\n- Minimum 44x44 points (iOS) \u002F 48x48 dp (Android) for all\n  interactive elements.\n- At least 8pt gap between targets to prevent mis-taps.\n- Primary CTAs 48-56pt high.\n- Thumbs reach the lower two-thirds of the screen easily — put\n  frequent actions there.\n- Keep destructive actions away from frequent-tap zones.\n- Floating action buttons: 56dp standard, 40dp mini.\n\n### Navigation patterns\n\n- **Tab bar (bottom):** 3-5 top-level destinations, always visible,\n  best for peer sections.\n- **Navigation drawer (hamburger):** 5+ destinations or infrequent\n  sections.\n- **Stack navigation:** push\u002Fpop for hierarchical detail screens.\n- **Modal sheets:** temporary tasks, filters, confirmations —\n  dismiss with swipe or button.\n\nKeep depth shallow (3 levels max). Show a back button or\nswipe-to-go-back gesture on every non-root screen. Persistent bottom\nnav should highlight the active tab and not reset tab state on\nre-tap.\n\n### Responsive layouts\n\nDesign for the smallest supported screen first (375pt width for iOS,\n360dp for Android). Use a 4pt or 8pt spacing grid. Support landscape\nunless the content is strongly portrait-oriented. Adapt to tablets\nwith split-view or increased content width via max-width constraints.\nSupport Dynamic Type (iOS) and font scaling (Android) — never\nhardcode font sizes — and test with the system font set to its\nmaximum size to catch overflow.\n\n### iOS vs Android conventions\n\n- **Back navigation:** iOS swipe-from-edge or top-left button;\n  Android system back button or gesture.\n- **Tabs:** iOS bottom tab bar; Android bottom navigation bar or top\n  tabs.\n- **Buttons:** iOS plain text or rounded rect; Android filled or\n  outlined Material buttons.\n- **Alerts:** iOS centered alerts with stacked buttons; Android\n  dialogs with side-by-side buttons.\n- **Typography:** iOS uses SF Pro; Android uses Roboto or system\n  font.\n- **Icons:** iOS SF Symbols (outline by default); Android Material\n  Icons (filled or outlined).\n\nWhen in doubt, follow platform conventions — users expect familiar\nbehavior.\n\n### Gesture patterns\n\n- **Tap:** primary interaction — feedback under 100ms.\n- **Long press:** secondary actions, context menus — always provide\n  a visible alternative.\n- **Swipe:** list actions (delete, archive), sheet dismissal, page\n  navigation.\n- **Pull to refresh:** standard for list content — show a spinner.\n- **Pinch to zoom:** images, maps — provide zoom controls as an\n  alternative.\n\nMake swipe actions discoverable with a peek animation on first use.\nNever make gestures the only way to perform an action.\n\n### Accessibility\n\nSupport screen readers with labels on every interactive element and\nimage. Maintain 4.5:1 text contrast, 3:1 UI contrast. Support Dynamic\nType and font scaling without layout breakage. Provide captions or\ntranscripts for audio\u002Fvideo. Test with VoiceOver (iOS) and TalkBack\n(Android). Ensure touch targets stay accessible at all accessibility\nzoom levels. Respect reduced-motion preferences with static\nalternatives.\n\n### Offline-first design\n\n- Show cached content immediately while fetching updates in the\n  background.\n- Display clear \"offline\" indicators — never silently fail.\n- Queue user actions when offline and sync when reconnected.\n- Use optimistic UI: show the result immediately, reconcile later.\n- Store critical data locally — users expect apps to work without\n  signal.\n- Design conflict resolution for collaborative data.\n\n### Push notifications\n\n- Request permission at a contextually relevant moment, not on first\n  launch.\n- Explain the value before asking (\"Get notified when your order\n  ships\").\n- Group related notifications to avoid overwhelming the user.\n- Deep link from notifications directly to the relevant content.\n- Respect notification settings — provide in-app controls to\n  customize.\n- Never use notifications for marketing on first install — earn\n  trust first.\n\n### Onboarding flows\n\n- Keep onboarding to 3-5 screens maximum — users want to use the\n  app.\n- Show value immediately — let users explore before requiring\n  sign-up.\n- Progressive disclosure: teach features as users encounter them.\n- Skip onboarding for returning users by checking for existing data.\n- Provide a \"Skip\" option on every onboarding screen.\n- Prefer contextual tooltips and coach marks over upfront tutorials.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Designing for the largest screen first and scaling down.** Starting with a wide screen allows fitting too much content, which breaks on the common 375pt iPhone viewport. Design for the smallest supported screen first, then progressively enhance for larger displays.\n- **Using touch targets smaller than platform minimums.** Anything below 44×44 points (iOS) or 48×48 dp (Android) causes mis-taps and generates disproportionate accessibility complaints. Apply the minimums to every interactive element, including secondary and icon-only buttons.\n- **Placing destructive actions in the high-frequency thumb zone.** The lower two-thirds of the screen is the easiest reach area. Putting \"Delete\" or \"Log out\" near frequently tapped actions causes accidental destructive interactions. Keep destructive actions away from high-frequency zones and require confirmation.\n- **Requesting permissions on first launch.** Users who have not yet experienced the app's value deny permissions at high rates, and iOS\u002FAndroid only allow one native prompt per permission. Request permissions at a contextually relevant moment after the user has seen the benefit.\n- **Not testing with the system font at maximum scale.** Dynamic Type (iOS) and font scaling (Android) can triple the effective font size. Fixed-height containers, truncated labels, and overflowing text are only visible when tested at the maximum system accessibility font scale.\n- **Designing for online-only without an offline state.** Users regularly use apps in low-signal environments. An app that silently fails or shows blank screens when offline creates broken experiences. Design the offline state explicitly: show cached content, queue writes, and display clear \"offline\" indicators.\n- **Making gestures the only way to perform an action.** Swipe-to-delete or pull-to-refresh as the sole access method excludes users who cannot perform those gestures. Always pair gestures with a discoverable alternative — a button, long-press menu, or context action.\n\n## Full reference\n\n### iOS HIG vs Material Design — navigation\n\n| Aspect | iOS (HIG) | Android (Material 3) |\n|---|---|---|\n| Primary nav | Bottom tab bar (UITabBarController) | Bottom navigation bar (NavigationBar) |\n| Tab limit | 5 max (more goes to \"More\" tab) | 3-5 destinations |\n| Secondary nav | Back button (top-left) | System back gesture\u002Fbutton |\n| Drawer | Rare — prefer tabs or lists | Common for 5+ destinations |\n| Stack | UINavigationController push\u002Fpop | Fragment\u002FActivity back stack |\n| Modals | Sheet sliding up, swipe to dismiss | Bottom sheet or dialog |\n\n### Typography\n\n| Element | iOS (SF Pro) | Android (Roboto \u002F Material Type Scale) |\n|---|---|---|\n| Large title | 34pt bold | Display Large: 57sp |\n| Title | 17pt semibold | Title Large: 22sp |\n| Body | 17pt regular | Body Large: 16sp |\n| Caption | 12pt regular | Body Small: 12sp |\n| Line height | ~1.2x font size | ~1.25-1.5x font size |\n\nBoth platforms require support for dynamic font sizing — never\nhardcode sizes.\n\n### Iconography\n\n| Aspect | iOS | Android |\n|---|---|---|\n| Icon set | SF Symbols (5000+ icons) | Material Symbols (3000+ icons) |\n| Style | Outline by default, filled for active tab | Filled or outlined per Material theme |\n| Size | 22-28pt for toolbar\u002Ftab icons | 24dp standard |\n| Weight | Matches text weight (dynamic) | Fixed weight per variant |\n\n### Spacing and layout\n\n| Aspect | iOS | Android |\n|---|---|---|\n| Base grid | 8pt grid (some 4pt) | 8dp \u002F 4dp grid |\n| Content margins | 16pt standard, 20pt on larger devices | 16dp standard |\n| List row height | 44pt minimum | 48dp minimum (one-line), 56dp (two-line) |\n| Card padding | 16pt internal | 16dp internal |\n| Safe areas | Required (notch, home indicator) | Edge-to-edge with system bar insets |\n\n### Color\n\n| Aspect | iOS | Android |\n|---|---|---|\n| System colors | Dynamic (adapt to light\u002Fdark) | Material color roles (primary, secondary, surface) |\n| Accent color | App tint color | Primary color from seed |\n| Dark mode | Elevated surfaces are lighter | Tonal elevation (surface color shifts) |\n| Contrast | System provides high-contrast variants | Medium\u002FHigh contrast themes available |\n| Color scheme | System colors + custom via asset catalog | Dynamic color from wallpaper (Android 12+) |\n\n### Components\n\n| Component | iOS | Android |\n|---|---|---|\n| Primary button | Filled or plain text | Filled button (FilledButton) |\n| Secondary button | Tinted or outline | Outlined button (OutlinedButton) |\n| Toggle | UISwitch (green\u002Fgray) | Material Switch |\n| Date picker | Wheel or compact popup | Calendar dialog |\n| Alert | Centered, stacked buttons | Dialog, side-by-side buttons |\n| Action menu | Action sheet (bottom) | Bottom sheet or popup menu |\n| Search | Search bar in navigation | SearchBar widget |\n| Pull to refresh | UIRefreshControl | SwipeRefreshLayout |\n\n### When to follow platform vs cross-platform\n\nFollow platform conventions when:\n\n- The control has a direct platform equivalent (alerts, date\n  pickers, sheets).\n- The gesture is platform-specific (iOS swipe-back, Android system\n  back).\n- Users expect platform-consistent behavior (share sheets,\n  notifications).\n- Accessibility features depend on native patterns (VoiceOver,\n  TalkBack).\n\nUse cross-platform consistency when:\n\n- The feature is unique to your app (custom visualizations, brand\n  experience).\n- The interaction has no strong platform equivalent.\n- Maintaining two designs would create user confusion between\n  platforms.\n- Your brand identity requires visual consistency.\n\n### Key principles\n\n1. **Respect the platform** — users spend 99% of their time in other\n   apps.\n2. **Prioritize usability** — a familiar pattern beats a clever\n   custom solution.\n3. **Test on both platforms** — what feels natural on iOS may feel\n   foreign on Android.\n4. **Use adaptive layouts** — design once, adapt to platform\n   conventions in code.\n5. **Accessibility first** — both platforms provide excellent a11y\n   tools; use them.\n\n### Further reading\n\n- `references\u002Fplatform-guidelines.md` — source for the iOS vs\n  Material comparison tables above.\n- [Apple Human Interface Guidelines](https:\u002F\u002Fdeveloper.apple.com\u002Fdesign\u002Fhuman-interface-guidelines\u002F)\n- [Material Design 3](https:\u002F\u002Fm3.material.io\u002F)\n","# Mobile App Design\n\n## Intro\n\nMobile UX is shaped by finger-sized touch targets, one-thumb reach,\nplatform conventions, and flaky connectivity. Start with the smallest\nsupported screen, respect platform idioms for navigation and\ncomponents, and design for offline-first use from the beginning.\n\n## Overview\n\n### Touch target sizing\n\n- Minimum 44x44 points (iOS) \u002F 48x48 dp (Android) for all\n  interactive elements.\n- At least 8pt gap between targets to prevent mis-taps.\n- Primary CTAs 48-56pt high.\n- Thumbs reach the lower two-thirds of the screen easily — put\n  frequent actions there.\n- Keep destructive actions away from frequent-tap zones.\n- Floating action buttons: 56dp standard, 40dp mini.\n\n### Navigation patterns\n\n- **Tab bar (bottom):** 3-5 top-level destinations, always visible,\n  best for peer sections.\n- **Navigation drawer (hamburger):** 5+ destinations or infrequent\n  sections.\n- **Stack navigation:** push\u002Fpop for hierarchical detail screens.\n- **Modal sheets:** temporary tasks, filters, confirmations —\n  dismiss with swipe or button.\n\nKeep depth shallow (3 levels max). Show a back button or\nswipe-to-go-back gesture on every non-root screen. Persistent bottom\nnav should highlight the active tab and not reset tab state on\nre-tap.\n\n### Responsive layouts\n\nDesign for the smallest supported screen first (375pt width for iOS,\n360dp for Android). Use a 4pt or 8pt spacing grid. Support landscape\nunless the content is strongly portrait-oriented. Adapt to tablets\nwith split-view or increased content width via max-width constraints.\nSupport Dynamic Type (iOS) and font scaling (Android) — never\nhardcode font sizes — and test with the system font set to its\nmaximum size to catch overflow.\n\n### iOS vs Android conventions\n\n- **Back navigation:** iOS swipe-from-edge or top-left button;\n  Android system back button or gesture.\n- **Tabs:** iOS bottom tab bar; Android bottom navigation bar or top\n  tabs.\n- **Buttons:** iOS plain text or rounded rect; Android filled or\n  outlined Material buttons.\n- **Alerts:** iOS centered alerts with stacked buttons; Android\n  dialogs with side-by-side buttons.\n- **Typography:** iOS uses SF Pro; Android uses Roboto or system\n  font.\n- **Icons:** iOS SF Symbols (outline by default); Android Material\n  Icons (filled or outlined).\n\nWhen in doubt, follow platform conventions — users expect familiar\nbehavior.\n\n### Gesture patterns\n\n- **Tap:** primary interaction — feedback under 100ms.\n- **Long press:** secondary actions, context menus — always provide\n  a visible alternative.\n- **Swipe:** list actions (delete, archive), sheet dismissal, page\n  navigation.\n- **Pull to refresh:** standard for list content — show a spinner.\n- **Pinch to zoom:** images, maps — provide zoom controls as an\n  alternative.\n\nMake swipe actions discoverable with a peek animation on first use.\nNever make gestures the only way to perform an action.\n\n### Accessibility\n\nSupport screen readers with labels on every interactive element and\nimage. Maintain 4.5:1 text contrast, 3:1 UI contrast. Support Dynamic\nType and font scaling without layout breakage. Provide captions or\ntranscripts for audio\u002Fvideo. Test with VoiceOver (iOS) and TalkBack\n(Android). Ensure touch targets stay accessible at all accessibility\nzoom levels. Respect reduced-motion preferences with static\nalternatives.\n\n### Offline-first design\n\n- Show cached content immediately while fetching updates in the\n  background.\n- Display clear \"offline\" indicators — never silently fail.\n- Queue user actions when offline and sync when reconnected.\n- Use optimistic UI: show the result immediately, reconcile later.\n- Store critical data locally — users expect apps to work without\n  signal.\n- Design conflict resolution for collaborative data.\n\n### Push notifications\n\n- Request permission at a contextually relevant moment, not on first\n  launch.\n- Explain the value before asking (\"Get notified when your order\n  ships\").\n- Group related notifications to avoid overwhelming the user.\n- Deep link from notifications directly to the relevant content.\n- Respect notification settings — provide in-app controls to\n  customize.\n- Never use notifications for marketing on first install — earn\n  trust first.\n\n### Onboarding flows\n\n- Keep onboarding to 3-5 screens maximum — users want to use the\n  app.\n- Show value immediately — let users explore before requiring\n  sign-up.\n- Progressive disclosure: teach features as users encounter them.\n- Skip onboarding for returning users by checking for existing data.\n- Provide a \"Skip\" option on every onboarding screen.\n- Prefer contextual tooltips and coach marks over upfront tutorials.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Designing for the largest screen first and scaling down.** Starting with a wide screen allows fitting too much content, which breaks on the common 375pt iPhone viewport. Design for the smallest supported screen first, then progressively enhance for larger displays.\n- **Using touch targets smaller than platform minimums.** Anything below 44×44 points (iOS) or 48×48 dp (Android) causes mis-taps and generates disproportionate accessibility complaints. Apply the minimums to every interactive element, including secondary and icon-only buttons.\n- **Placing destructive actions in the high-frequency thumb zone.** The lower two-thirds of the screen is the easiest reach area. Putting \"Delete\" or \"Log out\" near frequently tapped actions causes accidental destructive interactions. Keep destructive actions away from high-frequency zones and require confirmation.\n- **Requesting permissions on first launch.** Users who have not yet experienced the app's value deny permissions at high rates, and iOS\u002FAndroid only allow one native prompt per permission. Request permissions at a contextually relevant moment after the user has seen the benefit.\n- **Not testing with the system font at maximum scale.** Dynamic Type (iOS) and font scaling (Android) can triple the effective font size. Fixed-height containers, truncated labels, and overflowing text are only visible when tested at the maximum system accessibility font scale.\n- **Designing for online-only without an offline state.** Users regularly use apps in low-signal environments. An app that silently fails or shows blank screens when offline creates broken experiences. Design the offline state explicitly: show cached content, queue writes, and display clear \"offline\" indicators.\n- **Making gestures the only way to perform an action.** Swipe-to-delete or pull-to-refresh as the sole access method excludes users who cannot perform those gestures. Always pair gestures with a discoverable alternative — a button, long-press menu, or context action.\n\n## Full reference\n\n### iOS HIG vs Material Design — navigation\n\n| Aspect | iOS (HIG) | Android (Material 3) |\n|---|---|---|\n| Primary nav | Bottom tab bar (UITabBarController) | Bottom navigation bar (NavigationBar) |\n| Tab limit | 5 max (more goes to \"More\" tab) | 3-5 destinations |\n| Secondary nav | Back button (top-left) | System back gesture\u002Fbutton |\n| Drawer | Rare — prefer tabs or lists | Common for 5+ destinations |\n| Stack | UINavigationController push\u002Fpop | Fragment\u002FActivity back stack |\n| Modals | Sheet sliding up, swipe to dismiss | Bottom sheet or dialog |\n\n### Typography\n\n| Element | iOS (SF Pro) | Android (Roboto \u002F Material Type Scale) |\n|---|---|---|\n| Large title | 34pt bold | Display Large: 57sp |\n| Title | 17pt semibold | Title Large: 22sp |\n| Body | 17pt regular | Body Large: 16sp |\n| Caption | 12pt regular | Body Small: 12sp |\n| Line height | ~1.2x font size | ~1.25-1.5x font size |\n\nBoth platforms require support for dynamic font sizing — never\nhardcode sizes.\n\n### Iconography\n\n| Aspect | iOS | Android |\n|---|---|---|\n| Icon set | SF Symbols (5000+ icons) | Material Symbols (3000+ icons) |\n| Style | Outline by default, filled for active tab | Filled or outlined per Material theme |\n| Size | 22-28pt for toolbar\u002Ftab icons | 24dp standard |\n| Weight | Matches text weight (dynamic) | Fixed weight per variant |\n\n### Spacing and layout\n\n| Aspect | iOS | Android |\n|---|---|---|\n| Base grid | 8pt grid (some 4pt) | 8dp \u002F 4dp grid |\n| Content margins | 16pt standard, 20pt on larger devices | 16dp standard |\n| List row height | 44pt minimum | 48dp minimum (one-line), 56dp (two-line) |\n| Card padding | 16pt internal | 16dp internal |\n| Safe areas | Required (notch, home indicator) | Edge-to-edge with system bar insets |\n\n### Color\n\n| Aspect | iOS | Android |\n|---|---|---|\n| System colors | Dynamic (adapt to light\u002Fdark) | Material color roles (primary, secondary, surface) |\n| Accent color | App tint color | Primary color from seed |\n| Dark mode | Elevated surfaces are lighter | Tonal elevation (surface color shifts) |\n| Contrast | System provides high-contrast variants | Medium\u002FHigh contrast themes available |\n| Color scheme | System colors + custom via asset catalog | Dynamic color from wallpaper (Android 12+) |\n\n### Components\n\n| Component | iOS | Android |\n|---|---|---|\n| Primary button | Filled or plain text | Filled button (FilledButton) |\n| Secondary button | Tinted or outline | Outlined button (OutlinedButton) |\n| Toggle | UISwitch (green\u002Fgray) | Material Switch |\n| Date picker | Wheel or compact popup | Calendar dialog |\n| Alert | Centered, stacked buttons | Dialog, side-by-side buttons |\n| Action menu | Action sheet (bottom) | Bottom sheet or popup menu |\n| Search | Search bar in navigation | SearchBar widget |\n| Pull to refresh | UIRefreshControl | SwipeRefreshLayout |\n\n### When to follow platform vs cross-platform\n\nFollow platform conventions when:\n\n- The control has a direct platform equivalent (alerts, date\n  pickers, sheets).\n- The gesture is platform-specific (iOS swipe-back, Android system\n  back).\n- Users expect platform-consistent behavior (share sheets,\n  notifications).\n- Accessibility features depend on native patterns (VoiceOver,\n  TalkBack).\n\nUse cross-platform consistency when:\n\n- The feature is unique to your app (custom visualizations, brand\n  experience).\n- The interaction has no strong platform equivalent.\n- Maintaining two designs would create user confusion between\n  platforms.\n- Your brand identity requires visual consistency.\n\n### Key principles\n\n1. **Respect the platform** — users spend 99% of their time in other\n   apps.\n2. **Prioritize usability** — a familiar pattern beats a clever\n   custom solution.\n3. **Test on both platforms** — what feels natural on iOS may feel\n   foreign on Android.\n4. **Use adaptive layouts** — design once, adapt to platform\n   conventions in code.\n5. **Accessibility first** — both platforms provide excellent a11y\n   tools; use them.\n\n### Further reading\n\n- `references\u002Fplatform-guidelines.md` — source for the iOS vs\n  Material comparison tables above.\n- [Apple Human Interface Guidelines](https:\u002F\u002Fdeveloper.apple.com\u002Fdesign\u002Fhuman-interface-guidelines\u002F)\n- [Material Design 3](https:\u002F\u002Fm3.material.io\u002F)\n",{"name":5,"metadata":54,"description":60},{"processkit":55},{"id":56,"created":57,"version":58,"category":32,"apiVersion":59},"SKILL-mobile-app-design",1775433600000,"1.1.0","processkit.projectious.work\u002Fv2","Mobile app UX — touch targets, navigation, platform conventions, accessibility. Use when designing mobile interfaces, reviewing mobile UX, adapting web designs for mobile, or reconciling iOS and Android conventions.\n","main","7231f100e266e30d2c1699ecde5c00602471dc3c","src\u002Fcontext\u002Fskills\u002Fdesign\u002Fmobile-app-design","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add projectious-work\u002Fprocesskit --skill mobile-app-design",{"tool":74,"command":75},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill mobile-app-design",{"tool":77,"command":78},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill mobile-app-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fdesign\u002Fmobile-app-design\u002FSKILL.md",true,[82,88],{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fplatform-guidelines.md","REFERENCE","参考文档",3940,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fdesign\u002Fmobile-app-design\u002Freferences\u002Fplatform-guidelines.md",{"path":89,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":14,"sourceHtmlUrl":92},"scripts\u002F.gitkeep","SCRIPT","脚本","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fdesign\u002Fmobile-app-design\u002Fscripts\u002F.gitkeep",[94,119,139,160,177,195],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":103,"publishedAt":49},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[100],{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[104,105,106,107,108,109,43,110,111,112,96,113,114,115,116,117,118],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":126,"publishedAt":49},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[125],{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},[104,127,128,129,130,131,109,43,132,133,111,134,135,136,113,137,138],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":49},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[104,146,147,106,107,148,109,43,149,150,151,152,113,153,154,155,156,157,158,159],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":49},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[104,112,167,106,109,168,169,132,170,149,111,171,172,113,173,174,154,175,116,176],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":183,"publishedAt":49},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[184,185,186,187,109,188,189,190,43,191,192,193,194],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":201,"publishedAt":49},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[104,202,203,106,107,148,109,168,43,110,149,204,111,151,113,174,154,155,205,118],"capability","capability management","queries","changes"]