Task: Create SCREENSPEC.md for a Mobile Screen

Task: Create SCREEN_SPEC.md for a Mobile Screen

Objective

Produce a SCREEN_SPEC.md that serves as the single source of truth for composing one screen of a native mobile application: the screen shell (status bar, nav bar, bottom area, safe-area rules, scroll behavior), the region layout, the per-section composition with spacing and container treatment cited by token name, the per-component layout for non-standard widgets, an action-inventory table with placement and visibility rules, per-gesture interaction specs (target, effect, conflict resolution, haptics, cancel behavior), state-specific layout deltas, orientation and tablet rules, platform-variation deltas (iOS / Android / iPadOS), screen-specific motion, and accessibility commitments. The defining claim — and the definition of "done" — is that the gap between MOBILE_IA's blueprint plus DESIGN.md plus this SCREEN_SPEC and the screen as built is purely mechanical: an implementing agent reading those three artifacts composes the screen on each target platform without inventing spatial decisions, gesture handling, or platform-variant treatment.

The commonest violation is silently restating something MOBILE_IA already owns — re-listing sections, re-declaring the primary CTA, re-enumerating gestures, re-stating platform availability, redefining a state from the state matrix — instead of extending it with composition and interaction detail. SCREEN_SPEC owns how each named region and section is composed and how each gesture behaves; MOBILE_IA owns that those regions, sections, and gestures exist. When the SCREEN_SPEC needs a fact that is missing from MOBILE_IA (e.g., a section the screen has but MOBILE_IA does not list, a gesture not declared in MOBILE_IA's blueprint), surface that gap as an open question for /MOBILE_IA.md to resolve — do not silently add it.

Inputs

1. Screen identifier (required) — the stable screen ID from MOBILE_IA.md's Screen Inventory. The skill operates on exactly one screen per invocation.
2. MOBILE_IA.md (required) — the parent IA hub. Provides the per-screen blueprint to extend: route or deep-link, purpose, audience, auth requirement, platform set (iOS / Android / iPadOS), sections, primary CTA, secondary actions, gestures listed, orientation support, permissions involved, state matrix (including offline and permission-denied), entry / exit points, lifecycle behavior, parameter-dependent behavior, shared surfaces invoked. SCREEN_SPEC reads the entry for the named screen end-to-end, plus the centralized Navigation Model, Deep-Link Strategy, Permissions Strategy, and Shared Surfaces sections it references.
3. DESIGN.md (required if present) — global design system: design tokens (spacing, color, typography, elevation, radius), component library (with variants), layout templates (e.g., mobile-stack, mobile-tabs, mobile-modal, mobile-sheet, mobile-detail), breakpoints and safe-area rules, motion principles, typography scale, touch-target minimums. SCREEN_SPEC cites tokens, components, and templates by name from this document — it does not redefine them.
4. Sibling SCREEN_SPEC.md files (optional, auto-discovered) — SCREEN_SPECs for screens this screen flows into or out of, when MOBILE_IA's flows reference them. Discovery mechanism: walk the entry / exit points and flow references in MOBILE_IA's per-screen blueprint and load any sibling mobile-screens/<screen-id>/SCREEN_SPEC.md that exists. Use these only to keep transition direction and shared surface invocation consistent — do not duplicate their content.
5. Prior mobile-screens/<screen-id>/SCREEN_SPEC.md (optional, auto-discovered — only if refining) — read fully; preserve every resolved open question and every decision that survives the new MOBILE_IA. Re-run citations against the current MOBILE_IA and DESIGN — do not assume stale section names, token names, component names, layout template names, or gesture names are still valid.

Read-set size: MOBILE_IA + DESIGN are always read; 0–2 sibling SCREEN_SPECs and an optional prior version. Read MOBILE_IA's per-screen entry end-to-end — partial reads cause silent drift between blueprint and spec.

Rules

Selection rules

SCREEN_SPEC is opt-in. Before writing, verify the screen meets at least one criterion below; if it meets none, the screen should stay with its inline blueprint in MOBILE_IA.md and this skill should not produce output.

• Composition exceeds ~30 lines if expressed inline in MOBILE_IA's per-screen entry.
• Two or more states in MOBILE_IA's state matrix have materially different layouts (not just skeleton-vs-content).
• The screen uses gesture combinations not covered by DESIGN.md's component-level gestures.
• Platform behavior diverges substantively between iOS and Android in spatial composition (not just chrome).
• Tablet / iPad uses a composition different from phone.
• Multiple work units touch this screen and need a shared composition contract.
• The screen is flagship or high-traffic and the team has decided to invest in deep specification.

If the screen meets no criterion, surface the situation as the only entry in section 13 Open Questions with a recommendation to keep the screen inline in MOBILE_IA, rather than producing a half-spec.

Hub-leaf boundary rules