skills/expo-cicd-workflows/SKILL.md
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.
npx skillsauth add abogoyavlensky/agents expo-cicd-workflowsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
tools
Run a second-opinion code review using the Codex CLI (`codex exec review`) in the background and surface the findings when it finishes. Use when the user says "review with codex", "second-opinion review", "what does codex think", or wants an outside model to look at local changes (uncommitted, current branch vs main, or a named commit). Also used as the review checkpoint inside the `executing-plans` skill.
documentation
Create structured implementation plan in docs/plans/
development
Review local code changes — uncommitted work, the current branch vs main, or a specific commit — for code quality, minimal implementation, basic security, and feature completeness. Use this skill whenever the user asks to review code, review changes, review a branch, review a commit, audit a diff, sanity-check what's about to be committed, or asks "is this ready to ship?" — even when they don't say the word "review" explicitly. This is a fast local review run inside the project, not the cloud-based /ultrareview. The output is a severity-grouped findings report with file:line citations.
testing
Use when writing prose humans will read - documentation, commit messages, error messages, explanations, reports, or UI text. Applies Strunk's timeless rules for clearer, stronger, more professional writing.