ci-cd

CI/CD パイプライン：マルチプラットフォームの本番インフラストラクチャ

GitHub Actions、GitLab CI/CD、Forgejo Actions、Gitea Actions、Woodpecker をまたぐ CI/CD パイプラインを作成、レビュー、設計します。目標は、エンジニアリング上のニーズとコンプライアンス要件（PCI-DSS 4.0）の両方を満たす、安全で高速かつ監査可能なパイプラインです。

対象バージョン：2026年10月時点のスナップショットです。Forge、ランナー、CI、またはサプライチェーンツールのバージョンを固定する前に、references/target-versions.md をお読みください。

このスキルでは、ワークフロー設計、セキュリティ、コンプライアンス、プラットフォーム間の移行、ランナー、依存関係の更新、スキャン、レビューゲート、ロールアウトの順序を扱います。

使用する場面

• CI/CD パイプライン設定（GitHub/Forgejo/Gitea Actions、.gitlab-ci.yml、.woodpecker/*.yaml）の作成またはレビュー
• パイプラインアーキテクチャ（ステージ、並列処理、キャッシュ、デプロイ戦略）の設計
• サプライチェーン攻撃に対するパイプラインの強化（SHA による固定、イメージ署名、来歴）
• CI でのセキュリティスキャン（SAST、SCA、コンテナスキャン、シークレット検出）の設定
• ランナーの設定（インストール、登録、エグゼキューターの選択、強化）— references/runners.md を参照
• キャッシュ戦略またはアーティファクト管理の設定
• CI/CD の PCI-DSS 4.0 準拠（要件 6.2.1、6.2.4、6.3.2、6.4.2、6.5.3）
• プラットフォーム間でのパイプライン移行（GitLab -> GitHub、GitHub -> Forgejo）
• 失敗するパイプライン、不安定なジョブ、またはランナーの問題のトラブルシューティング

使用しない場面

• Kubernetes マニフェスト、Helm チャート、クラスターアーキテクチャ — kubernetes を使用
• Dockerfile、Compose スタック、コンテナイメージの最適化 — docker を使用
• Terraform/OpenTofu によるインフラストラクチャ・アズ・コード — terraform を使用
• Ansible プレイブック、構成管理 — ansible を使用
• アプリケーションコードのセキュリティ監査（SAST の検出結果、認証のバグ）— security-audit を使用
• パイプラインに関連しているだけのアプリケーションコードの正確性レビュー — code-review を使用します。 パイプライン設定のレビュー、デバッグ、アーキテクチャ、CI 固有の強化は、このスキルの対象です。
• データベースの移行またはスキーマ作業 — databases を使用

AI セルフチェック

AI ツールは、同じ CI/CD の間違いを繰り返し発生させます。生成したパイプライン設定を返す前に、必ずこのリストに照らして確認してください。

レビューモード： パイプラインを生成するのではなく、既存のパイプラインを監査する場合は、このチェックリストを逆に適用します。該当しない項目はすべて指摘事項です。リストを上から順に確認し、該当する問題をすべてファイル名と行番号を添えて報告してください。

• SHA による固定：すべてのサードパーティ製アクション／イメージを、変更可能なタグではなく完全なコミット SHA またはダイジェストで固定します。読みやすさのために # vX.Y.Z コメントを追加します。tj-actions、reviewdog、Trivy の侵害では、いずれも変更可能なタグが移動されました。
• 権限：すべての GitHub Actions ワークフローに明示的な permissions: ブロックを設定します（デフォルトは読み取り専用）。GitLab では、保護された変数が正しくスコープ設定されていることを確認します。
• 設定ファイルにシークレットを含めない：トークン、パスワード、API キーをハードコードしません。CI/CD のシークレット変数または Vault 連携を使用します。
• latest タグを使わない：ランナーイメージ、ツールイメージ、ベースイメージを特定のバージョンまたは SHA256 ダイジェストで固定します。
• キャッシュ戦略：依存関係は適切にキャッシュし（ロックファイルベースのキーを使用）、ビルド出力にはキャッシュではなくアーティファクトを使用します。
• セキュリティチェックを早期に実施：SAST、依存関係スキャン、シークレット検出を早い段階で実行します（デプロイ後ではなく）。
• 本番環境への認可：必須の環境承認とリポジトリのデプロイポリシーを遵守します。リリースに対してすでに付与された明示的な認可は維持しますが、必須の環境保護が免除されるわけではありません。
• SBOM の生成：リリースパイプラインで SBOM（SPDX または CycloneDX）を生成し、添付します。有用なインベントリの証拠になりますが、この形式を該当する管理策／ポリシーで要求される場合にのみ必須です。
• スコープを最小限にする：ジョブに必要最小限の権限を付与し、必要なシークレットのみへのアクセスを許可し、必要なステップのみを実行します。
• 正当な理由なしに allow_failure を使わない：ジョブの失敗を許容する場合は、その理由をコメントに記載します。
• ツールのバージョンを固定：可変のエイリアスではなく特定のバージョンを指定します。node:lts ではなく node:22、python:3 ではなく python:3.13 を使用します。特定のバージョンを指定すると予期しない破損を防げますが、上記の SHA による固定も引き続き必要です。
• トリガーのスコープ設定：ブランチ／パスのフィルターを指定しない on: push は、すべてのブランチへのすべてのプッシュで実行されます。branches: [main] および／または paths: フィルターで対象を絞ります。GitLab も同様に、単独の only: [pushes] ではなく、if 条件を含む rules: を使用します。
• 式のインジェクションを防止（GitHub Actions）：${{ }} 式を run: ブロック内で直接使用しません。まず env: に割り当てます。github.event.* は攻撃者が制御できます。セキュリティ上重要なコンテキストでは、細工されたタグ名／ブランチ名によってインジェクション可能な github.ref_name の使用を避けます。
• 公開／信頼できないリポジトリでは、セルフホストランナーを一時的にする：外部 PR を受け付けるリポジトリで非一時的なシェルランナーを使うことは、セルフホストランナーが侵害される主な原因です。--ephemeral（GitHub、Gitea）を使用していることを確認します。Forgejo では、検証済みの単一ジョブ終了ライフサイクルと、ジョブごとに新しいホスト／コンテナー状態を用意します。容量制限やデーモンの再起動だけでは、一時的とはいえません。外部コントリビューターには承認ゲートを設けます。references/runners.md を参照してください。
• Docker ソケットのマウント範囲：ジョブに /var/run/docker.sock をマウントすると、そのジョブにホスト上の root 権限が与えられます。信頼できる内部パイプラインでのみ許容されます。公開／共有ランナーでは、代わりに DinD サイドカーまたは rootless buildkit を使用します。
• スキャンゲートには一律ブロックではなくベースラインを設ける：exit-code 1 と抑制ゼロを設定して導入したコンテナー／IaC／SAST スキャナーは、必ず無効化されます。references/best-practices.md にあるラチェット方式（非ブロッキング → ベースライン → 新規項目のみブロック）を使用します。
• 無視リストの項目に有効期限を設定：各 .trivyignore、.grype.yaml、Dependabot の ignore、または Renovate の ignoreDeps 項目に、再確認日と担当者を記載したコメントを付けます。日付がない項目は、放置された技術的負債になります。
• ロックファイルをコミット：アプリケーションでは package-lock.json、bun.lock、Cargo.lock、go.sum、uv.lock をバージョン管理に含めます。マニフェストのみのコミットでは再現性が損なわれます。
• 自動マージは lint だけでなくテストを条件にする：変更箇所のテストカバレッジがないまま Dependabot／Renovate の自動マージを許可するのは、サプライチェーン上の近道です。
• ランナーの信頼性を確認：ワークフローの説明では、ホスト型、セルフホスト型、フォーク、保護ブランチでの実行を区別します。
• 変更可能な参照を管理：サプライチェーンのリスクが重要な箇所では、アクション、イメージ、インクルード、テンプレートを固定します。
• 横断的なエージェントの衛生対策を適用します。references/agent-hygiene.md を参照してください。

パフォーマンス

• ロックファイルとツールチェーンのバージョンをキーにキャッシュし、古い依存関係を復元する広範なキャッシュは避けてください。
• 迅速なリント／ユニットテストのゲートと、時間のかかる統合テスト、イメージ、デプロイのジョブを分けてください。
• パスフィルターとマトリックスの上限を使い、モノレポのパイプラインの規模を変更内容に見合ったものにしてください。

ベストプラクティス

• クラウドへのデプロイでは、長期間有効な静的シークレットの代わりに OIDC または有効期間の短いフェデレーションを使用してください。
• 明示的に分離されていない限り、フォークからのプルリクエストワークフローは読み取り専用にしてください。
• forge がサポートしている場合は、リリース成果物の来歴情報またはアテステーションを生成してください。

ワークフロー

このチェックリストをコピーして進捗を管理してください。

• ステップ 1：プラットフォームを特定（または確認）
• ステップ 2：ドメインを選択
• ステップ 3：トリガー、ビルド、テスト、デプロイ、コンプライアンス、ランナーの要件を収集
• ステップ 4：プラットフォームのリファレンスを読み、設定を作成
• ステップ 5：リントに合格し、AI セルフチェックを通過（失敗した場合はステップ 4 に戻る）

ステップ 1：プラットフォームを特定する

シグナル	プラットフォーム
.github/workflows/*.yml	GitHub Actions
.gitlab-ci.yml	GitLab CI/CD
.forgejo/workflows/*.yml	Forgejo Actions
.gitea/workflows/*.yml	Gitea Actions
.woodpecker/*.yaml または .woodpecker.yaml	Woodpecker（Gitea/Forgejo）
ユーザーが「work」／「gitlab」／glab と言う	GitLab CI/CD
ユーザーが「home」／「forgejo」／fj と言う	Forgejo Actions
ユーザーが「gitea」と言う	Gitea Actions（または 1.20 以前の場合は Woodpecker）
ユーザーが「github」／「ghcr」／gh と言う	GitHub Actions

不明な場合は確認してください。表面的には似ていても、プラットフォーム間には大きな違いがあります。

ステップ 2：ドメインを判断する

• 「プロジェクト用の CI パイプラインを作成して」 -> ワークフロー設計
• 「パイプラインを強化して」／「アクションを固定して」 -> セキュリティ
• 「PCI 準拠にして」／「SBOM」 -> コンプライアンス
• 「これを GitLab から GitHub に移植して」 -> クロスプラットフォーム

ステップ 3：要件を収集する

パイプライン設定を作成する前に、次の点を確認してください。

• パイプラインを起動するトリガーは何ですか？ プッシュ、PR/MR、タグ、スケジュール、手動
• 何をビルドしますか？ 言語、ランタイム、パッケージマネージャー、ビルドツール
• 何をテストしますか？ ユニットテスト、統合テスト、E2E、リント、型チェック
• どこにデプロイしますか？ K8s、Docker レジストリ、クラウド、ベアメタル
• どのようなコンプライアンス要件がありますか？ PCI-DSS、SOC 2、社内ポリシー
• セルフホストランナーですか、それともマネージドランナーですか？ 利用可能なツールとキャッシュに影響します

ステップ 4：プラットフォーム固有のパターンを適用する

適切なリファレンスファイルを読んでください。

• GitHub Actions：references/github-actions.md
• GitLab CI/CD：references/gitlab-ci.md
• Forgejo/Gitea Actions および Woodpecker：references/forgejo-gitea-actions.md
• セルフホストランナー（5 つすべての実装）：references/runners.md
• ベストプラクティス（依存関係、リント、スキャン、レビューゲート、段階的な展開）：references/best-practices.md
• サプライチェーン／コンプライアンス：references/supply-chain.md

Forgejo CI/CD の場合は、以下の Forgejo セクションにある主要な差異の表から始めてください。

デプロイパイプラインを依頼された場合は、ステップ 3 で選択したライフサイクルの各段階を考慮し、明示的なデプロイジョブ、またはデプロイ用のプレースホルダーを明確に記載してください。対象環境と、必要な認可／保護要件を指定してください。テスト／ビルドのみの出力には、デプロイには不完全であることを明記してください。CI のみの依頼にはデプロイ段階を追加しないでください。

ステップ 5：検証する

生成した設定をリントしてください（GitHub/Forgejo/Gitea Actions には actionlint、GitLab には glab ci lint）。まず検出します：command -v actionlint >/dev/null || echo "actionlint missing"。リントまたは AI セルフチェックに失敗した場合は、設定を修正してステップ 4 に戻り、成功するまで繰り返してください。実行できなかったリントツールがあれば報告してください。 actionlint が自動検出するのは .github/workflows のみです。.forgejo/workflows/*.yml のパスは明示的に渡してください。カスタムランナーラベルは actionlint.yaml の self-hosted-runner.labels で宣言してください。リントに通すためだけに runs-on を変更してはいけません。

クロスプラットフォームのパターン

ステージの順序（すべてのプラットフォーム）

変更による動作、依存関係、リポジトリのポリシーに基づいてステージを選択します。これは順序のガイドであり、すべての PR ですべてのステージを実行する必要があるという意味ではありません。まず、影響を受ける範囲の高速なチェックから始めます。 変更が結果に影響する可能性がある場合は、ビルドまたは統合テストスイートを実行します。無関係でコストの高いマトリックスやリリース作業は、適切なスケジュール実行、マージ後の実行、またはリリース実行に回します。 チェックの選択と条件付きの必須ゲートについては、references/best-practices.md を参照してください。

lint -> test -> build -> scan -> deploy

1. Lint を最初に実行します - 最も早くフィードバックが得られ、フォーマットや構文の問題を早期に検出します
2. Test - ユニットテスト、型チェック
3. Build - コンパイル、バンドル、成果物の作成
4. Scan - SAST、依存関係の監査、コンテナスキャン（ビルド出力を対象）
5. Deploy - ステージングは自動、本番は手動

キャッシュ戦略

対象	キャッシュキー	プラットフォームに関する注意事項
npm/bun	${{ hashFiles('**/package-lock.json') }} または bun.lock	GH：actions/cache。GL：cache:key:files。Forgejo：GH と同じ。
pip	${{ hashFiles('**/requirements*.txt') }}	GH：cache: pip を指定した setup-python。GL：~/.cache/pip をキャッシュします。
poetry	${{ hashFiles('**/poetry.lock') }}	GH：cache: poetry を指定した setup-python。GL：~/.cache/pypoetry をキャッシュします。
uv	${{ hashFiles('**/uv.lock') }}	GH：astral-sh/setup-uv には組み込みキャッシュがあります。GL：~/.cache/uv をキャッシュします。
Go	${{ hashFiles('**/go.sum') }}	GH：actions/setup-go には組み込みキャッシュがあります。
Docker レイヤー	BuildKit キャッシュマウントまたはレジストリキャッシュ	GH：--cache-from type=gha。GL：--cache-from $CI_REGISTRY_IMAGE:cache。

ルール：キャッシュは速度を向上させるための最適化であり、正しさを保証する仕組みではありません。成果物はジョブ間のデータ受け渡しに使います。キャッシュはいつでも削除される可能性があるため、パイプラインはキャッシュなしでも動作する必要があります。

シークレット管理

プラットフォーム	仕組み	スコープ制御
GitHub	リポジトリ／組織／環境のシークレット	環境、リポジトリ、組織ごとに設定。デプロイ対象のブランチを指定します。
GitLab	CI/CD 変数（プロジェクト／グループ／インスタンス）	保護されたブランチ／タグ、環境、ログでのマスキング。
Forgejo	リポジトリ／組織のシークレット	リポジトリ、組織ごとに設定。現時点では環境ごとのスコープ指定はできません。

すべてのプラットフォーム：シークレットを出力したり、CLI 引数として渡したり（ps から参照できるため）、成果物に書き込んだりしないでください。環境変数またはファイルベースの注入を使用してください。

認証情報のライフサイクル

発行者の信頼性、ジョブの ID、シークレットの注入、後続処理の権限、ローテーション、失効を追跡します。承認された非本番ジョブで期限切れまたは失効済みの認証情報をテストし、ログ、キャッシュ、成果物に値が含まれないことを確認します。プロビジョニング／状態管理に関する懸念事項は terraform に、ワークロードの更新／再読み込みは kubernetes に任せ、それぞれの境界で担当者を明記してください。

デプロイゲート

環境	トリガー	承認
Dev/Preview	関連するアプリの変更、またはプレビューのリクエスト	プロジェクトのポリシーに従う
Staging	main へのマージ	なし（自動デプロイ）
Production	タグまたは手動ディスパッチ	必須レビュアー

GitLab：when: manual と environment:。GitHub：保護ルールを設定した environment:。 Forgejo：手動ディスパッチ（workflow_dispatch）。

モノレポのパターン

リポジトリに共通ライブラリを共有する複数のサービスが含まれる場合：

パスベースのトリガー

必須ワークフローは、該当するすべての PR でステータスを報告するようにし、コストの高いジョブはその内部で条件付き実行にします。必須ステータスが保留状態のままになる問題については、references/best-practices.md を参照してください。

• GitHub Actions：on.push.paths / on.pull_request.paths を使用して、サービスごとにワークフローの対象を絞ります
• GitLab CI/CD：compare_to: refs/heads/main を指定した rules: changes: paths: を使用します
• Forgejo：GitHub Actions と同じ（on.push.paths）

共通ライブラリの検出

libs/common/ が変更された場合は、それに依存するすべてのサービスを再ビルドします：

• 依存するサービスをマトリックスに列挙するか、すべてのサービスのワークフローをトリガーします
• paths フィルターでは glob を使用できます：paths: ['services/api/**', 'libs/common/**']

選択的ビルド

変更があったものだけをビルドします。方法は2つあります。

1. サービスごとのワークフローでpaths:フィルターを使用する（最も簡単で、推奨）
2. マトリックスを使った単一のワークフローと、ビルドが必要なサービスを出力する変更検出ジョブを使用する

ルール：共有ライブラリに変更があった場合は、必ず再ビルドしてください。共有依存関係を見落とす「変更なし」最適化を行うよりも、すべてを再ビルドするほうがよいです。

Python モノレポ固有の事項（GitLab / GitHub / Forgejo）

共通ライブラリ（libs/common/）を複数のサービスで共有する Python モノレポの場合：

• インストールの手順ではなく、リゾルバーの出力をキャッシュします。 hashFiles('**/requirements*.txt')または**/poetry.lock／**/uv.lockをキーにします。uvまたはpipを使う場合は、~/.cache/uvまたは~/.cache/pipと、サービスのパスおよびロックファイルのハッシュをキーにした各サービスの.venv/をキャッシュします。
• 共有ライブラリは編集可能モードでインストールします（pip install -e libs/common）。これにより、サービスは古いホイールではなく、リポジトリ内のバージョンをインポートします。
• パスフィルターを使って、サービスごとにジョブの対象を絞ります。 GitLab：rules: - changes: paths: ['services/api/**', 'libs/common/**'] compare_to: refs/heads/main。GitHub／Forgejo：on.push.paths／on.pull_request.paths。共有ライブラリの変更ですべてのサービスがトリガーされるよう、各サービスのフィルターに必ずlibs/common/**を含めてください。
• サービスごとのジョブテンプレートには、YAML アンカー（GitLab）／再利用可能なワークフロー（GitHub）を使います。 api、worker、schedulerにほぼ同一のブロックを3つ用意するのは、保守上の落とし穴になります。

モノレポの完全な.gitlab-ci.yml（YAML アンカー、compare_to、サービスごとの変更ルール、共有ライブラリの検出）については、references/gitlab-ci.mdを参照してください。

Forgejo CI/CD

Forgejo Actionsは、GitHub Actionsと「互換性を目的とするのではなく、使い慣れたものにすることを目的として設計されています」。 ワークフローの構文を再利用しますが、互換性は保証されません。

GitHub Actionsとの主な違い

機能	GitHub Actions	Forgejo Actions
permissions:	GITHUB_TOKENのスコープを制御します	適用されません - トークンは常に完全な読み書き権限を持ちます（フォークからのPRでは読み取り専用）
continue-on-error:（ジョブレベル）	ワークフローを失敗させずにジョブの失敗を許容します	サポートされていません - ステップレベルのみです
ランナーイメージ	200以上のツールを備えた管理対象のubuntu-24.04	セルフホスト型で、通常は軽量なDebian／Alpineです
アクションの解決	actions/checkout@v7 -> github.com	Forgejoミラーから解決されます（設定可能）
OIDC	permissions: id-token: write	enable-openid-connectキー
ワークフロー呼び出しのデフォルト値	inputs.<id>.defaultが設定されます	常に空です
マトリックス + 動的なruns-on	サポートされています	v14.0以降でサポートされています
LXC実行	サポートされていません	サポートされています（Forgejo固有）

ワークフローとリリースのテンプレート、Forgejoミラー上でのアクションSHAの確認方法、Forgejo特有の注意点（TLS、不足しているツール、適用されないpermissions:）、およびfjによるActions管理については、references/forgejo-gitea-actions.md（Forgejo Actionsのパターン）を参照してください。

Gitea CI/CD

Giteaには、実用的なCIの選択肢が2つあります。Gitea Actions（Forgejo Actionsと同じactベースのエンジンで、Gitea 1.21以降に対応）と、Woodpecker CI（別サービスで、コンテナーを中心に設計され、Webhook駆動）です。Droneはレガシーです。新規インストールには使用しないでください。

簡単な目安：GitHubから移行する場合や、運用するサービスを1つにしたい場合は、Gitea Actionsを使用してください。適切なマトリックスビルド、キャッシュの基本機能、またはより少ないリソース使用量が必要な場合は、Woodpeckerを使用してください。同じリポジトリに両方を実行しないでください。

アクションSHAの確認方法、Gitea ActionsとForgejo Actionsの違い、WoodpeckerのYAML例、プラグインとコマンドのステップ、OAuthの設定、マトリックスのパターン、Droneからの移行ガイダンスについては、references/forgejo-gitea-actions.mdを参照してください。

PCI-DSS：CI/CD コンプライアンスマッピング

対象範囲内のシステムでは、管理策を実際の要件および評価証拠に対応付けてください。

要件	CI/CD による対応
6.2.3	リリース前に独自開発／カスタムソフトウェアをレビューし、対象範囲と指摘事項への対応を記録します
6.3.2	ソフトウェア／コンポーネントのインベントリを維持します。SBOM はこれを支援できます
6.5.1	本番環境への変更承認、テスト、影響、および復旧手順を記録します

ツールが存在するだけでは、コンプライアンスを証明できません。アーティファクト署名と SBOM 形式は有用な管理策ですが、PCI の実装として一律に規定されているものではありません。評価範囲と一次情報については、references/supply-chain.md を参照してください。

テンプレートの規約

• GitHub Actions のテンプレートにある @<sha> はプレースホルダーです。対象バージョンの実際の 40 文字のコミット SHA に置き換えてください。SHA はアクションのリリースページで確認するか、Dependabot で自動管理してください。
• テンプレート内のイメージタグには、読みやすさを考慮して変動するマイナーバージョン（例：oven/bun:1.2、docker:29.9）を使用しています。本番環境では、特定のパッチバージョンまたは SHA256 ダイジェストに固定してください。テンプレートが示すのは許容される最小粒度であり、理想的な粒度ではありません。

参考ファイル

• references/github-actions.md - GitHub Actions のパターン、テンプレート、セキュリティ強化
• references/forgejo-gitea-actions.md - Forgejo Actions のテンプレート、SHA の確認方法、注意点、fj、Gitea Actions との違い、トラブルシューティング、Woodpecker のパターン、Drone からの移行ガイダンス
• references/gitlab-ci.md - GitLab CI/CD 19.x のパターン、SaaS とセルフマネージドの違い、Catalog、Components、セキュリティ
• references/runners.md - セルフホスト型ランナー（actions-runner、gitlab-runner、forgejo-runner、gitea-runner、woodpecker-agent）：インストール、登録、エグゼキューターの選択、Linux と macOS、セキュリティ強化
• references/best-practices.md - 依存関係の更新（Dependabot/Renovate）、段階的なリンティング、スキャンマトリクス（シークレット/SCA/コンテナ/IaC/SAST）、レビューゲート、マージキュー、展開順序
• references/supply-chain.md - サプライチェーンセキュリティ、インシデントのタイムライン、SHA の固定、SBOM/SLSA、PCI-DSS コンプライアンス、イメージ署名、侵害後の対応。slopsquatting、CI/CD 内の AI エージェント、パイプラインへのプロンプトインジェクションについては、「AI-Age Supply Chain Risks」セクションを参照してください
• references/target-versions.md - フォージ、ランナー、CI システム、サプライチェーンツールの、日付付きバージョンスナップショット

出力契約

契約の全文については、references/output-contract.md を参照してください。

• スキル名： CI-CD
• 成果物の分類： audits
• モード： 条件付き。既存のリポジトリ内容の分析、レビュー、監査、改善を依頼された場合は、references/output-contract.md のレポートサイズと証拠に関するルールを適用し、成果物を docs/local/audits/ci-cd/<YYYY-MM-DD>-<slug>.md に書き込んでください。質問への回答、概念の説明、新しいアーティファクトの作成、コンテンツの生成を依頼された場合は、契約に従わず自由に回答してください。
• 重大度の尺度： P0 | P1 | P2 | P3 | info（共通契約を参照。監査／レビューモードでのみ使用）

関連スキル

• code-review - アプリケーションコードの正確性をレビューします。パイプラインの YAML、式、ランナーの動作、キャッシュ、デプロイジョブのバグはこのスキルの対象です。
• security-audit - パイプラインコードではなく、アプリケーションコードを監査するためのスキルです
• docker - Dockerfile とコンテナイメージを最適化します
• kubernetes - パイプラインがデプロイする K8s マニフェストと Helm チャートを扱います
• git - パイプラインをトリガーする git 操作（コミット、PR/MR、タグ、リリース）を扱います。CI/CD は git イベントに反応し、git はそれらのイベントを発生させる操作を処理します。

ルール

AI セルフチェックでは、SHA のピン留め、設定内のシークレット、本番環境の認可、スキャンの順序を確認します。キャッシュ戦略と PCI のセクションでは、キャッシュとアーティファクトの使い分け、およびコンプライアンスの証跡を扱います。以下も追加してください。

• まずプラットフォームを確認します。 設定を書く前に、必ずどの CI/CD プラットフォームを使うか確認してください。Forgejo では「ほぼ動く」GitHub Actions の構文でも、エッジケースでひそかに失敗します。
• シークレットをログ、アーティファクト、argv に残さないでください。 保護されていないブランチでは、保護変数を絶対に使用しないでください。GitLab では、そのようなブランチで保護変数がひそかに空になります。
• パイプライン自体をテストしてください。 GitHub Actions には act、GitLab には gitlab-ci-local、またはプラットフォームのドライランモードを使用してください。本番環境でパイプラインのバグに気づくことのないようにしてください。