Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →bartsoj/MOBILE_IA.md
Generate a native mobile information architecture registry — platform strategy, navigation model, deep-link strategy, permissions strategy, screen-template inventory, per-screen blueprints, flows, shared surfaces, push notifications, lifecycle behavior, and use-case traceability.
Passed 18 of 22 test cases with the skill, and 11 of 22 without it.
and 6 more in the full report
7 fixed11 passed either way4 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
Our mobile application is targeted strictly at English users in North America and supports only a single locale (en-US). How should the Internationalization section be handled in our registry document?
| Checked | Without skill | With skill |
|---|---|---|
| omits the Internationalization section entirely when supporting only a single locale | Missed | Passed |
The instructions your model reads when the skill loads.
Produce a MOBILE_IA.md that serves as the single source of truth for a native mobile application's information architecture: the platform strategy, navigation model (stack / tab / drawer / modal), deep-link strategy, permissions strategy, full screen-template inventory, per-screen blueprint (purpose, sections, primary CTA, data dependencies, gestures, orientation, permissions, platform variations, state matrix including offline and permission-denied, entry/exit points, lifecycle behavior, parameter-dependent behavior), cross-screen flows, shared native surfaces, push-notification architecture, terminal and background lifecycle behavior, global states, orientation and form-factor strategy, accessibility commitments, and bidirectional traceability from product use cases to screens. An agent or designer reading this document knows exactly what screens exist, how users move between them, what permissions and platform behavior each screen depends on, and how every use case is realized on the native mobile surface — without making any independent architectural decisions. MOBILE_IA sits between product requirements (proposal, use cases) and per-unit mobile SPECs, the same way WEB_IA and CLI_IA do for their respective surfaces.
NavGraph.kt, AppCoordinator.swift, route tables, AndroidManifest.xml, Info.plist). Treat as reference only — MOBILE_IA is the target state, not a mirror of the current state.WEB_IA.md, CLI_IA.md, VOICE_IA.md, TUI_IA.md. If present, use-case traceability must be consistent across channels. Every use case surfaces on at least one channel or is explicitly classified as having none.EP-name; wire formats are owned by INTERFACES.md, not redefined here.The user may override scope (e.g., "iOS only, defer Android", or "phone only, defer tablet"). Support that by recording the narrowed scope in the Identity & Context section and excluding out-of-scope surfaces from the inventory.
Scope note: this skill covers native mobile surfaces — apps distributed through App Store or Google Play, running on iOS or Android, built natively or with cross-platform frameworks (React Native, Flutter, Kotlin Multiplatform). WebView-wrapped web apps are out of scope — use WEB_IA.md for those. Terminal-invoked binaries are in CLI_IA.md. Full voice UIs are in VOICE_IA.md (but App Intents / Siri Shortcuts / Google Assistant actions as mobile-app invocation points are in scope here).
Mobile IA generation proceeds in seven phases: scope, platform-and-navigation globals, inventory, per-screen blueprint, flows and shared surfaces, push and lifecycle and global states, traceability and validation. Phases are sequential — later phases depend on earlier decisions — but revisit earlier phases if a later phase reveals a gap.
Derive from the product doc and use cases document the target mobile surface (iOS only, Android only, both; phone only, phone and tablet; with or without wearable / CarPlay / widget companions) and the audiences the IA serves. Record explicitly what is not in scope for this MOBILE_IA document — WebView wrappers, non-mobile surfaces, companion platforms the team is deferring. Keep audience treatment thin — named user types and their 3–7 top tasks per audience. No deep persona work.
Lock the four centralized sections before enumerating screens. This prevents per-screen drift where each screen reinvents its navigation placement, deep-link shape, or permission handling.
Platform Strategy. Decide:
test cases passed, vs 11 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.