expo-cicd-workflows

Visión general de la skill expo-cicd-workflows

La skill expo-cicd-workflows te ayuda a crear, editar y validar YAML de EAS Workflows para proyectos Expo. Está pensada sobre todo para desarrolladores que ya tienen claro qué quieren automatizar —builds, tests, submissions, updates o pipelines de despliegue de varios pasos— pero no quieren adivinar la sintaxis vigente de EAS Workflows.

Qué trabajo resuelve realmente esta skill

No es un paquete genérico de prompts para CI/CD. La tarea real que resuelve es convertir un objetivo de despliegue en un archivo .eas/workflows/*.yml válido que respete las reglas actuales de Expo EAS Workflows: tipos de job, triggers, expresiones y restricciones del esquema.

Quién debería instalar expo-cicd-workflows

Usa expo-cicd-workflows si:

• publicas una app con Expo y quieres CI/CD dentro de EAS Workflows
• necesitas ayuda para escribir o corregir YAML en .eas/workflows/
• quieres que un agente razone con sintaxis específica de Expo en lugar de apoyarse en patrones genéricos de GitHub Actions
• te importa validar contra el esquema en vivo, no contra ejemplos desactualizados

Por qué esta skill es mejor que un prompt simple

La diferencia principal es que la skill indica al agente que consulte el esquema y la documentación actual de Expo antes de generar YAML. Eso importa porque las opciones de EAS Workflows evolucionan, y los valores enum inválidos o los campos obsoletos son puntos de fallo muy habituales cuando se usan prompts corrientes.

Qué incluye

El repositorio es pequeño, pero práctico:

• SKILL.md explica cómo consultar la documentación fuente de verdad
• scripts/fetch.js guarda en caché documentación remota con ETags
• scripts/validate.js valida archivos de workflow con ajv, ajv-formats y js-yaml

Eso hace que expo-cicd-workflows sea útil tanto para generar archivos nuevos como para corregir workflows existentes.

La limitación más importante que conviene conocer desde el principio

Esta skill se centra en el YAML de EAS Workflows, no en todo tu proceso de release móvil. Te ayudará a diseñar el archivo de workflow, pero seguirás teniendo que aportar detalles específicos del proyecto, como entornos de la app, estrategia de ramas, configuración de credenciales y qué significa exactamente “deploy” en tu equipo.

Cómo usar la skill expo-cicd-workflows

Contexto de instalación de expo-cicd-workflows

Instala la skill expo-cicd-workflows desde el repositorio de skills de Expo en el entorno donde tu agente de código pueda leer tu proyecto Expo y escribir archivos de workflow:

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

Si tu agente admite descubrimiento local de skills, asegúrate de que pueda acceder a los archivos instalados y ejecutar scripts auxiliares basados en Node.

Lee primero estos archivos

Empieza por estos archivos en este orden:

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

Este orden importa: SKILL.md define el procedimiento de trabajo, validate.js muestra el modelo de validación guiado por esquema y fetch.js explica el comportamiento de caché para referencias remotas.

Qué datos necesita de ti la skill

Para obtener un resultado útil, dale a la skill:

• tu objetivo de workflow: build, test, submit, update o flujo de release encadenado
• reglas de activación: rama, PR, horario, manual o después de otro workflow
• alcance por plataforma: iOS, Android o ambas
• necesidades de entorno: secrets, profiles, env vars, channels
• salidas deseadas: artifacts, updates, store submission, notifications
• archivo de destino: normalmente .eas/workflows/<name>.yml

Sin eso, el agente solo podrá producir un borrador genérico.

Convierte una petición vaga en un prompt sólido

Petición débil:

• “Hazme un workflow de despliegue para Expo.”

Mejor petición:

• “Usa la skill expo-cicd-workflows para crear .eas/workflows/release.yml para una app Expo. Actívalo con pushes a main. Genera builds de Android y iOS con perfiles de producción, ejecuta tests antes si está soportado y luego envía ambos builds. Explica qué secrets hacen falta y valida el YAML final contra el esquema actual de EAS.”

El segundo prompt da a la skill la estructura suficiente para elegir triggers, orden de jobs y pasos de validación.

Consulta siempre las referencias actuales de Expo

Esta skill está diseñada para trabajar con documentación actual, no con la memoria del modelo. Antes de escribir o revisar YAML, consulta las referencias actuales que se mencionan en SKILL.md, en especial:

• https://api.expo.dev/v2/workflows/schema
• la documentación de sintaxis de Expo EAS Workflows
• la documentación de jobs preconfigurados de Expo

Ese es el hábito de mayor valor al usar expo-cicd-workflows for Deployment, porque la deriva del esquema es la forma más rápida de terminar con una salida inválida.

Valida el YAML generado antes de confiar en él

El patrón de uso más sólido es:

1. pedir al agente que redacte el workflow
2. guardarlo en .eas/workflows/
3. ejecutar el script de validación
4. corregir los errores de esquema
5. solo entonces adaptar los valores específicos del proyecto

Ejemplo de flujo de validación:

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

Si lo ejecutas desde el contexto del directorio de la skill, el validador consultará el esquema en vivo y reportará errores de YAML o del esquema con las rutas de los campos.

Qué está comprobando realmente el script de validación de expo-cicd-workflows

validate.js analiza el YAML, carga el esquema en vivo de EAS y comprueba tu archivo con validación estricta de AJV. Esto detecta:

• YAML mal formado
• campos obligatorios ausentes
• valores enum no admitidos
• tipos incorrectos
• estructura superior o anidada inválida

Eso hace que el flujo de expo-cicd-workflows usage sea mucho más seguro que copiar ejemplos de publicaciones antiguas.

Flujo recomendado para proyectos reales

Un flujo práctico es:

1. revisar tu eas.json actual y tu proceso de release
2. indicar al agente cuál es el trigger y la salida deseada
3. pedir un archivo de workflow inicial junto con una explicación de sus supuestos
4. validar el YAML
5. ajustar secrets, nombres de profiles, channels y filtros de rama
6. ejecutar primero un workflow de alcance reducido antes de convertirlo en tu pipeline principal de release

Así minimizas el problema más común al adoptarlo: generar YAML sintácticamente válido que, aun así, hace lo incorrecto a nivel operativo.

El mejor patrón de prompt para editar workflows existentes

Cuando revises un archivo actual, incluye el YAML completo y la solicitud de cambio. Ejemplo:

• “Usa expo-cicd-workflows para actualizar este .eas/workflows/preview.yml. Mantén los jobs de build existentes, pero actívalo solo en PRs hacia develop, añade un paso para preview updates y conserva los nombres actuales de las variables de entorno. Valida el resultado e indica cualquier campo no admitido.”

Esto ayuda al agente a conservar la intención en lugar de reescribir todo el archivo.

Detalles del repositorio que conviene compartir con la skill

El agente funcionará mejor si le proporcionas:

• eas.json
• archivos existentes .eas/workflows/*.yml
• reglas de nombres de ramas
• si usas EAS Update
• si el envío a stores forma parte de tu CI/CD
• cualquier convención de nombres para profiles o entornos

Estas entradas mejoran de forma material la calidad de la expo-cicd-workflows guide, porque la skill es muy específica en sintaxis, pero la forma real del release la define tu repositorio.

FAQ de la skill expo-cicd-workflows

¿expo-cicd-workflows sirve solo para archivos de workflow nuevos?

No. expo-cicd-workflows también es útil para revisar, depurar y modernizar YAML existente de EAS Workflows, especialmente cuando un archivo se escribió con documentación antigua o se copió de un ejemplo incompleto.

¿Es mejor que pedir YAML genérico de CI/CD?

Sí, si tu objetivo es EAS Workflows. Los prompts genéricos de CI/CD suelen desviarse hacia conceptos de GitHub Actions que no encajan bien con la sintaxis de .eas/workflows/. Esta skill está ajustada a la estructura y validación específicas de Expo.

¿Necesito conocer ya EAS Workflows?

Los usuarios principiantes también pueden usar la skill, pero los mejores resultados llegan cuando puedes responder preguntas básicas de release: qué activa el workflow, qué entornos existen y qué debe hacer el paso final de despliegue. La skill ayuda más con la sintaxis y la estructura que con la estrategia de producto.

¿Cuándo no debería usar expo-cicd-workflows?

Sáltatela si:

• no usas Expo EAS Workflows
• necesitas un diseño completo de CI multiplataforma fuera del tooling de Expo
• tu principal problema es la firma de la app, las credenciales o la política de las stores, y no el YAML del workflow
• buscas un despliegue de un clic sin decisiones específicas del repositorio

¿La skill instala dependencias del proyecto?

No. El paso de expo-cicd-workflows install instala la skill en sí, pero la validación depende de las dependencias del script en scripts/package.json. Si quieres ejecutar el validador en local, instala esas dependencias en el directorio del script.

¿expo-cicd-workflows puede garantizar un pipeline de despliegue funcional?

No. Puede mejorar la corrección del archivo de workflow y reducir errores de esquema, pero que el despliegue funcione de verdad sigue dependiendo de credenciales, profiles, secrets, configuración de la app y de cómo esté montado tu proyecto Expo.

Cómo mejorar la skill expo-cicd-workflows

Da intención de despliegue, no solo un nombre de archivo

La forma más rápida de mejorar la salida de expo-cicd-workflows es describir claramente la intención del release:

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

La intención permite que el agente elija triggers y secuencias de jobs más adecuadas.

Aporta la configuración de Expo que rodea al workflow

Incluye eas.json, los archivos de workflow existentes y cualquier convención de nombres de entorno. Muchas salidas flojas aparecen porque el agente inventa nombres de profiles, channels o supuestos que no existen en tu proyecto.

Pide a la skill que explicite sus supuestos

Un prompt sólido termina con algo como:

• “Lista los supuestos antes de cerrar el YAML.”
• “Marca los campos que dependan de valores específicos del repositorio.”
• “Explica qué secrets o profiles deben existir previamente.”

Eso hace que el primer borrador sea más fácil de revisar y reduce los fallos ocultos.

Usa ciclos de validar-corregir

Para obtener mejores resultados, trata expo-cicd-workflows usage como un proceso iterativo:

1. generar el YAML
2. validarlo
3. pegar de vuelta los errores exactos
4. pedir una versión corregida

Como el validador informa rutas concretas del esquema, la segunda pasada suele tener mucha más calidad que la primera.

Vigila estos modos de fallo habituales

Entre los problemas más comunes están:

• mezclar sintaxis de GitHub Actions dentro de EAS Workflows
• usar nombres de campos o enum desactualizados
• omitir detalles del trigger
• dependencias entre jobs poco claras
• asumir profiles, channels o secrets que tu repositorio no tiene

La mayoría de estos problemas se evitan obligando a la skill a consultar la documentación actual y compartiendo tus archivos de configuración reales.

Pide primero workflows mínimos viables

Si la adopción se bloquea por complejidad, pide primero el workflow válido más pequeño que demuestre la forma del pipeline y luego amplíalo. Ejemplo:

• primero crea un build manual de Android
• luego añade triggers por rama
• después añade iOS
• por último incorpora pasos de submission o update

Esto reduce el coste de depuración y suele ser la mejor forma de adoptar expo-cicd-workflows for Deployment.

Mejora la calidad de la salida con prompts ricos en restricciones

Un buen prompt avanzado incluye:

• ruta del archivo de destino
• condiciones de activación
• alcance por plataforma
• jobs requeridos en orden
• profiles o channels
• qué debe permanecer sin cambios
• petición de validar contra el esquema en vivo

Esa combinación produce resultados más fiables que pedir “un workflow completo de CI/CD” en una sola frase.

Usa los scripts auxiliares como anclas de confianza

La fortaleza menos visible de expo-cicd-workflows no está solo en las instrucciones escritas. Está en las herramientas auxiliares:

• fetch.js reduce el riesgo de documentación desactualizada con caché y ETags
• validate.js impone corrección frente al esquema en vivo

Si quieres mejores resultados, indica al agente que use esos scripts como parte del flujo de trabajo, no solo como extras opcionales.