expo-cicd-workflows

Overview of expo-cicd-workflows skill

The expo-cicd-workflows skill helps you create, edit, and validate EAS workflow YAML for Expo projects. It is best for developers who already know what they want to automate—builds, tests, submissions, updates, or multi-step deployment pipelines—but do not want to guess the current EAS workflow syntax.

What job this skill actually does

This is not a generic CI/CD prompt pack. The real job-to-be-done is to turn a deployment goal into a valid .eas/workflows/*.yml file that matches current Expo EAS workflow rules, job types, triggers, expressions, and schema constraints.

Who should install expo-cicd-workflows

Use expo-cicd-workflows if you:

• ship an Expo app and want CI/CD inside EAS Workflows
• need help writing or fixing .eas/workflows/ YAML
• want an agent to reason about Expo-specific workflow syntax instead of generic GitHub Actions patterns
• care about validation against the live schema, not stale examples

Why this skill is better than a plain prompt

The main differentiator is that the skill tells the agent to fetch the current Expo workflow schema and docs before generating YAML. That matters because EAS workflow options evolve, and invalid enum values or outdated fields are common failure points when using ordinary prompts.

What it includes

The repository is small but practical:

• SKILL.md explains how to fetch source-of-truth docs
• scripts/fetch.js caches remote docs with ETags
• scripts/validate.js validates workflow files with ajv, ajv-formats, and js-yaml

That makes expo-cicd-workflows useful both for generation and for correction of existing workflow files.

Biggest limitation to know up front

This skill focuses on EAS workflow YAML, not your entire mobile release process. It will help design the workflow file, but you still need to provide project-specific details like app environments, branch strategy, credentials setup, and what “deploy” should mean in your team.

How to Use expo-cicd-workflows skill

Install context for expo-cicd-workflows

Install the expo-cicd-workflows skill from the Expo skills repository in the environment where your coding agent can read your Expo project and write workflow files:

npx skills add https://github.com/expo/skills --skill expo-cicd-workflows

If your agent supports local skill discovery, make sure it can access the installed files and run Node-based helper scripts.

Read these files first

Start with these files in order:

1. plugins/expo/skills/expo-cicd-workflows/SKILL.md
2. plugins/expo/skills/expo-cicd-workflows/scripts/validate.js
3. plugins/expo/skills/expo-cicd-workflows/scripts/fetch.js

This reading path is important: SKILL.md gives the operating procedure, validate.js shows the schema-driven validation model, and fetch.js explains the caching behavior for remote references.

What inputs the skill needs from you

To get a useful result, give the skill:

• your workflow goal: build, test, submit, update, or chained release flow
• trigger rules: branch, PR, schedule, manual, or after another workflow
• platform scope: iOS, Android, or both
• environment needs: secrets, profiles, env vars, channels
• desired outputs: artifacts, updates, store submission, notifications
• file target: usually .eas/workflows/<name>.yml

Without these, the agent can only produce a generic draft.

Turn a rough request into a strong prompt

Weak request:

• “Make me an Expo deployment workflow.”

Better request:

• “Use the expo-cicd-workflows skill to create .eas/workflows/release.yml for an Expo app. Trigger on pushes to main. Build Android and iOS production profiles, run tests first if supported, then submit both builds. Explain any required secrets and validate the final YAML against the current EAS schema.”

The second prompt gives the skill enough structure to choose triggers, job order, and validation steps.

Always fetch current Expo references

This skill is designed around current documentation, not memory. Before writing or revising YAML, fetch the current references mentioned in SKILL.md, especially:

• https://api.expo.dev/v2/workflows/schema
• Expo EAS workflows syntax docs
• Expo pre-packaged jobs docs

That is the highest-value habit when using expo-cicd-workflows for Deployment, because schema drift is the fastest way to get invalid output.

Validate generated YAML before trusting it

The strongest usage pattern is:

1. ask the agent to draft the workflow
2. save it under .eas/workflows/
3. run the validator script
4. fix schema errors
5. only then adapt project-specific values

Example validation flow:

cd plugins/expo/skills/expo-cicd-workflows/scripts
npm install
node validate.js /path/to/project/.eas/workflows/release.yml

If you are invoking from the skill directory context, the validator will fetch the live schema and report YAML or schema errors with field paths.

What the validation script is actually checking

validate.js parses YAML, loads the live EAS schema, and checks your file with strict AJV validation. This catches:

• malformed YAML
• missing required fields
• unsupported enum values
• wrong types
• invalid top-level or nested structure

That makes the expo-cicd-workflows usage flow much safer than copying examples from old blog posts.

Suggested workflow for real projects

A practical workflow is:

1. inspect your existing eas.json and release process
2. tell the agent your desired trigger and output
3. ask for an initial workflow file plus explanation of assumptions
4. validate the YAML
5. revise secrets, profile names, channels, and branch filters
6. run a small-scope workflow before making it your main release pipeline

This minimizes the most common adoption problem: generating syntactically valid YAML that still does the wrong operational job.

Best prompt pattern for editing existing workflows

When revising a current file, include the full YAML and the change request. Example:

• “Use expo-cicd-workflows to update this .eas/workflows/preview.yml. Keep existing build jobs, but only trigger on PRs to develop, add a step for preview updates, and preserve current environment variable names. Validate the result and call out any unsupported fields.”

This helps the agent preserve intent instead of rewriting the whole file.

Common repo details to share with the skill

The agent will perform better if you provide:

• eas.json
• existing .eas/workflows/*.yml
• branch naming rules
• whether you use EAS Update
• whether store submission is part of CI/CD
• any naming conventions for profiles or environments

Those inputs materially improve expo-cicd-workflows guide quality because the skill is specific about syntax, but your repo defines the release shape.

expo-cicd-workflows skill FAQ

Is expo-cicd-workflows only for new workflow files?

No. expo-cicd-workflows is also useful for reviewing, debugging, and modernizing existing EAS workflow YAML, especially when a file was written against older docs or copied from an incomplete example.

Is this better than asking for generic CI/CD YAML?

Yes, if your target is EAS Workflows. Generic CI/CD prompting often drifts into GitHub Actions concepts that do not map cleanly to .eas/workflows/ syntax. This skill is tuned for Expo-specific workflow structure and validation.

Do I need to know EAS Workflows already?

Beginner users can still use the skill, but the best results come when you can answer basic release questions: what triggers the workflow, what environments exist, and what the final deployment step should do. The skill helps with syntax and structure more than product strategy.

When should I not use expo-cicd-workflows?

Skip it if:

• you are not using Expo EAS Workflows
• you need a full cross-platform CI design outside Expo tooling
• your main problem is app signing, credentials, or store policy rather than workflow YAML
• you want one-click deployment with no repo-specific decisions

Does the skill install project dependencies?

No. The expo-cicd-workflows install step installs the skill itself, but validation depends on the Node script dependencies in scripts/package.json. If you want to run the validator locally, install those dependencies in the script directory.

Can expo-cicd-workflows guarantee a working deployment pipeline?

No. It can improve correctness of the workflow file and reduce schema errors, but a working deployment still depends on credentials, profiles, secrets, app config, and how your Expo project is set up.

How to Improve expo-cicd-workflows skill

Give deployment intent, not just a file name

The fastest way to improve expo-cicd-workflows output is to describe the release intent clearly:

• “preview updates on PRs”
• “nightly internal builds”
• “production store submission from main”
• “manual hotfix release”

Intent lets the agent choose more appropriate triggers and job sequencing.

Provide the surrounding Expo config

Include eas.json, existing workflow files, and any environment naming conventions. Many weak outputs happen because the agent invents profile names, channels, or assumptions that do not exist in your project.

Ask the skill to state assumptions explicitly

A strong prompt ends with:

• “List assumptions before finalizing YAML.”
• “Mark fields that depend on repo-specific values.”
• “Explain what secrets or profiles must already exist.”

This makes the first draft easier to review and lowers hidden breakage.

Use validate-fix loops

For best results, treat expo-cicd-workflows usage as iterative:

1. generate YAML
2. validate
3. paste the exact errors back
4. ask for a corrected version

Because the validator reports concrete schema paths, the second pass is usually much higher quality than the first.

Watch for these common failure modes

Common issues include:

• mixing GitHub Actions syntax into EAS workflows
• using outdated field names or enums
• missing trigger details
• unclear job dependencies
• assuming profiles, channels, or secrets that your repo does not have

Most of these are prevented by forcing the skill to fetch current docs and by sharing your actual config files.

Ask for minimal viable workflows first

If adoption is blocked by complexity, ask for the smallest valid workflow that proves the pipeline shape, then expand it. Example:

• first create a manual Android build
• then add branch triggers
• then add iOS
• then add submission or update steps

This reduces debugging cost and is often the best way to adopt expo-cicd-workflows for Deployment.

Improve output quality with constraint-rich prompts

A good advanced prompt includes:

• target file path
• trigger conditions
• platform scope
• required jobs in order
• profiles or channels
• what must stay unchanged
• request to validate against live schema

That combination produces more reliable results than asking for “a full CI/CD workflow” in one sentence.

Use the helper scripts as trust anchors

The hidden strength of expo-cicd-workflows is not just the written instructions. It is the helper tooling:

• fetch.js reduces stale-doc risk with caching and ETags
• validate.js enforces live-schema correctness

If you want better results, tell the agent to use those scripts as part of the workflow, not just as optional extras.