Skip to content
Expo Development Foundation
Esc
navigateopen⌘Jpreview
On this page

Authoring

Author and vendor neutral Expo skills.

Every skill has YAML frontmatter whose name and description match the manifest, an Inputs: section, an Output: section, and a focused Verification: section. Local references must resolve, and unresolved TODOs are rejected.

Keep skills reusable: avoid branding, user paths, secrets, hidden network behavior, and assumptions about paid EAS access. Update the manifest, then regenerate the catalog and run the skill verification scripts.

Upstream vendor sync

Many skills are foundation-owned procedures; others are snapshot-style guides adapted from Expo docs or examples. Stale Expo guidance is worse than a missing skill—refresh deliberately.

Kind Ownership Refresh
Foundation routers/orchestration (expo-development-foundation, expo-bootstrap, expo-project-orientation, expo-verify) Foundation-owned Update when routing or contracts change
Capability skills (expo-auth, expo-permissions, expo-linking, …) Foundation-owned Update when Expo APIs or failure modes change
Snapshot/vendored guides (some UI, EAS CLI detail skills) Snapshot of external Expo sources Re-read current Expo docs before material edits; note SDK assumptions
External skills outside this catalog Not installed here See docs/reference/external-skills.mdx — do not auto-vendor

The manifest records this ownership explicitly with source_id:

  • foundation is maintained by this repository and has no upstream snapshot object.
  • expo-official is a vendored snapshot and must carry snapshot status, revision, and verification date fields.

An unverified snapshot is not known to be broken. It means the repository has not recorded a verified upstream revision and date, so no agent may describe it as current. Its revision and date remain null rather than guessed.

Refreshing an official snapshot requires separately approved upstream research through TinyFish under the repository research policy. A verified refresh must record the actual upstream revision and an ISO YYYY-MM-DD verification date.

Docs rule: docs/skills/index.mdx documents only the foundation-owned skills. Official skills are link-outs to https://docs.expo.dev/skills/ — do not copy their procedure here.

Process:

  1. Prefer capability skills over one-skill-per-package.
  2. When refreshing a snapshot skill, verify commands against current Expo docs for the targeted SDK; remove invented flags.
  3. Keep manifest.json + ./Scripts/generate-skill-catalog.py in sync.
  4. Do not pull unrelated external agent skills into the installable catalog.
  5. Sync the Blume site: a new skill or significant change always updates docs/ (new page + meta.ts registration, or a revision of the affected page); minor edits get a review pass with a judgment call. Record the decision (updated vs reviewed-no-change-needed) in the final summary.

Was this page helpful?