CI

リポジトリの標準的なブートストラップ、テスト、ビルド、E2E コマンドを使用して、リポジトリの継続的インテグレーション（CI）ワークフローをスキャフォールドまたは修復します。

目的

このスキルを使用して、現在のリポジトリに対して最小限で信頼性の高い CI ワークフローを作成または改善します。

目標は新しいビルドシステムを発明することではなく、リポジトリの既存のローカルコントラクトを CI に公開して、すべての変更をクリーンなリモート環境でチェックできるようにすることです。

複雑な CI よりも小さく、明確な CI を優先します。

運用原則

CI をリポジトリの標準的なコマンドのコンシューマーとして扱います。

init、env、test、e2e で既に定義されているコマンドを優先します。リポジトリが既にブートストラップスクリプトまたはパッケージスクリプトを持っている場合は、複雑なセットアップロジックを CI ワークフロー内で重複させないでください。

ワークフローを理解しやすく保ちます。将来のエンジニアが CI ファイルを開いて、その場で何を検証しているのかがすぐに分かるべきです。

リポジトリがすでに明確にしていない限り、プラットフォーム固有の想定を追加しないでください。

編集前

リポジトリを最初に検査します。

以下をチェックします：

• 既存の CI ワークフロー
• パッケージマネージャーのロックファイル
• 言語とフレームワークの指標
• 既存のブートストラップ、テスト、リント、タイプチェック、ビルド、E2E スクリプト
• Playwright またはブラウザテストの構成
• 必須の環境変数
• データベース、キュー、エミュレーターなどのサービス依存関係

既存の CI が存在する場合は、不必要に置き換えるのではなく、修復または簡略化します。

リポジトリに明確な標準的なコマンドがない場合は、停止して不足しているものを報告します。リポジトリが決定論的なセットアップスクリプトが必要な場合は、最初に init を実行することをお勧めします。

ワークフロー

最初に、リポジトリの標準的なコマンドを特定します。

以下の順序でコマンドソースを検索します：

1. scripts/bootstrap、scripts/test、scripts/e2e などのリポジトリブートストラップスクリプト
2. npm test、npm run build、npm run e2e などのパッケージスクリプト
3. リポジトリがそのフレームワークを明確に使用している場合のみ、フレームワークのデフォルト

その後、CI ワークフローを作成または更新します。

GitHub Actions の場合、以下を優先します：

.github/workflows/ci.yml

デフォルトワークフローは通常、プルリクエストとメインブランチへのプッシュで実行されるべきです。

リポジトリが実際に実行できるチェックのみを含めます。

適切なベースラインは以下の通りです：

• チェックアウト
• ランタイムのセットアップ
• 依存関係のインストール
• 利用可能な場合はリントを実行
• 利用可能な場合はタイプチェックを実行
• テストを実行
• 利用可能な場合はビルドを実行
• 既に構成されており、実用的な場合は E2E を実行

明白で低リスクである場合は、依存関係キャッシングを使用します。

明示的に要求されない限り、デプロイ、パブリッシング、リリース自動化、シークレット集約的なジョブ、または環境プロモーションを追加しないでください。

検証

編集後、可能な限りローカルで検証します。

最低限：

• ワークフロー YAML が有効な構文であることを確認
• CI で参照されるすべてのコマンドが存在することを確認
• 実用的な場合は関連するローカルコマンドを実行
• 実行できなかったコマンドを報告
• CI が必要とするシークレットまたは環境変数を報告

検証が失敗した場合は、ワークフローを修正するか、残りのブロッカーを明確に説明します。

ハンドオフ

ハンドオフ時に以下を報告します：

• 作成または変更されたワークフローファイル
• 構成されたトリガー
• 含まれるジョブとチェック
• 使用されたコマンド
• なされた想定
• 実行された検証
• 必要なフォローアップ

サマリーは簡潔に保ちます。CI がリポジトリを保護する準備が整っているかどうかに焦点を当てます。