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，优先使用 devEngines.packageManager 而非 packageManager：pnpm 11+ 和 pnpm/setup action 会优先读取该字段，且 pnpm 会在 pnpm-lock.yaml 中记录解析后的版本。固定为确切版本而非版本范围，以确保每台机器和每次 CI 运行使用相同的 pnpm——在设置时解析当前最新版本（pnpm view pnpm version），并将其写为 { "name": "pnpm", "version": "<latest>", "onFail": "download" }。运行时也同理：在 devEngines.runtime 中声明 Node（pnpm 10.14+ 会下载它，并在锁文件中记录其校验和），而不是使用 .nvmrc 或 engines.node；固定为设置时解析出的当前 LTS 版本——pnpm runtime set node lts（pnpm 11.4+）会写入该字段；请确认保存的 version 是确切版本，而非版本范围。声明 pnpm 时写入该字段；迁移旧版 "packageManager": "pnpm@…" 声明值得进行，但并非必需。只保留一种声明，不要同时使用两种——如果两个字段的版本不一致，版本切换器会拒绝该项目。Yarn 仍需要 packageManager，这是它唯一读取的字段。Nub 会以兼容模式使用其他包管理器的锁文件，因此 pnpm-lock.yaml 旁边存在 nub.lock 表示使用的是 nub——仅根据锁文件下结论前，请先检查字段。

3. 生成工作流

读取 rules/ 中的每个规则文件，并在生成工作流时应用所有规则。

写入工作流前，按照 rules/action-pinning.md 固定每个 action 的版本，包括 GitHub 自有的 actions/*。使用 gh api repos/{owner}/{repo}/commits/{ref} --jq '.sha'，将预期的发行版或源引用解析为完整的提交 SHA，然后在注释中保留发行版或源引用。

如果项目会提交由迁移工具生成的迁移文件，还应按照 rules/migration-drift.md 添加独立的 migration-drift job，并告知用户将其设为必需的状态检查。

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/（action 版本固定、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. 自动修复

修复时，使用 gh api 查询固定版本所需的提交 SHA。

规则

规则	影响	文件
Action 固定版本	高	rules/action-pinning.md
权限	高	rules/permissions.md
迁移偏差	高	rules/migration-drift.md
并发	中	rules/concurrency.md
Node 版本	中	rules/node-version.md
缓存	中	rules/caching.md
触发器	低	rules/triggers.md
矩阵策略	低	rules/matrix.md
并行步骤	低	rules/parallel-steps.md