A settings screen only works if its controls change the intended setting, failed saves preserve edits, and larger text or the keyboard does not block the primary action. expo-native-ui guides an agent through native controls, platform styling, and screen structure. The notification-preferences exercise below goes from setup to device checks. It covers in-app preferences, not push-notification registration or operating-system permission by default.
Install the Skill and check the project runtime
Codex users can install the official Expo plugin from a terminal. Claude Code users can run claude plugin install expo@claude-plugins-official instead. For another Agent Skills client, run npx skills@latest add expo/skills --skill '*' from the project directory and select the client. The plugin brings Expo Skills and MCP configuration to the agent; it does not install @expo/ui into the app or create a screen. Refresh the agent session after installation.
codex plugin add expo@openai-curated
In the existing Expo project, have the agent read the Expo SDK version in package.json, the current screen, installed component libraries, and where settings are saved. The current expo-native-ui Skill consults the companion expo-ui Skill before choosing a control. Expo says @expo/ui native controls work in Expo Go on SDK 56 and later. For an older SDK, check its versioned documentation or keep a compatible component rather than copying a current example into the project.
If the chosen screen needs @expo/ui and the project does not have the package, run the following command inside the Expo project so Expo selects a version compatible with its SDK. This installs an app dependency; the agent plugin above is separate.
npx expo install @expo/ui
Give the agent a first task it can verify
Replace the bracketed path and saving details with those from your project:
Use expo-native-ui to update [existing settings screen path] with an in-app notification-preferences screen: three switches, a frequency choice, and Save. Do not add push registration in this task.
First read package.json, the current screen, and its settings persistence code. Report the SDK version, available iOS/Android controls, whether @expo/ui is needed, and whether Expo Go can run this project.
List loading, content, saving, and failed-save states before editing. Preserve unsaved changes after a failure and allow retry. If there is no persistence path, make it a clearly labeled local-state prototype; do not pretend the values were saved.
After editing, list changed files, how to open the screen on both platforms, and checks that you could not run.
The first useful response is a control and data-flow choice, followed by screen code and steps for running it. Establish what each switch controls: an existing business preference, device permission, or local preview state. Those are different behaviors and must not be collapsed into the same “Saved” alert. Expo UI’s universal Switch is controlled: wrap it in Host, connect value and onValueChange to state, and make Save call the project’s actual persistence path.
Run the screen and check the result
Run npx expo start from the project directory and scan the terminal QR code with Expo Go. In the Expo CLI, press a for an Android emulator or i for an iOS simulator. Try Expo Go first; use a development build only if the project requires a native module or native configuration that Expo Go lacks. If a physical device cannot open the QR code, check its network connection to the computer. On a physical iPhone, Expo Go and Expo CLI also need the same Expo account.
Walk through one real flow on each target platform: open the screen, change the switches and frequency, save, reopen, and compare the result with the app’s actual persistence model. Then make a save fail once and check that an error appears, the draft remains, and Retry works. A local-state prototype should not claim persistence across reopening. Check dark mode, large text, long labels, keyboard reachability, and screen-reader labels separately on iOS and Android. Ask the agent to report what it actually exercised on a device and what remains untested; one screenshot cannot verify interactions.
Troubleshoot the right layer
The agent cannot find the Skill: Check that the Expo plugin is enabled, refresh the session, and explicitly request expo-native-ui. Component selection should also load expo-ui. The agent plugin does not add @expo/ui to the app.
The @expo/ui import fails or Expo Go cannot open the app: Check the project SDK, whether npx expo install @expo/ui installed a compatible package, and whether another native module is absent from Expo Go. A runtime error is not automatically a screen-design problem, and an ordinary settings screen does not automatically need a cloud build.
The switch moves but Save changes nothing: Check the Switch value and change callback, the Save handler, its persistence destination, and the failure path. An empty handler or a success alert alone is not a settings implementation.
An Android button is larger than its iOS counterpart: One public reproduction used Expo SDK 57.0.22 and @expo/ui 57.0.18 on simulators: a Button requested at 34dp rendered at 48dp on Android and 34dp on iOS. For compact toolbars, inspect the rendered size and touch target on both platforms. This is a version-specific underlying-control report, not a claim that every project has the issue.