expo-cicd-workflows

expo-cicd-workflows スキルの概要

expo-cicd-workflows スキルは、Expo プロジェクト向けの EAS workflow YAML を作成・編集・検証するためのスキルです。特に、ビルド、テスト、申請、アップデート、複数ステップのデプロイパイプラインなど、何を自動化したいかは決まっている一方で、最新の EAS workflow 構文を手探りで確認したくない開発者に向いています。

このスキルが実際に担う役割

これは汎用的な CI/CD 用プロンプト集ではありません。実際の役割は、デプロイの目的を、現在の Expo EAS workflow のルール、job type、trigger、式、schema 制約に合った有効な .eas/workflows/*.yml ファイルへ落とし込むことです。

expo-cicd-workflows を導入すべき人

次のような場合は expo-cicd-workflows が適しています。

• Expo アプリを運用していて、CI/CD を EAS Workflows 内で完結させたい
• .eas/workflows/ の YAML を書く、または修正する支援がほしい
• 汎用的な GitHub Actions パターンではなく、Expo 固有の workflow 構文を前提にエージェントへ考えさせたい
• 古いサンプルではなく、最新の schema に照らした検証を重視したい

単なるプロンプトより優れている理由

最大の差は、YAML を生成する前に、現在の Expo workflow schema とドキュメントを取得するようエージェントに指示している点です。EAS workflow のオプションは更新され続けるため、通常のプロンプトでは無効な enum 値や廃れたフィールドを使ってしまい、そこで失敗するケースがよくあります。

含まれているもの

リポジトリは小規模ですが実用的です。

• SKILL.md には、信頼できる一次情報の取得方法がまとまっている
• scripts/fetch.js は ETag を使ってリモートドキュメントをキャッシュする
• scripts/validate.js は ajv、ajv-formats、js-yaml で workflow ファイルを検証する

そのため expo-cicd-workflows は、新規生成だけでなく既存 workflow ファイルの修正にも役立ちます。

最初に知っておきたい最大の制約

このスキルが対象にしているのは EAS workflow YAML であり、モバイルリリース工程全体ではありません。workflow ファイルの設計は支援してくれますが、アプリごとの環境、ブランチ運用、credentials の設定、チーム内で「deploy」をどう定義するかといった情報は、引き続きあなたが与える必要があります。

expo-cicd-workflows スキルの使い方

expo-cicd-workflows の導入環境

expo-cicd-workflows スキルは、コーディングエージェントが Expo プロジェクトを参照でき、workflow ファイルを書き込める環境に、Expo skills repository からインストールします。

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

エージェントがローカルの skill discovery に対応しているなら、インストール済みファイルへアクセスできること、そして Node ベースの補助スクリプトを実行できることも確認してください。

まず読むべきファイル

最初は次の順で読むのがおすすめです。

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

この順番には意味があります。SKILL.md で基本的な運用手順を把握し、validate.js で schema 駆動の検証モデルを確認し、fetch.js でリモート参照のキャッシュ動作を理解できます。

このスキルに渡すべき入力

有用な結果を得るには、少なくとも次の情報を渡してください。

• workflow の目的: build、test、submit、update、または連結した release flow
• trigger ルール: branch、PR、schedule、manual、または別 workflow 完了後
• 対象プラットフォーム: iOS、Android、または両方
• 環境要件: secrets、profiles、env vars、channels
• 期待する出力: artifacts、updates、store submission、notifications
• 出力先ファイル: 通常は .eas/workflows/<name>.yml

ここが曖昧だと、エージェントが出せるのは汎用的な下書き止まりです。

あいまいな依頼を、強いプロンプトに変える

弱い依頼:

• “Make me an Expo deployment workflow.”

より良い依頼:

• “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.”

後者のようなプロンプトなら、trigger、job の順序、検証手順まで判断できるだけの材料がそろいます。

必ず最新の Expo リファレンスを取得する

このスキルは記憶ではなく、現行ドキュメントを前提に使う設計です。YAML を新規作成・修正する前に、SKILL.md にある現在のリファレンス、とくに以下は必ず取得してください。

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

特に expo-cicd-workflows をデプロイ用途で使う場合、ここが最重要ポイントです。schema のズレは、無効な出力につながる最短ルートだからです。

生成した YAML は必ず検証してから信用する

もっとも堅実な使い方は次の流れです。

1. まずエージェントに workflow を下書きさせる
2. .eas/workflows/ 配下に保存する
3. validator script を実行する
4. schema エラーを修正する
5. その後で project 固有の値を詰める

検証フローの例:

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

skill ディレクトリの文脈から実行すれば、validator は live schema を取得し、YAML エラーや schema エラーをフィールドパス付きで報告してくれます。

検証スクリプトが実際に確認している内容

validate.js は YAML をパースし、live の EAS schema を読み込んだうえで、厳格な AJV 検証を行います。これにより、次のような問題を検出できます。

• YAML の構文不正
• 必須フィールドの不足
• サポートされていない enum 値
• 型の誤り
• トップレベルまたはネスト構造の不正

そのため、expo-cicd-workflows の利用フローは、古いブログ記事の例をコピペするよりずっと安全です。

実プロジェクトでおすすめの進め方

実務では、次の進め方が現実的です。

1. 既存の eas.json と現在のリリース手順を確認する
2. 希望する trigger と出力をエージェントに伝える
3. 仮の workflow ファイルと、前提条件の説明を一緒に出させる
4. YAML を検証する
5. secrets、profile 名、channel、branch filter を調整する
6. いきなり本番パイプラインにせず、まずは小さな範囲で workflow を実行する

このやり方なら、「構文的には正しいが、運用上やってほしいことと違う YAML ができる」という、導入時にありがちな問題を減らせます。

既存 workflow を編集するときの最適なプロンプト

既存ファイルを修正する場合は、変更したい YAML 全体と変更要求を一緒に渡してください。例:

• “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.”

この形式なら、ファイル全体を作り直すのではなく、意図を保ちながら修正しやすくなります。

スキルに共有すると精度が上がるリポジトリ情報

次の情報を渡すと、エージェントの精度はかなり上がります。

• eas.json
• 既存の .eas/workflows/*.yml
• ブランチ命名ルール
• EAS Update を使っているか
• store submission を CI/CD に含めるか
• profile や environment の命名規則

expo-cicd-workflows は構文には強い一方、リリースの形はリポジトリ固有です。だからこそ、これらの入力がガイド品質に直結します。

expo-cicd-workflows スキル FAQ

expo-cicd-workflows は新規 workflow ファイル専用ですか？

いいえ。expo-cicd-workflows は、既存の EAS workflow YAML のレビュー、デバッグ、モダナイズにも有効です。特に、古いドキュメントを前提に書かれたファイルや、不完全なサンプルを流用したファイルの見直しに向いています。

汎用的な CI/CD YAML を頼むより良いですか？

対象が EAS Workflows なら、はい。汎用 CI/CD のプロンプトでは、.eas/workflows/ 構文に素直に対応しない GitHub Actions 的な発想へ流れがちです。このスキルは Expo 固有の workflow 構造と検証に合わせて調整されています。

EAS Workflows をすでに理解していないと使えませんか？

初心者でも使えますが、より良い結果が出るのは、最低限のリリース要件に答えられる場合です。たとえば「何を trigger にするのか」「どんな environment があるのか」「最後の deploy step で何をしたいのか」といった点です。このスキルは、プロダクト戦略そのものよりも、構文と構造の支援に強みがあります。

expo-cicd-workflows を使わないほうがいいのはどんなときですか？

次のケースでは向いていません。

• Expo EAS Workflows を使っていない
• Expo ツール外まで含む、横断的な CI 設計が必要
• 主な課題が workflow YAML ではなく、app signing、credentials、store policy にある
• リポジトリ固有の判断なしにワンクリックで配備したい

このスキルは project dependencies もインストールしますか？

いいえ。expo-cicd-workflows の install で入るのはスキル本体です。一方、検証には scripts/package.json にある Node スクリプト用依存関係が必要です。validator をローカルで動かすなら、script ディレクトリでそれらをインストールしてください。

expo-cicd-workflows は、動くデプロイパイプラインまで保証してくれますか？

いいえ。workflow ファイルの正確性向上や schema エラーの削減には役立ちますが、実際に動くデプロイが成立するかどうかは、credentials、profiles、secrets、app config、そして Expo プロジェクトの構成に依存します。

expo-cicd-workflows スキルを改善する方法

ファイル名だけでなく、デプロイの意図を伝える

expo-cicd-workflows の出力を最も手早く改善する方法は、リリースの意図を明確に伝えることです。

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

意図がはっきりしていれば、エージェントは trigger や job の並びをより適切に選べます。

周辺の Expo 設定も一緒に渡す

eas.json、既存の workflow ファイル、environment の命名規則は一緒に渡してください。弱い出力の多くは、プロジェクトに存在しない profile 名や channel、前提条件をエージェントが勝手に補ってしまうことから起こります。

前提条件を明示させる

強いプロンプトの末尾には、次のような指示を入れると効果的です。

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

こうしておくと、最初のドラフトがレビューしやすくなり、見えにくい破綻も減らせます。

validate-fix ループで使う

最良の結果を得るには、expo-cicd-workflows の使い方を反復前提で考えてください。

1. YAML を生成する
2. 検証する
3. 正確なエラー内容をそのまま返す
4. 修正版を作らせる

validator は具体的な schema path を返してくれるので、1 回目より 2 回目のほうが大きく精度が上がることが多いです。

よくある失敗パターンに注意する

典型的な問題は次のとおりです。

• GitHub Actions の構文を EAS workflows に混ぜてしまう
• 古い field 名や enum を使う
• trigger の詳細が足りない
• job 間の依存関係が不明確
• リポジトリに存在しない profile、channel、secret を前提にしてしまう

こうした問題の多くは、最新ドキュメントの取得を必須にし、実際の設定ファイルを共有することで防げます。

まずは最小構成の workflow から始める

複雑さが導入の障害になっているなら、まずはパイプラインの形を確認できる最小限の有効 workflow を作り、そこから広げていくのが得策です。例:

• まず手動の Android build を作る
• 次に branch trigger を追加する
• その後 iOS を追加する
• 最後に submission や update step を足す

デバッグコストを抑えやすく、expo-cicd-workflows をデプロイ用途に定着させるうえでも有効です。

制約を多く含むプロンプトで精度を上げる

上級者向けの良いプロンプトには、次の要素を含めます。

• 対象ファイルパス
• trigger 条件
• 対象プラットフォーム
• 必要な job とその順序
• profiles または channels
• 変更してはいけない点
• live schema で検証する指示

この組み合わせのほうが、「フル CI/CD workflow を作って」と一文で頼むより、はるかに安定した結果になります。

補助スクリプトを信頼の軸にする

expo-cicd-workflows の隠れた強みは、文章の指示だけではありません。補助ツールがあることです。

• fetch.js はキャッシュと ETags により、古いドキュメントを参照するリスクを下げる
• validate.js は live schema に基づく正しさを強制する

結果をもっと良くしたいなら、これらを「使ってもよい補助機能」ではなく、実際の workflow の一部として使うようエージェントに指示してください。