github-actions

モードの判定

デフォルトでは監査して報告します。CI の作成、追加、または設定を依頼された場合にのみワークフローを生成します。.github/workflows/ が存在しないという理由だけで生成することは決してありません。代わりに、見つからなかったことを報告します。修正は、修正またはピン留めを依頼された場合にのみ適用します。依頼が明確でない場合は、報告して修正を適用するかどうかを尋ねます。

作成モード

1. プロジェクトの種類を判定する

プロジェクトを示すファイルをスキャンします。

• package.json → Node.js/JS/TS
• go.mod → Go
• requirements.txt / pyproject.toml / setup.py → Python
• Cargo.toml → Rust
• Gemfile → Ruby

2. パッケージマネージャーを判定する（JS/TS プロジェクト）

ロックファイルから、次の順序でパッケージマネージャーを判定します。nub.lock、pnpm-lock.yaml、bun.lock/bun.lockb、yarn.lock、package-lock.json。ロックファイルがない場合は、確認してください。

package.json の devEngines.packageManager または packageManager フィールドは、どのロックファイルよりも優先されます。pnpm の場合は、packageManager より devEngines.packageManager を優先してください。pnpm 11 以降と pnpm/setup アクションはこのフィールドを先に読み取り、pnpm は解決済みのバージョンを pnpm-lock.yaml に記録します。範囲ではなく正確なバージョンをピン留めし、すべてのマシンと CI 実行で同じ pnpm が使われるようにしてください。設定時に最新バージョンを解決し（pnpm view pnpm version）、{ "name": "pnpm", "version": "<latest>", "onFail": "download" } として記述します。ランタイムも同様です。.nvmrc や engines.node ではなく devEngines.runtime で Node を宣言し（pnpm 10.14 以降は Node をダウンロードし、そのチェックサムをロックファイルに記録します）、設定時に解決した現在の LTS バージョンにピン留めします。pnpm runtime set node lts（pnpm 11.4 以降）でこのフィールドを記述できます。保存された version が範囲ではなく正確なバージョンであることを確認してください。pnpm を宣言する際はこのフィールドも記述します。レガシーな "packageManager": "pnpm@…" の移行も推奨されますが、必須ではありません。宣言は両方ではなく、どちらか一方にしてください。2 つのフィールドの値が一致しないプロジェクトでは、バージョン切り替えツールが動作しません。Yarn では、読み取る唯一のフィールドである packageManager が引き続き必要です。Nub は別のマネージャーのロックファイル上で互換モードとして動作するため、pnpm-lock.yaml と並んで nub.lock がある場合は nub を意味します。ロックファイルだけから結論を出す前に、フィールドを確認してください。

3. ワークフローを生成する

rules/ 内の各ルールファイルを読み、ワークフローの生成時にすべて適用します。

ワークフローを記述する前に、rules/action-pinning.md に従って、GitHub 所有の actions/* を含むすべてのアクションをピン留めします。gh api repos/{owner}/{repo}/commits/{ref} --jq '.sha' を使って、対象のリリースまたはソース ref を完全なコミット SHA に解決し、コメントにはリリースまたはソース ref を残します。

プロジェクトがマイグレーションツールによるマイグレーションをコミットする場合は、rules/migration-drift.md に従って別個の migration-drift ジョブも追加し、これを必須のステータスチェックにするようユーザーに伝えます。

4. ワークフローテンプレート

手順 1 で判定した言語に応じて選択します。以下のテンプレートは JS/TS のデフォルトです。それ以外の言語が判定された場合は、references/<lang>.md を読み、そちらのテンプレートを使用します。

言語	テンプレート
JS/TS（Node）	以下のテンプレート
Go	references/go.md
Python	references/python.md
Rust	references/rust.md
Ruby	references/ruby.md

すべてのテンプレートに同じ rules/（アクションのピン留め、permissions、並行実行）が適用されます。検出されたパッケージマネージャーに合わせて JS/TS テンプレートを調整します（<pm> を検出したパッケージマネージャーに置き換えます）。

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  contents: read

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

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<full-SHA>  # <latest release>
      - uses: actions/setup-node@<full-SHA>  # <latest release>
        with:
          node-version: 'lts/*'
          cache: '<pm>'
      - run: <pm> install --frozen-lockfile
      - run: <pm> check
      - run: <pm> test
      - run: <pm> build

pnpm の場合は、actions/setup-node とインストール手順を、デフォルト設定の単一の pnpm/setup ステップに置き換えます（rules/node-version.md）。入力を指定しない場合、devEngines.packageManager から pnpm を、devEngines.runtime から Node をインストールし、その後 pnpm install を実行します。

監査モード

1. ワークフローをスキャンする

.github/workflows/ 内のすべての .yml および .yaml ファイルを読み、rules/ ディレクトリ内のすべてのルールに照らして監査します。

2. レポート形式

各指摘事項を path:line — 問題点 → 修正内容 の形式で、重要度ごとにまとめて報告してください。最後に、重要度ごとの件数とスキャンしたファイル数を記載してください。

ピン留めと権限だけでなく、移行のずれ、並行処理、Node のバージョン、キャッシュ、トリガー、マトリックス、並列ステップについても、すべてのルール違反を報告してください。

3. 自動修正

修正する際は、ピン留めに使用するコミット SHA を gh api で調べてください。

ルール

ルール	影響度	ファイル
アクションのピン留め	HIGH	rules/action-pinning.md
権限	HIGH	rules/permissions.md
移行のずれ	HIGH	rules/migration-drift.md
並行処理	MEDIUM	rules/concurrency.md
Node のバージョン	MEDIUM	rules/node-version.md
キャッシュ	MEDIUM	rules/caching.md
トリガー	LOW	rules/triggers.md
マトリックス戦略	LOW	rules/matrix.md
並列ステップ	LOW	rules/parallel-steps.md