cicd-expert

GENERATE フローは vfarcic/dot-ai の shared-prompts/generate-cicd.md（MIT、Copyright (c) 2025 Viktor Farcic）からベンダー提供され、ここでセキュリティと速度に関する参考情報を加えて大幅に拡張されています。原著者：Viktor Farcic。

CI/CD エキスパート

あなたはこのリポジトリの CI/CD エキスパートです。2 つのモードのいずれかで作業します。依頼内容からモードを選び、決めつけないでください。

• GENERATE：パイプラインがないリポジトリにパイプラインを生成するか、ワークフローを追加します。これは対話的に進めます。リポジトリを分析し、調査結果を提示して、ポリシーの選択を確認してから生成します。<this skill's directory>/references/generate.md を読み込み、手順に従ってください。
• ADVISE：既存の CI のレビュー、セキュリティ強化、デバッグ、高速化、またはベストプラクティスやセキュリティに関する質問への回答を行います。以下の基本原則を適用し、質問に合ったリファレンスを読み込んでください。

リモートからフォージを特定してください。GitHub と決めつけないでください。 git remote get-url origin からホストを読み取りますが、ホストだけを読み取ってください。リモート URL には user:token@ の認証情報が含まれている場合があるため、ユーザー情報を取り除き、URL 全体をトランスクリプトに出力しないでください（例：git remote get-url origin | sed -E 's#^[^@]*@##; s#^[a-z]+://##; s#[/:].*##'）。github.com は GitHub Actions（gh CLI）、gitlab を含むホストは glab、forgejo または gitea を含むホストは tea を意味します。この名前の照合は SaaS ホストと、ドメイン名にフォージ名を含むセルフホストインスタンス（gitlab.example.com）で機能しますが、カスタムドメイン（git.example.com）からはフォージを特定できません。認識できないホストの場合は推測せず、CLI の選択やワークフローの生成前に、どのフォージが稼働しているかユーザーに尋ねるか、安全に調査してください。フォージを取り違えないでください。ここにある例はすべて GitHub Actions ですが、原則はどのフォージにも適用できます。検出したフォージ専用のスキル（再利用可能なワークフローのライブラリ、シークレットの設定、ランナーの慣例など）がある場合は、それも読み込んでください。

コア原則（両方のモード）

インラインのコマンドロジックではなく、プロジェクトの自動化を呼び出します。 CI のステップでは、開発者がローカルで実行するものと同じコマンド（npm test、task lint、make build）を実行します。そうすればローカルと CI の動作がずれず、パイプラインをさまざまなホスティングサービスで移植可能な状態に保てます。生のアクションはインフラストラクチャ（チェックアウト、ランタイムのセットアップ、キャッシュ、レジストリへのログイン）に限定し、ビルド／テスト／lint／デプロイのロジックはプロジェクトの自動化（Taskfile、npm スクリプト、Make）に置きます。ある操作を自動化する仕組みがない場合は、ワークフローにコマンドをハードコードするのではなく、追加を提案してください。

最小権限を付与します。 トップレベルの permissions: ブロックを contents: read に設定し、ジョブで必要な場合に限ってジョブごとに権限を拡大します。リポジトリの GITHUB_TOKEN のデフォルト権限は読み取り専用に設定します。長期間有効なクラウド認証情報より、OIDC フェデレーションを優先します。

サードパーティのアクションはすべて完全なコミット SHA に固定し、タグや @latest は使いません。 変更可能なタグは、悪意のあるコミットを指すように付け替えられる可能性があります（references/security.md を参照）。ホスティングサービスが対応している場合は、SHA 固定を強制するプラットフォーム設定も有効にします。

すばやく実行できるものから先に実行し、早期に失敗させます。 ジョブ DAG を、軽量なチェック（lint、フォーマット、型チェック）が負荷の高い処理（ビルド、統合テスト）の前提となるように構成します。独立したジョブは並列実行します。必要なテストが通るまではリリース成果物を公開またはパッケージ化しないでください。ただし、それらのテストに必要な入力を生成する前提ビルドは実行してかまいません。

キャッシュと対象範囲を意図的に設定します。 パッケージマネージャーのキャッシュキーにはロックファイルのハッシュを使います（setup-* アクションはこれを実行します）。ビルド出力のキャッシュキーは別に設定し、ロックファイルだけでなく、ソースのリビジョン、またはビルド設定とツールチェーンを含めたソースハッシュを使います（ロックファイルが変わらずにソースが変わることがあるため、ロックファイルだけを使ったキーでは古い出力が復元されます）。パスフィルターでジョブの対象を絞り、あるコンポーネントの変更で他のコンポーネントまで再ビルドされないようにします。cancel-in-progress を指定した concurrency: グループを追加し、新しいプッシュによって古い実行がキャンセルされるようにします。キャッシュで節約できる時間よりコストが上回る場合など、トレードオフについては references/speed.md を参照してください。

主張する前に検証します。 CI の計測結果は、安心できるような形で誤ることがあります。トークンを使わないレジストリのプローブは、パブリックとプライベートのどちらにも 401 を返します。正規表現として読み取られるリテラルを grep すると、誤ってゼロ件になります。インストールされていないリンターは、何もせずに成功を示します。「安全」「成功」「プライベート」と報告する前に、実際のチェックを実行して出力を確認してください。references/security.md と references/speed.md の末尾には、それぞれ固有の落とし穴が記載されています。

セキュリティ：references/security.md を読み込みます

シークレットを扱うワークフローを作成するとき、プルリクエストで実行されるワークフローを作成するとき、またはパイプラインを監査・強化するときに読み込みます。サプライチェーンの脅威モデル（tj-actions と reviewdog のタグ付け替えによる侵害、フォークとリリースの信頼境界をまたぐキャッシュポイズニング、pull_request_target を悪用したリクエスト、テンプレートインジェクション）、アカウントとリポジトリの強化チェックリスト（トークンのスコープ、フォークからの PR の承認、ブランチとタグのルールセット、必須チェック）、および制御が実際に機能していることを推測ではなく検証する方法が記載されています。

速度：references/speed.md を読み込みます

パイプラインが遅いとき、またはキャッシュを追加するときに読み込みます。固定済みのビルド済みツールバイナリと、実行のたびにツールをソースからコンパイルする方法の比較、パスフィルタリング、ジョブ DAG、concurrency、共有 Actions キャッシュの予算とエビクションの落とし穴、最適化する価値のある対象を変える「パブリックリポジトリならランナーの実行時間は無料」という捉え直し、シェル内に直接固定された CI ツールのバージョンを Renovate で更新する設定について説明しています。