--- name: expo-cicd-workflows description: 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. risk: critical source: https://github.com/expo/skills/tree/main/plugins/expo/skills/expo-cicd-workflows source_repo: expo/skills source_type: official date_added: 2026-07-01 license: MIT license_source: https://github.com/expo/skills/blob/main/LICENSE --- # EAS Workflows Skill ## When to Use Use this skill when you need 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. Help developers write and edit EAS CI/CD workflow YAML files. ## Local helper behavior and deployment scope This tree bundles fetch.js, validate.js and package.json, not installed dependencies. Inspect them before execution: fetch accepts arbitrary URLs, follows platform redirects, caches text in a runtime-generated .cache directory beside the fetch helper and has no built-in timeout/response-size limit. Use only the fixed official resources below over HTTPS within a bounded network environment; never pass untrusted/private URLs or credentials. Validation fetches live schema and parses local YAML; record retrieval time/schema identity because results can change. Node must support import.meta.dirname/main, and installation needs reviewed compatible dependencies. Structural validation does not run the workflow, prove secret isolation, or authorize billable builds, submission, deployment or recurring triggers. ## Reference Documentation Fetch these resources before generating or validating workflow files. First resolve this skill's directory, then use the fetch script in its `scripts/` directory. It is implemented using Node.js and caches responses using ETags for efficiency: ```bash # Fetch resources node /scripts/fetch.js ``` 1. **JSON Schema** — https://api.expo.dev/v2/workflows/schema - It is NECESSARY to fetch this schema - Source of truth for validation - All job types and their required/optional parameters - Trigger types and configurations - Runner types, VM images, and all enums 2. **Syntax Documentation** — https://raw.githubusercontent.com/expo/expo/refs/heads/main/docs/pages/eas/workflows/syntax.mdx - Overview of workflow YAML syntax - Examples and English explanations - Expression syntax and contexts 3. **Pre-packaged Jobs** — https://raw.githubusercontent.com/expo/expo/refs/heads/main/docs/pages/eas/workflows/pre-packaged-jobs.mdx - Documentation for supported pre-packaged job types - Job-specific parameters and outputs Do not rely on memorized values; these resources evolve as new features are added. ## Workflow File Location Workflows live in `.eas/workflows/*.yml` (or `.yaml`). ## Top-Level Structure A workflow file has these top-level keys: - `name` — Display name for the workflow - `on` — Triggers that start the workflow (at least one required) - `jobs` — Job definitions (required) - `defaults` — Shared defaults for all jobs - `concurrency` — Control parallel workflow runs Consult the schema for the full specification of each section. ## Expressions Use `${{ }}` syntax for dynamic values. The schema defines available contexts: - `github.*` — GitHub repository and event information - `inputs.*` — Values from `workflow_dispatch` inputs - `needs.*` — Outputs and status from dependent jobs - `jobs.*` — Job outputs (alternative syntax) - `steps.*` — Step outputs within custom jobs - `workflow.*` — Workflow metadata ## Generating Workflows When generating or editing workflows: 1. Fetch the schema to get current job types, parameters, and allowed values 2. Validate that required fields are present for each job type 3. Verify job references in `needs` and `after` exist in the workflow 4. Check that expressions reference valid contexts and outputs 5. Ensure `if` conditions respect the schema's length constraints ## Validation After generating or editing a workflow file, validate it against the schema: ```sh # Install dependencies if missing [ -d "/scripts/node_modules" ] || npm install --prefix /scripts node /scripts/validate.js [workflow2.yml ...] ``` The validator fetches the latest schema and checks the YAML structure. Fix any reported errors before considering the workflow complete. ## Answering Questions 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. ## Limitations - Use this skill only when the task clearly matches its upstream product or API scope. - Verify commands, API behavior, pricing, quotas, credentials, and deployment effects against current official documentation before making changes. - Do not treat generated examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.