expo/skills: Expo's Official Agent Skills, and Where They Stop

The problem: agents know React Native, not Expo's conventions

An agent asked to add tabs to a React Native app will produce something plausible and often wrong for Expo. It may invent a folder layout, reach for a navigation library Expo Router already replaces, or write an EAS workflow file with keys that do not exist. The README frames the gap directly: skills give agents "focused Expo knowledge: when to use Expo APIs, how to structure common workflows, and which Expo, EAS, React Native, iOS, and Android constraints matter." That is a narrower claim than general coding assistance, and it is the right one. The audience is anyone whose agent already touches an Expo codebase: people scaffolding a new app, upgrading an SDK, wiring EAS Build or EAS Update, or migrating a web app to native. If your agent never sees an app.json or an eas.json, nothing here applies.

How the skills are packaged and routed

Each skill is a directory containing a SKILL.md file, and the README states that agents pick a skill "from the task context and each skill's description." That means the description text is the routing layer, not decoration. A vague request lands on expo-overview, which the README calls "the entry point when a request is vague or the user hasn't named a specific Expo tool," and that skill then routes to something more specific. The set is split into four groups. Framework skills cover the open source SDK and React Native: project structure, Router, animation, native UI, design systems, @expo/ui, data fetching, DOM components, web-to-native migration, native modules, brownfield integration, dev clients, the expo/examples repo, App Clips, and SDK upgrades. Services skills cover EAS: app store builds and submissions, EAS Hosting, Workflows, Observe, Update, Update Insights, and a remote simulator. A third group holds experimental skills for APIs that are not finalized, shipped in a separate expo-experiments plugin. The README is explicit that these can change or be retired, and that they graduate into the main groups once the underlying API stabilizes. Treat anything in that group as moving target code.

The free and paid boundary is labelled, not hidden

This is the design decision I would point at first. Skills are grouped "so the free vs paid boundary is clear," each skill's description carries the same label, and every services skill opens with a costs and plan-limits note. So an agent advising you to set up EAS Update has the pricing context in its own instructions rather than silently recommending a paid service. Two entries sit awkwardly on that line. expo-dev-client is filed under Framework, but the README notes that local builds are free while EAS Build and TestFlight are a paid step. expo-skill-feedback is also under Framework, and it does two unrelated things: collect feedback on Expo's skills, docs and CLIs, and control opt-in usage telemetry. A skill that both reports on the tooling and toggles telemetry is worth reading in full before you let an agent run it.

Installing it: three paths, one command that matters

For Claude Code and Codex, the README recommends the plugin route so updates flow through the official marketplaces: claude plugin install expo@claude-plugins-official, or /plugin install expo@claude-plugins-official inside Claude Code; codex plugin add expo@openai-curated, or /plugins in Codex. For Cursor, OpenCode, GitHub Copilot, Windsurf, Gemini, Cline, AMP, Factory Droid, Antigravity, Kiro CLI and other agents, use the skills CLI. The command is npx skills@latest add expo/skills --skill '*'. The wildcard selects every Expo skill without selecting every agent, and the CLI still prompts for an install location unless you add --agent <agent>. Run it from the project root, then restart or refresh the agent session so it discovers the installed SKILL.md files. Updates differ by path: plugin installs update through their marketplace, while skills CLI installs use npx skills@latest update, or npx skills@latest update expo-router to refresh one skill by name. Note what the README does not give: no version pinning, no lockfile, and no documented way to audit what changed between two skill revisions.

Where it is the wrong tool

The README sets a boundary that is easy to skip past: "Expo documentation, Expo CLI, and EAS CLI remain the source of truth; these skills help agents apply them correctly." Skills are a routing and convention layer, not a reference. If a skill and the current docs disagree, the docs win, and the agent has no mechanism to detect that drift on its own. Two consequences follow. First, on a bare React Native project with no Expo dependency, most of this collection does not apply, and the experimental group is a poor fit for anything you intend to ship. Second, the collection is large enough that install-everything is not obviously the right default. Loading twenty-plus skills into an agent session has a cost in context and in routing noise, and the README offers no guidance on pruning beyond the --skill flag. If you only touch EAS Update, installing the whole set and hoping the descriptions sort it out is a bet you do not have to take.

Compared with pointing your agent at the Expo docs

The obvious alternative costs nothing and needs no install: give the agent the Expo documentation, or an MCP server over it, and let it read the relevant page per task. The difference is where the knowledge lives. Documentation retrieval is per-query and current, but it returns prose the agent must interpret, and nothing in a docs page tells the agent that a request is vague enough to start from an overview or that a task belongs to a paid service tier. expo/skills inverts that: the knowledge is pre-digested into conventions, with an explicit entry point and cost labels attached to descriptions. The trade is freshness. Docs retrieval cannot go stale between sessions; an installed skill can, which is why the update commands and the marketplace path exist. If your agent already has reliable docs access and you mostly ask narrow API questions, the skills add a routing layer you may not need. If your agent keeps producing structurally wrong Expo code, that is the failure this collection targets.

Maintenance, licensing, and what the repository does not tell you

The repository is MIT licensed, which permits commercial use and modification, but this is a description of the licence text rather than legal advice; check the LICENSE file yourself if you plan to fork or redistribute. Maintenance has two layers. The plugin paths delegate updates to the Claude Code and Codex marketplaces, so you inherit whatever cadence those marketplaces run at. The skills CLI path puts the cadence on you: npx skills@latest update is a manual step, and nothing in the README describes a scheduled check or a changelog per skill. The experimental group carries the highest maintenance cost because the README says its content may change or be retired. The material also does not cover what happens when two installed skills give conflicting guidance, how the skills interact with an agent's own system prompt, or how to verify that a skill was actually loaded after install. The README's own test is behavioural: ask the agent an Expo-specific question and see whether the answer reflects the skill. That is the check to run before trusting the install.

Editorial conclusion

Adopt expo/skills if your agent already writes Expo code and you want it to stop inventing folder layouts and EAS workflow YAML. Skip it if you work outside Expo, or if you want a general React Native knowledge base, because every skill here is scoped to Expo tooling. Before installing, read the description of expo-overview and one services skill to confirm the free versus paid labelling, then run npx skills@latest add expo/skills --skill '*' from your project root and restart the agent session so it discovers the SKILL.md files.

Official sources

1. expo/skills on GitHub
2. Issues
3. License: MIT
4. README