configure-workflows

/configure:workflows

プロジェクトの標準に照らして、GitHub Actions の CI/CD ワークフローを確認し、設定します。

このスキルを使用するタイミング

次の場合にこのスキルを使用します…	次の場合は別の方法を使用します…
GitHub Actions ワークフローがプロジェクトの標準に準拠しているか確認する	失敗した CI 実行をデバッグする（github-actions-inspection スキルを使用）
コンテナーのビルド、テスト、または release-please ワークフローを設定する	Claude を利用する再利用可能なワークフローをインストールする（/configure:reusable-workflows を使用）
古いアクションのバージョン（checkout、build-push など）を更新する	カスタムワークフローを一から作成する（ci-workflows スキルを使用）
既存のワークフローにマルチプラットフォームビルドや GHA キャッシュを追加する	セキュリティに特化したワークフローを設定する（/configure:security を使用）
プロジェクトで不足している必須ワークフローを監査する	GitHub リポジトリの設定やブランチ保護ルールを管理する

コンテキスト

• ワークフローディレクトリ： !find . -maxdepth 1 -type d -name \'.github/workflows\'
• ワークフローファイル： !find . -path '*/.github/workflows/*' -maxdepth 3 \( -name '*.yml' -o -name '*.yaml' \)
• パッケージファイル： !find . -maxdepth 1 \( -name 'package.json' -o -name 'pyproject.toml' -o -name 'Cargo.toml' -o -name 'go.mod' \)
• Dockerfile： !find . -maxdepth 1 -name 'Dockerfile*'
• Release-please の設定： !find . -maxdepth 1 -name \'release-please-config.json\'

参照するスキル：ci-workflows、github-actions-auth-security

表示名の規則：生成または修復するすべてのワークフローの name: は <Domain>: <Action> [<target>] に従います（YAML では : がキーの区切りとして扱われるため、引用符で囲みます）。詳細な規則と有効なドメインについては、.claude/rules/workflow-naming.md を参照してください。

パラメーター

コマンド引数から解析します。

• --check-only：修正を提案せずに状態を報告します
• --fix：修正を自動的に適用します

実行

次の GitHub Actions ワークフロー設定チェックを実行します。

ステップ 1：最新のアクションバージョンを取得する

古いアクションを報告する前に、最新バージョンを確認します。

1. actions/checkout - リリース
2. actions/setup-node - リリース
3. actions/cache - リリース
4. docker/setup-buildx-action - リリース
5. docker/build-push-action - リリース
6. docker/login-action - リリース
7. docker/metadata-action - リリース
8. reproducible-containers/buildkit-cache-dance - リリース
9. google-github-actions/release-please-action - リリース

WebSearch または WebFetch を使用して、現在のバージョンを確認します。

ステップ 2：プロジェクトの種類を検出し、ワークフローを一覧表示する

1. .github/workflows/ ディレクトリがあるか確認します
2. すべてのワークフローファイル（.yml、.yaml）を一覧表示します
3. ワークフローを目的別（コンテナビルド、テスト、リリース）に分類します

プロジェクトの種類に基づいて、必要なワークフローを判断します。

プロジェクトの種類	必須ワークフロー
フロントエンド	container-build、release-please、renovate（任意：claude-auto-fix）
Python	container-build、release-please、test、renovate（任意：claude-auto-fix）
インフラストラクチャ	release-please、renovate（任意：docs、claude-auto-fix）

Step 3: ワークフローの準拠状況を分析する

コンテナビルドワークフローのチェック：

チェック項目	標準	重大度
checkout アクション	v6	古い場合は警告
build-push アクション	v7	古い場合は警告
マルチプラットフォーム	amd64 + arm64	未設定の場合は警告
レジストリ	GHCR (ghcr.io)	情報
キャッシュ	GHA キャッシュが有効	未設定の場合は警告
権限	明示的に指定	未設定の場合は警告
id-token: write	provenance/SBOM が有効な場合に必須	未設定の場合は警告
キャッシュスコープ	複数のビルドジョブがある場合は明示的な scope=	未設定の場合は警告
使用されないメタデータタグ	スケジュールトリガーなしで type=schedule を指定しない	情報
Semver 正規表現のエスケープ	type=match パターン内のドットをエスケープ（\d+\.\d+）	エスケープされていない場合は警告
ハードコードされたイメージ名	${{ github.repository }} から導出	ハードコードされている場合は情報
ダイジェスト出力	トレーサビリティのため、id: を使って build-push のダイジェストを取得	未設定の場合は情報
ジョブサマリー	イメージ／ダイジェスト／タグを $GITHUB_STEP_SUMMARY に書き込む	未設定の場合は情報
重複したジョブ条件	兄弟ジョブ間で if: が同一の場合、ゲートジョブを提案	情報

Release Please ワークフローのチェック：

チェック項目	標準	重大度
アクションのバージョン	v4	古い場合は警告
トークン	MY_RELEASE_PLEASE_TOKEN	GITHUB_TOKEN の場合は警告
権限	contents: write, pull-requests: write	不足している場合は失敗

テストワークフローのチェック：

チェック項目	標準	重大度
Node バージョン	22	古い場合は警告
Lint	npm run lint	未設定の場合は警告
型チェック	npm run typecheck	未設定の場合は警告
カバレッジ	カバレッジのアップロード	情報

Renovate ワークフローのチェック：

チェック項目	標準	重大度
RENOVATE_REPOSITORIES 環境変数	設定必須（${{ github.repository }}）	未設定の場合は失敗
checkout アクション	v6	古い場合は警告
renovatebot/github-action	マイナーバージョンを固定（例：v46.1.0）。メジャータグは不可	メジャーのみのタグの場合は警告
再利用可能なワークフローを使用	推奨（インフラストラクチャを除く）	単独の場合は情報

Claude 自動修正ワークフローのチェック（存在する場合）：

チェック項目	標準	重大度
workflow_run トリガー	少なくとも 1 つのワークフローを監視	設定が誤っている場合は警告
ループ防止	fix(auto): コミットをスキップ	未設定の場合は失敗
重複排除	オープン状態の自動修正 PR 数に上限を設定	未設定の場合は警告
Claude Code Action	anthropics/claude-code-action@v1	古い場合は警告
OAuth トークン	CLAUDE_CODE_OAUTH_TOKEN シークレット	未設定の場合は失敗
権限	必要最小限の権限セット	過剰な場合は警告

Step 4: 準拠レポートを生成する

ワークフローの状態、ワークフローごとのチェック結果、欠落しているワークフローを示す、書式設定された準拠レポートを出力します。

--check-only が設定されている場合は、ここで終了します。

レポートの書式については、REFERENCE.md を参照してください。

Step 5: 設定を適用する（--fix が指定された場合、またはユーザーが確認した場合）

1. 欠落しているワークフロー：標準テンプレートから作成します
2. 古いアクション：バージョン番号を更新します
3. マルチプラットフォームの設定漏れ：build-push にプラットフォームを追加します
4. キャッシュの設定漏れ：GHA キャッシュ設定を追加します

標準テンプレート（コンテナビルド、テストワークフロー）については、REFERENCE.md を参照してください。

Step 6: 標準の追跡情報を更新する

.project-standards.yaml を更新します：

components:
  workflows: "2025.1"

エージェント向けの最適化

コンテキスト	コマンド
簡易準拠チェック	/configure:workflows --check-only
すべての問題を自動修正	/configure:workflows --fix
ワークフローファイルを一覧表示	find .github/workflows -name '*.yml' -o -name '*.yaml'
アクションのバージョンを確認	rg 'uses:' .github/workflows/ --no-heading
release-please の設定を確認	test -f release-please-config.json && echo "EXISTS"

フラグ

フラグ	説明
--check-only	修正を提示せずに状態を報告
--fix	修正を自動的に適用

関連項目

• /configure:container - コンテナインフラストラクチャの包括的な設定（ビルド、レジストリ、スキャン）
• /configure:dockerfile - Dockerfile の設定とセキュリティ
• /configure:release-please - リリース自動化の詳細
• /configure:all - すべてのコンプライアンスチェックを実行
• ci-workflows スキル - ワークフローパターン
• github-actions-inspection スキル - ワークフローのデバッグ