expo-cicd-workflows

Savant verdict: Review advised

SkillSpector or the source hub flagged patterns to review before use.

Live evaluation

0 pass · 0 investigate · 6 fail across 6 cases. Jev accepted 6 of 14 LLM-drafted cases. Drafted and run by nvidia/nemotron-3-super-120b-a12b, validated and scored by jev-latest.

• I want to set up a workflow that runs my Jest tests on Ubuntu-latest whenever a pull request is opened against the dev branch, and only if the tests pass, start a preview build for iOS.positive case · fail
• Show me an example of a workflow that uses workflow_dispatch with inputs for version name and version code, then builds an Android app bundle using those inputs.positive case · fail
• Make a workflow that triggers on schedule every Monday at 9 AM and only runs if the repository has fewer than 10 open issues.edge case · fail
• Write a GitHub Actions workflow that deploys to Firebase when a release is published.negative case · fail
• Help me configure Bitrise steps to cache Expo dependencies and run EAS build as part of a mobile CI pipeline.negative case · fail
• Create a workflow that runs on pull request and schedule triggers, but I want the schedule to override the pull request trigger when both occur at the same time.edge case · fail

Safety (NVIDIA SkillSpector)

9 patterns found

• MCP Least Privilege: Skill declares no tool scope ('permissions' or 'allowed-tools') but code capabilities were detected: network.medium · SKILL.md:1 · Without declared permissions the skill's intent is opaque and cannot be validated.
• Data Exfiltration: https://api.expo.dev/medium · SKILL.md:21 · Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
• Data Exfiltration: https://api.expo.dev/medium · scripts/validate.js:13 · Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
• Trigger Abuse: Overly Broad Triggerlow · SKILL.md:1 · Overly Broad Trigger: description clause 'Use this skill when the user asks about CI/CD or workflows in an Expo or EAS context, mentions' activates on 'CI', which is too short and may match unintended inputs
• Supply Chain: "ajv": "^8.17.1"low · scripts/package.json:7 · Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
• Supply Chain: ajvlow · scripts/package.json:7 · Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.
• Supply Chain: "ajv-formats": "^3.0.1"low · scripts/package.json:8 · Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
• Supply Chain: "js-yaml": "^4.1.0"low · scripts/package.json:9 · Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
• Supply Chain: js-yamllow · scripts/package.json:9 · Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.

Structure

• Ships 2 executable scriptsscripts/fetch.js, scripts/validate.js. Review what they do before enabling the skill for agents with tool access.

SKILL.md

---
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.
version: 1.0.0
license: MIT License
---

# EAS Workflows Skill

Help developers write and edit EAS CI/CD workflow YAML files.

## 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 <skill-dir>/scripts/fetch.js <url>
```

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 "<skill-dir>/scripts/node_modules" ] || npm install --prefix <skill-dir>/scripts

node <skill-dir>/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.

## 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.