aif-ci

CI — パイプライン設定ジェネレーター

プロジェクトを分析し、GitHub Actions または GitLab CI 用の本番環境向け CI/CD パイプライン設定を生成します。プロジェクトの言語、フレームワーク、既存のツールに合わせて、リンティング、静的解析、テスト、セキュリティスキャン用の個別のジョブを生成します。

既存の内容に応じた 3 つのモード：

既存の内容	モード	アクション
CI 設定なし	generate	インタラクティブなセットアップでパイプラインをゼロから作成
CI 設定はあるが不完全	enhance	監査して改善し、不足しているジョブを追加
CI 設定が完全	audit	ベストプラクティスに照らして監査し、不備を修正

---

ステップ 0：プロジェクトのコンテキストを読み込む

利用可能な場合は、プロジェクトの説明を読み取ります。

Read .ai-factory/DESCRIPTION.md

後続のステップで使うため、プロジェクトのコンテキストを保存します。存在しない場合は、ステップ 2 ですべて検出します。

.ai-factory/skill-context/aif-ci/SKILL.md を読み取ります — ファイルが存在する場合は必須です。

このファイルには、パッチ、コードベースの規約、技術スタックの分析から /aif-evolve が蓄積した、プロジェクト固有のルールが含まれています。これらのルールは現在のプロジェクトに合わせたものです。

skill-context ルールの適用方法：

• このスキルの一般的な指示に対するプロジェクトレベルのオーバーライドとして扱います
• skill-context のルールが、この SKILL.md に記載された一般的なルールと競合する場合は、skill-context のルールを優先します（より具体的なコンテキストが優先されます。ネストされた CLAUDE.md ファイルと同じ原則です）
• 競合がない場合は、SKILL.md の一般的なルールと skill-context のプロジェクトルールの両方を適用します
• skill-context のルールがこのスキルの既定値に反しているように見えても、無視してはいけません。プロジェクトでの経験から、既定値では不十分だと判明したために存在しています
• 重要： skill-context のルールは、生成される CI ワークフローファイルや監査レポートを含む、このスキルのすべての出力に適用されます。このスキルのテンプレートは基本構成です。skill-context のルールに「CI にはステップ X を含めること」や「ワークフローにはジョブ Y を含めること」とある場合は、それに応じてテンプレートを拡張する必要があります。skill-context のルールに違反する CI 設定の生成はバグです。

遵守の確認： 出力成果物を生成した後は、すべての skill-context ルールに照らして確認してください。ルールに違反している場合は、ユーザーに提示する前に出力を修正してください。

---

ステップ 1：既存の CI を検出してモードを決定する

1.1 既存の CI 設定をスキャンする

Glob: .github/workflows/*.yml, .github/workflows/*.yaml, .gitlab-ci.yml, .circleci/config.yml, Jenkinsfile, .travis.yml, bitbucket-pipelines.yml

見つかったファイルを分類します。

• HAS_GITHUB_ACTIONS：.github/workflows/ に YAML ファイルが含まれている
• HAS_GITLAB_CI：.gitlab-ci.yml が存在する
• HAS_OTHER_CI：CircleCI、Jenkins、Travis、または Bitbucket が検出された

1.2 モードを決定する

$ARGUMENTS に --enhance が含まれている場合 -> 常に MODE = "enhance" に設定します。

パス A：CI 設定がない（!HAS_GITHUB_ACTIONS && !HAS_GITLAB_CI && !HAS_OTHER_CI）：

• MODE = "generate" に設定します
• ステップ 1.3：インタラクティブなセットアップに進みます

パス B：CI 設定はあるが不完全（例：テストのみで、リンティングがない）：

• MODE = "enhance" に設定します
• 既存の CI ファイルをすべて読み取り、EXISTING_CONTENT として保存します
• ログに記録します：「既存の CI 設定が見つかりました。分析して、不足しているジョブを追加します。」

パス C：CI 設定が完全（リンティング + テスト + 静的解析がある）：

• MODE = "audit" に設定します
• 既存の CI ファイルをすべて読み取り、EXISTING_CONTENT として保存します
• ログに記録します：「完全な CI 設定が見つかりました。ベストプラクティスに照らして監査し、不備を修正します。」

1.3 インタラクティブなセットアップ（生成モードのみ）

$ARGUMENTS から CI プラットフォームを特定するか、ユーザーに確認します。

$ARGUMENTS に github が含まれている場合 -> PLATFORM = "github" に設定します
$ARGUMENTS に gitlab が含まれている場合 -> PLATFORM = "gitlab" に設定します

それ以外の場合：

AskUserQuestion: Which CI/CD platform do you use?

Options:
1. GitHub Actions (Recommended) — .github/workflows/*.yml
2. GitLab CI — .gitlab-ci.yml

任意の機能について確認します：

AskUserQuestion: Which additional CI features do you need?

Options (multiSelect):
1. Security scanning — Dependency audit, SAST
2. Coverage reporting — Upload test coverage
3. Matrix builds — Test across multiple language versions
4. None — Just linting, static analysis, and tests

選択内容を保存します。

• PLATFORM：github | gitlab
• WANT_SECURITY：boolean
• WANT_COVERAGE：boolean
• WANT_MATRIX：boolean

1.4 既存のファイルを読み取る（拡張／監査モード）

既存の CI ファイルをすべて読み取り、EXISTING_CONTENT として保存します。

• すべての .github/workflows/*.yml ファイル
• .gitlab-ci.yml
• インクルードされている GitLab CI ファイル（include: ディレクティブを確認）

既存のファイルから PLATFORM を特定します。

---

ステップ 2：プロジェクトの詳細分析

プロジェクトを隅々までスキャンします。生成されるパイプラインのすべての判断は、このプロファイルに依存します。

2.1 言語とランタイム

ファイル	言語
composer.json	PHP
package.json	Node.js / TypeScript
pyproject.toml / setup.py / setup.cfg	Python
go.mod	Go
Cargo.toml	Rust
pom.xml	Java（Maven）
build.gradle / build.gradle.kts	Java/Kotlin（Gradle）

2.2 言語のバージョン

CI で使用するプロジェクトの言語バージョンを検出します。

言語	バージョンの参照元	例
PHP	composer.json -> require.php	>=8.2 -> ['8.2', '8.3', '8.4']
Node.js	package.json -> engines.node、.nvmrc、.node-version	>=18 -> [18, 20, 22]
Python	pyproject.toml -> requires-python、.python-version	>=3.11 -> ['3.11', '3.12', '3.13']
Go	go.mod -> go ディレクティブ	go 1.23 -> '1.23'
Rust	Cargo.toml -> rust-version、rust-toolchain.toml	1.82 -> '1.82'
Java	pom.xml -> maven.compiler.source、build.gradle -> sourceCompatibility	17 -> [17, 21]

マトリックスビルドの場合、プロジェクトの設定にある最小バージョンを下限として、最新の安定版も含めます。マトリックスビルド以外の場合は、制約を満たす最新バージョンを使用します。

2.3 パッケージマネージャーとロックファイル

ファイル	パッケージマネージャー	インストールコマンド
composer.lock	Composer	composer install --no-interaction --prefer-dist
bun.lockb	Bun	bun install --frozen-lockfile
pnpm-lock.yaml	pnpm	pnpm install --frozen-lockfile
yarn.lock	Yarn	yarn install --frozen-lockfile
package-lock.json	npm	npm ci
uv.lock	uv	uv sync --all-extras --dev
poetry.lock	Poetry	poetry install
Pipfile.lock	Pipenv	pipenv install --dev
requirements.txt	pip	pip install -r requirements.txt
go.sum	Go modules	go mod download
Cargo.lock	Cargo	（組み込み）

保存する値：PACKAGE_MANAGER、LOCK_FILE、INSTALL_CMD。

2.4–2.7 ツールの検出

設定ファイルと依存関係をスキャンして、プロジェクトのツールを検出します。ツールとコマンドの完全な対応表については、references/TOOL-COMMANDS.md を参照してください。

カテゴリ：リンターとフォーマッター（PHP-CS-Fixer、ESLint、Prettier、Biome、Ruff、golangci-lint、clippy、Checkstyle）、静的解析（PHPStan、Psalm、Rector、mypy、tsc）、カバレッジフラグを含むテストフレームワーク（PHPUnit、Pest、Jest、Vitest、pytest、go test、cargo test）、セキュリティ監査（composer audit、npm audit、pip-audit、govulncheck、cargo audit）。

2.8 サービスの検出

テストで外部サービス（データベース、Redis など）が必要かどうかを確認します。

Grep in tests/: postgres|mysql|redis|mongo|rabbitmq|elasticsearch
Glob: docker-compose.test.yml, docker-compose.ci.yml

サービスが必要な場合は、CI パイプラインでサービスコンテナとして設定されます。

2.9 ビルド出力

プロジェクトにビルド手順はありますか？

言語	ビルドの有無	ビルドコマンド
Node.js（build スクリプトがある場合）	あり	npm run build / pnpm build
Go	あり	go build ./...
Rust	あり	cargo build --release
Java	あり	mvn package -DskipTests -B / ./gradlew assemble
PHP	通常なし	—
Python	通常なし	—

まとめ

PROJECT_PROFILE を構築します。

• language、language_version、language_versions（マトリックス用）
• package_manager、lock_file、install_cmd
• linters：{name, command, config_file} のリスト
• static_analyzers：{name, command} のリスト
• test_framework、test_cmd、coverage_cmd
• security_tools：{name, command} のリスト
• has_build_step、build_cmd
• has_typescript：ブール値（型チェックジョブ用）
• services_needed：CI に必要なサービスのリスト
• source_dir：メインのソースディレクトリ（src/, app/, lib/）

---

ステップ 3：ベストプラクティスとテンプレートを読む

Read skills/ci/references/BEST-PRACTICES.md

プラットフォームと言語に合ったテンプレートを選択します。

GitHub Actions：

言語	テンプレート
PHP	templates/github/php.yml
Node.js	templates/github/node.yml
Python	templates/github/python.yml
Go	templates/github/go.yml
Rust	templates/github/rust.yml
Java	templates/github/java.yml

GitLab CI：

言語	テンプレート
PHP	templates/gitlab/php.yml
Node.js	templates/gitlab/node.yml
Python	templates/gitlab/python.yml
Go	templates/gitlab/go.yml
Rust	templates/gitlab/rust.yml
Java	templates/gitlab/java.yml

選択したテンプレートを読みます。

Read skills/ci/templates/<platform>/<language>.yml

---

ステップ 4：パイプラインを生成する（生成モード）

PROJECT_PROFILE、ベストプラクティス、テンプレートを基に、カスタマイズした CI パイプラインを生成します。

4.1 GitHub Actions の生成

関心事項ごとにワークフローを分ける — 各ファイルに固有のトリガー、権限、並行処理を設定します。

ファイル	名前	ジョブ	作成する条件
lint.yml	Lint	code-style、static-analysis、rector	リンターまたは SA が検出された場合
tests.yml	Tests	tests（＋サービスコンテナ）	常に
build.yml	Build	build	has_build_step
security.yml	Security	dependency-audit、dependency-review	WANT_SECURITY

関心事項ごとにファイルを分ける理由：

• PR で各チェックが個別のステータスチェックになるため、何が失敗したかをすぐに確認できます
• トリガーを個別に設定できます — セキュリティはスケジュール実行、テストは push/PR 時、ビルドはテストの後にのみ実行
• 権限を個別に設定できます — セキュリティでは security-events: write が必要になる場合があります
• 他のワークフローに影響を与えずに、1 つのワークフローを無効化または再実行できます
• ブランチ保護ルールで特定のワークフローを必須にできます（例：tests は必須にし、security は必須にしない）

単一ファイルにまとめる場合： lint と tests の 2 ジョブのみの非常に小規模なプロジェクトに限ります。関心事項が 3 つ以上になったら、分割します。

すべてのワークフローに同じヘッダーパターンを設定します。

name: <Name>

on:
  push:
    branches: [main]
  pull_request:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

permissions:
  contents: read

ファイルごとのジョブ構成：

lint.yml — すべてのコード品質チェックを並列実行します。

ジョブ	目的	含める条件
code-style	フォーマット（CS-Fixer、Prettier、Ruff format、rustfmt）	フォーマッターが検出された場合
lint	リント（ESLint、Ruff check、Clippy、golangci-lint）	リンターが検出された場合
static-analysis	型チェック／SA（PHPStan、Psalm、mypy、tsc）	SA ツールが検出された場合
rector	Rector のドライラン（PHP のみ）	Rector が検出された場合

すべてのジョブは並列で実行します（needs なし）。検出されたツールが 1 つだけの場合（例：golangci-lint のみを使う Go プロジェクト）、ファイル内のジョブが 1 つだけでも問題ありません。

tests.yml — テストスイート：

ジョブ	目的	含める条件
tests	単体テスト／統合テスト	常に
tests-<service>	サービスコンテナを必要とするテスト	services_needed が検出された場合

マトリックスビルド（複数の言語バージョン）は、このファイルにのみ設定します。

build.yml — ビルドの検証：

ジョブ	目的	備考
build	コンパイル／バンドルを検証します	workflow_run を使って外部ワークフローに依存させるか、独立して実行できます

security.yml — セキュリティスキャン：

ジョブ	目的	追加のトリガー
dependency-audit	脆弱性スキャン	schedule: cron '0 6 * * 1'（毎週）
dependency-review	PR の依存関係の差分	pull_request 時のみ

ジョブごとのルール：

1. 各ジョブで個別にセットアップします（チェックアウト、言語のセットアップ、キャッシュ、依存関係のインストール）
2. キャッシュ機能が組み込まれた言語別のセットアップアクションを使用します：
   • PHP：shivammathur/setup-php@v2 の tools: パラメーター
   • Node.js：actions/setup-node@v4 の cache: パラメーター
   • Python：astral-sh/setup-uv@v5（uv の場合）、または actions/setup-python@v5（pip の場合）
   • Go：actions/setup-go@v5（自動でキャッシュされます）
   • Rust：dtolnay/rust-toolchain@stable ＋ Swatinem/rust-cache@v2
   • Java：actions/setup-java@v4 の cache: パラメーター
3. マトリックスビルドでは fail-fast: false を使用します
4. WANT_COVERAGE の場合は、カバレッジをアーティファクトとしてアップロードします

マトリックスビルド（WANT_MATRIX の場合）：

マトリックスを使用するのは tests ジョブのみです。Lint／SA ジョブは最新バージョンのみで実行します。

tests:
  name: Tests (${{ matrix.<language>-version }})
  strategy:
    fail-fast: false
    matrix:
      <language>-version: <language_versions from PROJECT_PROFILE>

リンタージョブの統合：

プロジェクトで同じエコシステムのフォーマッターとリンターの両方を使用している場合は、1 つのジョブにまとめます：

• PHP：php-cs-fixer のチェックとその他の lint を code-style ジョブにまとめます
• Node.js：eslint と prettier を lint ジョブにまとめます。Biome は ESLint と Prettier の両方を置き換えます — Biome が検出された場合は、1 つの lint ジョブで npx biome check . のみを使用します
• Python：ruff check と ruff format --check を lint ジョブにまとめます（Ruff は両方に対応します）
• Rust：cargo fmt と cargo clippy は別々のジョブにできます（fmt は高速で、clippy にはコンパイルが必要です）

lint／SA とテストは統合しないでください — 明確なフィードバックを得られるよう、個別に失敗させる必要があります。

ワークフローファイルの生成には、templates/github/ と templates/gitlab/ のテンプレートをベースとして使用します。ヘッダーパターン（name、on、concurrency、permissions）と、前述のファイルごとのジョブ構成に従ってください。

4.2 GitLab CI の生成

出力ファイル：.gitlab-ci.yml

GitLab 固有のパイプライン構造、キャッシュ戦略、レポート形式の統合、言語別のパターンについては、references/GITLAB-PATTERNS.md を参照してください。

パイプラインのステージ：install → lint → test → build → security

4.3 サービスコンテナ

services_needed が空でない場合は、テストジョブにサービスコンテナを追加します。 GitHub Actions および GitLab CI のサービスコンテナ構文については、references/SERVICE-CONTAINERS.md を参照してください。

品質チェック（書き込み前）

書き込む前に、生成したパイプラインを確認します。

正確性：

• すべてのジョブにチェックアウト／セットアップ／インストールのステップがある
• 正しいロックファイルに対してキャッシュが設定されている
• すべてのコマンドが、プロジェクトに実際に存在するツールに対応している
• マトリックスのバージョンが、プロジェクトのバージョン制約に一致している
• サービスコンテナにヘルスチェックがある

ベストプラクティス：

• concurrency グループが設定されている（GitHub Actions）
• permissions: contents: read が設定されている（GitHub Actions）
• interruptible: true が設定されている（GitLab CI）
• workflow.rules が定義されている（GitLab CI）
• 可能な場合はジョブが並列実行される（不要な needs がない）
• マトリックスビルドで fail-fast: false が設定されている

過剰な設計を避ける：

• プロジェクトに存在しないツールのジョブがない
• プロジェクトが 1 つのバージョンのみを対象としている場合、マトリックスビルドがない
• 要求されていない場合、またはツールがインストールされていない場合は、セキュリティスキャンを行わない
• プロジェクトにビルド手順がない場合、ビルドジョブがない

---

Step 5: 既存のパイプラインの強化／監査

MODE = "enhance" または MODE = "audit" の場合は、EXISTING_CONTENT をプロジェクトプロファイルおよびベストプラクティスと照合して分析します。

5.1 ギャップ分析

既存のパイプラインを PROJECT_PROFILE と照合します。

不足しているジョブ：

• リンターはインストール済みですが、CI に lint ジョブがありませんか？
• SA ツールはインストール済みですが、SA ジョブがありませんか？
• テストは存在しますが、テストジョブがありませんか？
• セキュリティツールはインストール済みですが、セキュリティジョブがありませんか？

設定上の問題：

• キャッシュが設定されていませんか？
• 同時実行グループ（GitHub Actions）がありませんか？
• 非推奨のアクションを使用していませんか（例：dtolnay/rust-toolchain ではなく actions-rs を使用）？
• 変数やマトリックスではなく、言語のバージョンをハードコードしていませんか？
• マトリックスに fail-fast: false がありませんか？
• すべての GitLab ジョブで policy: pull-push を使用し、インストール以外のジョブでは pull を使用していませんか？

不足している機能：

• カバレッジツールが利用可能なのに、カバレッジレポートがありませんか？
• JUnit／codequality レポートとの連携（GitLab）がありませんか？
• モノレポ向けのパスフィルタリングがありませんか？
• workflow_dispatch トリガー（GitHub Actions）がありませんか？

5.2 監査レポートと修正

監査レポートの形式、修正フローの選択肢、表示テンプレートについては、references/AUDIT-REPORT.md を参照してください。

各チェックの結果を ✅／❌／⚠️ 付きの表で提示します。推奨事項を重大度（CRITICAL、HIGH、MEDIUM、LOW）別に分類します。すべて修正するか、重大な項目のみ修正するか、先に詳細を表示するかをユーザーに確認します。

**修正する場合：**既存の構成、ジョブ名、順序の規則を維持します。

---

ステップ 6：ファイルの作成

6.1 生成モード — パイプラインの作成

GitHub Actions：

Bash: mkdir -p .github/workflows
Write .github/workflows/lint.yml        # If linters/SA detected
Write .github/workflows/tests.yml       # Always
Write .github/workflows/build.yml       # If has_build_step
Write .github/workflows/security.yml    # If WANT_SECURITY

検出された懸念事項に対応するファイルのみを作成します。lint とテストのみの場合は、ファイルは 2 つです。プロジェクトが非常に小規模（lint ジョブ 1 つ、テストジョブ 1 つ）であれば、単一の ci.yml でも構いません。

GitLab CI：

Write .gitlab-ci.yml

GitLab CI では .gitlab-ci.yml を 1 つだけ使用し、ステージと DAG（needs:）で処理を分離します。

6.2 拡張／監査モード — 既存ファイルの更新

Edit ツールを使用して既存のファイルを編集します。元の構成を維持し、必要な項目のみを追加または変更します。

---

ステップ 7：概要とフォローアップ

7.1 概要の表示

references/AUDIT-REPORT.md の形式（Summary Display Template セクション）を使用して概要を表示します。プラットフォーム、作成したファイル、機能、クイックスタートコマンドを示します。

7.2 フォローアップスキルの提案

次を提案します：Makefile／Taskfile の CI ターゲットには /aif-build-automation、コンテナ化には /aif-dockerize。

成果物の所有権と設定ポリシー

• 主な所有対象：.github/workflows/* や .gitlab-ci.yml などの CI パイプライン成果物。
• 許可される関連更新：デフォルトでは CI ファイル以外はありません。
• 設定ポリシー：設計上、設定に依存しません。このスキルは config.yaml ではなく、リポジトリの検出とユーザーによる明示的な選択に依存します。