generate-cicd

vfarcic/dot-ai の shared-prompts/generate-cicd.md から取り込まれたものです（MIT、Copyright (c) 2025 Viktor Farcic）。原作者：Viktor Farcic。

CI/CD ワークフローの生成

対話形式の会話を通じて、現在のプロジェクトに適した CI/CD ワークフローを生成します。このプロンプトでは、リポジトリ全体を分析し、調査結果を提示したうえで、ワークフローの設定について質問し、確認された選択に基づいてワークフローを生成します。

手順

プロジェクトの CI/CD ワークフロー設定を支援します。テンプレートベースのジェネレーターとは異なり、次のことを行います。

1. リポジトリ全体（ソースコード、自動化、設定ファイル、ドキュメント、既存の CI）を分析する
2. 意思決定のため、調査結果とワークフローの選択肢をユーザーに提示する
3. ユーザーが確認した選択に基づいてワークフローを生成する

この対話形式のモデルが不可欠なのは、CI/CD ワークフローには、コードだけからは推測できないポリシー上の判断（PR と直接のプッシュのどちらを使うか、リリースのトリガー、デプロイ戦略など）が含まれるためです。これらはチームの希望や組織のポリシーを反映します。

主なルール

すべてを確認する：手順、シークレット、設定を追加する前に、実際のコードベースを調べて確認してください。決して推測してはいけません。不確かな場合は質問してください。

必ずワークフローの選択肢を提示する：CI/CD には、ユーザーの入力が必要なポリシー上の判断が伴います。テストと Dockerfile が見つかったとしても、テストを PR で実行するか main で実行するか、リリースのトリガーは何か、どのレジストリを使うか、どのようにデプロイするかは判断できません。これらのワークフローの選択について、ユーザーに確認する必要があります。

---

ベストプラクティス

ワークフローを生成する際は、以下のプラクティスを適用してください。

インラインコマンドではなく、プロジェクトの自動化を使用する

CI ワークフローからは、コマンドのロジックをインラインで記述するのではなく、プロジェクトの自動化を呼び出してください。

# ❌ BAD - Logic in CI, can't run locally the same way
- run: |
    jest --coverage --ci
    eslint src/ --format=stylish

# ✅ GOOD - CI calls project automation
- run: npm test
- run: npm run lint

理由：ローカルと CI の一貫性、CI プラットフォーム間の移植性、デバッグの容易さ、信頼できる唯一の情報源の確保につながります。

プロジェクトの自動化が存在しない場合は、ユーザーに質問してください。

I didn't find automation for [operation]. Would you like me to:
1. Add it to the project (recommended for local/CI parity)
2. Use inline command in workflow

インフラにはアクション、ロジックにはプロジェクトのコマンドを使用する

カテゴリ	例	方法
CI インフラ	checkout、ランタイムのセットアップ、キャッシュ、レジストリへのログイン	✅ アクションを使用する
プロジェクトのロジック	ビルド、テスト、lint、docker build、デプロイ	✅ プロジェクトの自動化を使用する

シークレットの取り扱い

シークレットにアクセスできるのは、シークレットを設定した組織または所有者のみです。フォークからの PR では、ベースリポジトリのシークレットにアクセスできません。

シークレットを利用できない場合は、条件付きで手順をスキップしてください。

- name: Run integration tests
  if: secrets.API_KEY != ''
  run: npm run test:integration
  env:
    API_KEY: ${{ secrets.API_KEY }}

生成したワークフローでシークレットが必要な場合は、必要なシークレットを明確に記載してください。

## Required Secrets

| Secret Name | Description | How to Create |
|-------------|-------------|---------------|
| `REGISTRY_USERNAME` | Container registry username | Your registry account username |
| `REGISTRY_TOKEN` | Container registry access token | Registry settings > Access Tokens |

**To create secrets via CLI:**
gh secret set REGISTRY_USERNAME
gh secret set REGISTRY_TOKEN

ガイダンスとして gh secret set コマンドを示してください。ただし、実行してはいけません。

セキュリティ

プラクティス	説明
最小限の権限	permissions: ブロックを使用し、必要な権限のみを付与する
長期間有効なトークンより OIDC を優先	クラウドプロバイダーでは、OIDC フェデレーションを優先する
アクションのバージョンを固定	SHA またはバージョンタグを使用し、@latest は決して使用しない
認証情報の永続化を無効化	actions/checkout で persist-credentials: false を使用する
スクリプトインジェクションを防止	信頼できない入力（ブランチ名、PR タイトル）を run: コマンドに直接埋め込まない
pull_request_target を避ける	このトリガーはシークレットにアクセスできる一方、フォークのコードをチェックアウトできます。危険な組み合わせです
環境保護	本番環境へのデプロイには、必須レビュー担当者を設定した GitHub 環境を使用する

テスト

プラクティス	説明
素早く失敗させる	時間のかかるテストの前に、lint などの高速なチェックを実行する
ビルド前にテストする	テストに失敗した場合、ビルドに時間を費やさない
ジョブを並列化する	相互に独立したチェックを同時に実行する
テストマトリックス	必要に応じて、複数のバージョンやプラットフォームを検討する

キャッシュ

検出されたパッケージマネージャーとロックファイルに基づいて、適切なキャッシュを実装してください。

---

プロセス

重要：このプロセスは順番に実行してください。各ステップによって会話の方向性が変わる場合があります。質問をまとめて一度に尋ねないでください。各フェーズを一つずつ進め、次に進む前にユーザーの回答を待ってください。

ワークフローは次の3つのフェーズで構成されます。

┌─────────────────────────────────────────────────────────────────┐
│ PHASE 1: ANALYZE                                                │
│ Discover what CAN be built/tested/deployed                      │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ PHASE 2: PRESENT & ASK                                          │
│ Show findings + present workflow choices for user decision      │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ PHASE 3: GENERATE                                               │
│ Create workflows based on confirmed user choices                │
└─────────────────────────────────────────────────────────────────┘

ステップ 0：CI プラットフォームの確認（必須ゲート）

最重要：これは必須ゲートです。まず、CI プラットフォームについてのみ尋ねてください。ユーザーが GitHub Actions を使うと確認するまで、ほかの質問や分析を行わないでください。

ユーザーに使用している CI/CD プラットフォームを尋ねてください。次の選択肢のみを提示してください。

1. GitHub Actions
2. その他

GitHub Actions の場合 → ステップ 1（分析）に進みます。

その他の場合 → 停止します。使用しているプラットフォームを尋ねてから、次のように応答してください。

[Platform] is not yet supported. Would you like me to open a feature
request issue at https://github.com/vtmocanu/skills/issues so we
can prioritize adding it?

1. Yes, open a feature request
2. No, I'll use a different approach

その後、ユーザーの回答に対応してください（イシューを作成するか、会話を終了します）。サポート対象外のプラットフォームについて、リポジトリの分析に進まないでください。

ステップ 1：リポジトリの包括的な分析

すべてを分析してください。リポジトリ全体がコンテキストです。

1.1 言語とフレームワークの検出

• ソースファイルと依存関係マニフェストから主要な言語を特定します
• 依存関係からフレームワークを検出します
• バージョン要件を確認します

1.2 既存の自動化の特定と理解

既存の自動化を見つけ、その動作を理解するためにスクリプトを読んでください。受け付ける引数、内部で処理する内容、呼び出し方法を確認します。スクリプトが存在することを記録するだけでなく、動作を理解してください。

• タスク用の自動化が存在する場合 → 生成するワークフローでそれを使用します
• 既存の自動化がない場合に限り、コマンドを直接生成します
• 自動化の選択肢が複数ある場合 → ユーザーに尋ねます

重要な理由：既存の自動化には、セットアップ、フィクスチャ、環境変数、クリーンアップなど、コマンドを直接実行するだけでは対応できない処理が含まれていることがよくあります。メンテナーがそのビルドシステムを選んだのには理由があります。

1.3 既存 CI の分析

既存の CI 設定を確認します。見つかった場合：

• すでに設定されている内容とその理由を分析します
• ステップ 2 で、既存のワークフローを更新するか、新規作成するかをユーザーに尋ねます

1.4 コンテナーとレジストリの検出

• Dockerfile とコンテナー設定を確認します
• 既存の CI、自動化、ドキュメントからレジストリへの参照を検索します
• Dockerfile がなく、プロジェクトにコンテナー化が有益な場合は、/generate-dockerfile プロンプトの使用を提案します

1.5 ブランチ戦略とリリース戦略

• 既存の CI トリガーにパターンがあるか確認します
• バージョン管理のパターンを把握するため、Git タグを確認します
• ワークフローに関する手掛かりをドキュメントから確認します

1.6 環境とシークレット

• 環境変数のドキュメントや例を探します
• 必要な環境変数をコードから検索します
• ワークフローで必要となるシークレットを特定します

1.7 アプリ定義の検出

アプリケーションがデプロイ用にどのようにパッケージ化されているかを特定します。

• Helm チャート
• Kustomize 設定
• プレーンな Kubernetes マニフェスト
• コンテナーのみ（K8s デプロイなし）

1.8 デプロイ方式の検出

アプリケーションのデプロイ方法を特定します。

• GitOps（ArgoCD、Flux）
• 直接デプロイ（Helm、kubectl）
• 手動デプロイ
• 外部システム

GitOps の場合：

• CI から直接デプロイしてはいけません。CI はマニフェストを更新し、GitOps コントローラーが同期します
• GitOps リソース（ArgoCD Application、Flux Kustomization）が存在するか確認します
• 存在しない場合は、作成が必要になることがあります（同じリポジトリ、または別の cluster-config リポジトリ）
• イメージタグ更新用のマニフェストがどこにあるかを特定します

不明な点があれば、ステップ 2 でユーザーに尋ねてください。

1.9 ツールマネージャーの検出

既存のツール／環境マネージャー（DevBox、mise、asdf など）を確認します。見つかった場合は自動的に使用します。見つからない場合は、対話形式の Q&A でユーザーに尋ねます。

ステップ 2：確認のための分析結果の提示

ワークフローを生成する前に、分析の概要を提示してください。 このプロジェクトに関係する内容のみを含めてください。以下の例は説明用であり、記入用のテンプレートではありません。

## Analysis Summary

I analyzed your repository and found:

**Language/Framework**: Node.js 20 with Express
**Build Command**: `npm run build` (from package.json)
**Test Command**: `npm test` (from package.json)
**Existing CI**: GitHub Actions workflow found (ci.yml)

**App Definition**: Helm chart in `charts/myapp/`
**Deployment Mechanism**: GitOps with ArgoCD

Is this correct? Would you like to change anything?

ユーザーができること：

• 分析結果を確認する → ワークフローの選択に進みます
• 誤りを訂正する
• 不明点を明確にする

ステップ 3：ワークフローの選択肢を提示する

分析に基づき、このプロジェクトに関連する選択肢を提示します。 これらはユーザーの入力が必要なポリシー上の決定事項です。該当する内容のみを質問してください。たとえば、Dockerfile がない場合はコンテナーレジストリについて質問せず、ライブラリの場合はデプロイ戦略について質問しないでください。

一般的な選択肢は次のとおりです。

• PR ワークフロー：プルリクエストで何を実行しますか？
• リリースのトリガー：何をきっかけにリリースビルドを実行しますか？
• リリースの検証：リリースワークフローで、PR ですでに成功したチェックを再実行しますか？（すべて再実行＝最も安全／最も遅い、検証をスキップ＝最速、セキュリティスキャンのみ＝折衷案）
• コンテナーレジストリ：イメージをどこにプッシュしますか？（コンテナー化されている場合）
• 環境のセットアップ：ネイティブの GitHub Actions と DevBox のどちらを使用しますか？
• デプロイ戦略：GitOps、直接デプロイ、手動のどれにしますか？（デプロイする場合）

必要に応じて、明確化のための質問をしてください。

• ブランチ戦略が不明な場合：「プルリクエストを使うフィーチャーブランチを使用していますか、それとも main に直接プッシュしていますか？」
• 自動化の選択肢が複数ある場合：「テストの実行方法が複数見つかりました。主なテストコマンドはどれですか？」
• GitOps が検出されたもののリポジトリの場所が不明な場合：「GitOps マニフェストはどこに保存されていますか？同じリポジトリですか、それとも別のリポジトリですか？」

ステップ 4：ワークフローを生成する

分析と確認済みのユーザーの選択に基づいて、適切なワークフローを生成します。

ステップ 5：生成したワークフローを検証する

ユーザーに提示する前に、次の項目を確認します。

1. 構文の検証：有効な YAML および GitHub Actions の構文であることを確認します
2. 参照の確認：参照されている自動化が存在することを確認します
3. シークレットの説明：必要なシークレットを明確に一覧表示します
4. 権限の確認：permissions ブロックが最小限であることを確認します
5. デプロイの確認：デプロイ手順が選択された方式に一致することを確認します

ステップ 6：ユーザーに提示する

次の内容を提示します。

1. 生成したワークフローファイル（説明コメント付き）
2. 検出した内容と決定事項の概要
3. 設定が必要な必須のシークレット（設定方法のガイダンス付き）
4. 必要な権限と設定：ワークフローの内容に基づいて、必要な権限やリポジトリ設定を特定し、設定手順を提示します。ワークフローが失敗するまで待つのではなく、事前に必要な設定をユーザーに伝えてください。

ステップ 7：検証する

ユーザーの承認後、プロジェクトで確立された手順に従ってワークフローをコミットします。ワークフローを実行し、実行状況を監視して、成功するまで失敗への対応と改善を繰り返します。