Design Mobile

Make the user journey, platform constraints, and app architecture explicit before implementation. Target iOS with SwiftUI unless the project or user specifies otherwise, and respect the app's existing navigation, state, design-system, and networking patterns.

Lazy Design

Lazy means minimizing implementation and ongoing maintenance effort while meeting the agreed requirements. Read the relevant app code and trace affected user flows and state ownership before recommending a design. For fixes, address the cause at the appropriate shared owner. Favor readable, complete solutions over line-count targets.

Consider, in order: no change if the outcome is already met; reuse in the app; standard-library support; native platform features; installed dependencies; then minimal custom code or a justified new dependency. Stop when an option satisfies the contract and constraints. Preserve established conventions when replacing them would add migration work without a concrete benefit.

Require a current need for extra layers, configuration, or extension points. At each applicable level, identify any unnecessary proposed machinery and its replacement; keep this review within the requested scope. Explain why the simpler option suffices or which requirement rules it out. Preserve explicit requirements, accessibility, privacy, validation, data integrity, and necessary lifecycle and error handling. Propose scope reductions for agreement.

Dependency Gate

At Components, list every proposed new package, SDK, or third-party service, with its purpose and why the platform or existing dependencies cannot meet the need. Obtain explicit agreement for each before moving to Interactions. Do not add, install, configure, or assume approval for a new dependency.

Conversation

Start at Capabilities for new flows or platform integrations; start at Components for a bounded screen change. Never skip Contracts. Present one level at a time, then wait for explicit approval. Do not write code, change files, or show implementation snippets until the applicable design is approved.

1. Capabilities — Confirm user outcome, entry and exit paths, platforms, accessibility, offline behavior, permissions, analytics, and exclusions.
2. Components — Identify the screens, navigation destinations, state holders, domain use cases, repositories, and platform adapters actually needed; the list is not a required layer stack. Consider native SwiftUI controls and platform APIs before custom controls or SDKs. Reuse existing pieces first and obtain the dependency agreement.
3. Interactions — Trace user actions, navigation, lifecycle effects, loading/error/empty states, cache and sync behavior, deep links, and cancellation.
4. Contracts — Define UI states and events, state ownership, necessary domain/repository interfaces, API models, validation, and error mapping. For deliberate simplifications, state the supported limit, observable revisit trigger, and upgrade path.
5. Implementation — After approval, propose a minimal sequence with unit, UI, or device/platform checks appropriate to the affected behavior, including relevant accessibility and lifecycle cases; implement only when requested. Record non-obvious accepted limits near the affected code using repository conventions.

At every level, label assumptions, call out meaningful tradeoffs, and ask for the next decision. Do not add screens, permissions, tracking, or abstractions that were not agreed.