expo
Helps understand and write EAS workflow YAML files for Expo projects. Use this skill when the user asks about CI/CD or workflows in an Expo or EAS context, mentions .eas/workflows/, or wants help with EAS build pipelines or deployment automation.
bunx add-skill expo/skills -s expo-cicd-workflowsLoadingβ¦
Help developers write and edit EAS CI/CD workflow YAML files.
Fetch these resources before generating or validating workflow files. Use the fetch script (implemented using Node.js) in this skill's scripts/ directory; it caches responses using ETags for efficiency:
# Fetch resources
node {baseDir}/scripts/fetch.js <url>
JSON Schema β https://api.expo.dev/v2/workflows/schema
Syntax Documentation β https://raw.githubusercontent.com/expo/expo/refs/heads/main/docs/pages/eas/workflows/syntax.mdx
Pre-packaged Jobs β https://raw.githubusercontent.com/expo/expo/refs/heads/main/docs/pages/eas/workflows/pre-packaged-jobs.mdx
Do not rely on memorized values; these resources evolve as new features are added.
Workflows live in .eas/workflows/*.yml (or .yaml).
A workflow file has these top-level keys:
name β Display name for the workflowon β Triggers that start the workflow (at least one required)jobs β Job definitions (required)defaults β Shared defaults for all jobsconcurrency β Control parallel workflow runsConsult the schema for the full specification of each section.
Use ${{ }} syntax for dynamic values. The schema defines available contexts:
github.* β GitHub repository and event informationinputs.* β Values from workflow_dispatch inputsneeds.* β Outputs and status from dependent jobsjobs.* β Job outputs (alternative syntax)steps.* β Step outputs within custom jobsworkflow.* β Workflow metadataWhen generating or editing workflows:
needs and after exist in the workflowif conditions respect the schema's length constraintsAfter generating or editing a workflow file, validate it against the schema:
# Install dependencies if missing
[ -d "{baseDir}/scripts/node_modules" ] || npm install --prefix {baseDir}/scripts
node {baseDir}/scripts/validate.js <workflow.yml> [workflow2.yml ...]
The validator fetches the latest schema and checks the YAML structure. Fix any reported errors before considering the workflow complete.
When users ask about available options (job types, triggers, runner types, etc.), fetch the schema and derive the answer from it rather than relying on potentially outdated information.
Use when you need to run Flow type checking, or when seeing Flow type errors in React code.
Use when you want to validate changes before committing, or when you need to check all React contribution requirements.
Use when feature flag tests fail, flags need updating, understanding @gate pragmas, debugging channel-specific test failures, or adding new flags to React.
Use when you need to check feature flag states, compare channels, or debug why a feature behaves differently across release channels.