What this prompt does
This prompt casts the model as a senior mobile product designer and engineer building a companion app for AR glasses, and asks for working component code rather than screen descriptions. It enumerates six deliverables that define what a wearable companion really needs: a pairing flow with recovery, a connected-apps list with per-app display toggles, battery and connection status for both glasses and case, granular notification mirroring, display and voice setup, and a firmware-update screen with safe-to-disconnect guidance. The structure works because it forces the model to treat trust and control as the organizing principle, not a footnote.
Four variables shape the output. [stack] sets the framework (default React Native). [connection] describes how the glasses talk to the phone, such as Bluetooth LE plus Wi-Fi direct, which drives the pairing and status UI. [privacy_posture] is the most consequential: a value like "on-device by default, explicit opt-in for sharing" makes the model surface controls prominently instead of burying them. [mirrored_apps] lists which notification sources get per-source toggles. Together these turn a generic settings screen into a privacy-forward companion app where users feel they control what a face-worn camera can see and show.
When to use it
- You are designing a companion app for AR glasses, smart glasses, or another face-worn wearable.
- Pairing reliability and a recovery path matter because users will hit failed connections.
- Privacy and explicit user control over a camera-equipped device are central to the brief.
- You need per-app and per-source toggles for what the device may display or mirror.
- You want a firmware-update flow with progress, release notes, and safe-to-disconnect guidance.
- You need working components in a specific stack rather than a flat feature list.
Example output
Expect a navigation structure plus each key screen delivered as separate components in your [stack]: a pairing flow with explicit connection states and a failure-recovery path, a connected-apps list with per-app display toggles, dual battery and connection indicators for glasses and case, notification mirroring with per-source control over [mirrored_apps], display preferences (brightness, position, contrast) and voice-assistant setup, and a firmware-update screen. The emphasis throughout is on trust and user control over privacy, reflecting the [privacy_posture] you set.
Pro tips
- Make
[privacy_posture]explicit and strong; a clear stance like on-device-by-default produces visible, prominent controls instead of buried settings. - List real apps in
[mirrored_apps]so the per-source notification toggles map to your actual integrations. - Set
[connection]accurately, since the pairing states and status indicators depend on whether you use BLE, Wi-Fi direct, or both. - Insist the per-source toggles in the notification step stay obvious — that screen is where users decide whether to keep the device on.
- Swap
[stack]to your real framework so the generated screens are idiomatic rather than needing rewrites. - If pairing feels thin, re-run asking specifically for failure and recovery states, not just the happy path.
