aif-ci

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

CI — Pipeline Configuration Generator

CI — 流水线配置生成器

Analyze a project and generate production-grade CI/CD pipeline configuration for GitHub Actions or GitLab CI. Generates separate jobs for linting, static analysis, tests, and security scanning — adapted to the project's language, framework, and existing tooling.

Three modes based on what exists:

What exists	Mode	Action
No CI config	`generate`	Create pipeline from scratch with interactive setup
CI config exists but incomplete	`enhance`	Audit & improve, add missing jobs
Full CI config	`audit`	Audit against best practices, fix gaps

分析项目并生成适用于GitHub Actions或GitLab CI的生产级CI/CD流水线配置。针对项目的语言、框架和现有工具，生成独立的代码检查、静态分析、测试和安全扫描任务。

基于现有状态的三种模式：

现有状态	模式	操作
无CI配置	`generate`	通过交互式设置从头创建流水线
CI配置存在但不完整	`enhance`	审核并改进配置，添加缺失任务
完整CI配置	`audit`	对照最佳实践审核配置，修复漏洞

Step 0: Load Project Context

步骤0：加载项目上下文

Read the project description if available:

Read .ai-factory/DESCRIPTION.md

Store project context for later steps. If absent, Step 2 detects everything.

Read
.ai-factory/skill-context/aif-ci/SKILL.md
— MANDATORY if the file exists.

This file contains project-specific rules accumulated by

/aif-evolve

from patches, codebase conventions, and tech-stack analysis. These rules are tailored to the current project.

How to apply skill-context rules:

Treat them as project-level overrides for this skill's general instructions
When a skill-context rule conflicts with a general rule written in this SKILL.md, the skill-context rule wins (more specific context takes priority — same principle as nested CLAUDE.md files)
When there is no conflict, apply both: general rules from SKILL.md + project rules from skill-context
Do NOT ignore skill-context rules even if they seem to contradict this skill's defaults — they exist because the project's experience proved the default insufficient
CRITICAL: skill-context rules apply to ALL outputs of this skill — including generated CI workflow files and audit reports. Templates in this skill are base structures. If a skill-context rule says "CI MUST include step X" or "workflow MUST have job Y" — you MUST augment the templates accordingly. Generating CI config that violates skill-context rules is a bug.

Enforcement: After generating any output artifact, verify it against all skill-context rules. If any rule is violated — fix the output before presenting it to the user.

若有项目描述则读取：

Read .ai-factory/DESCRIPTION.md

保存项目上下文供后续步骤使用。若不存在该文件，步骤2将自动检测所有信息。

读取
.ai-factory/skill-context/aif-ci/SKILL.md
— 若文件存在则为必填项。

该文件包含由

/aif-evolve

从补丁、代码库约定和技术栈分析中积累的项目特定规则，这些规则是为当前项目量身定制的。

如何应用技能上下文规则：

将其视为本技能通用指令的项目级覆盖规则
当技能上下文规则与本SKILL.md中的通用规则冲突时，技能上下文规则优先（更具体的上下文优先级更高 — 与嵌套CLAUDE.md文件的原则相同）
无冲突时，同时应用SKILL.md的通用规则和技能上下文的项目规则
即使技能上下文规则看似与本技能默认设置矛盾，也不得忽略 — 这些规则存在是因为项目实践证明默认设置不足
关键要求： 技能上下文规则适用于本技能的所有输出 — 包括生成的CI工作流文件和审核报告。本技能中的模板是基础结构。若技能上下文规则规定“CI必须包含步骤X”或“工作流必须有任务Y” — 必须相应扩充模板。生成违反技能上下文规则的CI配置属于错误。

执行要求： 生成任何输出工件后，需对照所有技能上下文规则验证。若违反任何规则 — 在呈现给用户前修复输出内容。

Step 1: Detect Existing CI & Determine Mode

步骤1：检测现有CI并确定模式

1.1 Scan for Existing CI Configuration

1.1 扫描现有CI配置

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

Classify found files:

```
HAS_GITHUB_ACTIONS
```
:
```
.github/workflows/
```
contains YAML files
```
HAS_GITLAB_CI
```
:
```
.gitlab-ci.yml
```
exists
```
HAS_OTHER_CI
```
: CircleCI, Jenkins, Travis, or Bitbucket detected

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 Determine Mode

1.2 确定模式

If
$ARGUMENTS
contains
--enhance
-> set

MODE = "enhance"

regardless.

Path A: No CI config exists (

!HAS_GITHUB_ACTIONS && !HAS_GITLAB_CI && !HAS_OTHER_CI

Set
```
MODE = "generate"
```
Proceed to Step 1.3: Interactive Setup

Path B: CI config exists but is incomplete (e.g., has only tests, no linting):

Set
```
MODE = "enhance"
```
Read all existing CI files -> store as
```
EXISTING_CONTENT
```
Log: "Found existing CI configuration. Will analyze and add missing jobs."

Path C: Full CI setup (has linting + tests + static analysis):

Set
```
MODE = "audit"
```
Read all existing CI files -> store as
```
EXISTING_CONTENT
```
Log: "Found complete CI setup. Will audit against best practices and fix gaps."

若
$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 Interactive Setup (Generate Mode Only)

1.3 交互式设置（仅生成模式）

Determine CI platform from

$ARGUMENTS

or ask:

$ARGUMENTS

contains

github

-> set

PLATFORM = "github"

$ARGUMENTS

contains

gitlab

-> set

PLATFORM = "gitlab"

Otherwise:

AskUserQuestion: Which CI/CD platform do you use?

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

Ask about optional features:

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

Store choices:

```
PLATFORM
```
: github | gitlab
```
WANT_SECURITY
```
: boolean
```
WANT_COVERAGE
```
: boolean
```
WANT_MATRIX
```
: boolean

从

$ARGUMENTS

中确定CI平台，或询问用户：

若

$ARGUMENTS

包含

github

-> 设置

PLATFORM = "github"

若

$ARGUMENTS

包含

gitlab

-> 设置

PLATFORM = "gitlab"

否则：

AskUserQuestion: 您使用哪个CI/CD平台？

选项：
1. GitHub Actions（推荐） — .github/workflows/*.yml
2. GitLab CI — .gitlab-ci.yml

询问可选功能：

AskUserQuestion: 您需要哪些额外的CI功能？

选项（可多选）：
1. 安全扫描 — 依赖项审核、SAST
2. 覆盖率报告 — 上传测试覆盖率
3. 矩阵构建 — 跨多个语言版本测试
4. 无 — 仅需代码检查、静态分析和测试

保存选择：

```
PLATFORM
```
: github | gitlab
```
WANT_SECURITY
```
: 布尔值
```
WANT_COVERAGE
```
: 布尔值
```
WANT_MATRIX
```
: 布尔值

1.4 Read Existing Files (Enhance / Audit Modes)

1.4 读取现有文件（增强/审核模式）

Read all existing CI files and store as

EXISTING_CONTENT

All
```
.github/workflows/*.yml
```
files
```
.gitlab-ci.yml
```
Any included GitLab CI files (check
```
include:
```
directives)

Determine

PLATFORM

from existing files.

读取所有现有CI文件并保存为

EXISTING_CONTENT

：

所有
```
.github/workflows/*.yml
```
文件
```
.gitlab-ci.yml
```
文件
所有被GitLab CI包含的文件（检查
```
include:
```
指令）

从现有文件中确定

PLATFORM

。

Step 2: Deep Project Analysis

步骤2：深度项目分析

Scan the project thoroughly — every decision in the generated pipeline depends on this profile.

全面扫描项目 — 生成流水线的每个决策都依赖于此分析结果。

2.1 Language & Runtime

2.1 语言与运行时

File	Language
`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)

文件	语言
`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 Language Version

2.2 语言版本

Detect the project's language version to use in CI:

Language	Version Source	Example
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` directive	`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]`

For matrix builds: use the minimum version from the project config as the lowest, and include the latest stable version. For non-matrix builds: use the latest version that satisfies the constraint.

检测项目使用的语言版本以用于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 Package Manager & Lock File

2.3 包管理器与锁定文件

File	Package Manager	Install Command
`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	(built-in)

Store:

PACKAGE_MANAGER

LOCK_FILE

INSTALL_CMD

文件	包管理器	安装命令
`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 Tool Detection

2.4–2.7 工具检测

Detect project tools by scanning config files and dependencies. For the complete tool-to-command mapping → read

references/TOOL-COMMANDS.md

Categories: Linters & Formatters (PHP-CS-Fixer, ESLint, Prettier, Biome, Ruff, golangci-lint, clippy, Checkstyle), Static Analysis (PHPStan, Psalm, Rector, mypy, tsc), Test Frameworks (PHPUnit, Pest, Jest, Vitest, pytest, go test, cargo test) with coverage flags, Security Audit (composer audit, npm audit, pip-audit, govulncheck, cargo audit).

通过扫描配置文件和依赖项检测项目工具。完整的工具-命令映射 → 阅读

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 Services Detection

2.8 服务检测

Check if tests require external services (database, Redis, etc.):

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

If services are needed, they will be configured in the CI pipeline as service containers.

检查测试是否需要外部服务（数据库、Redis等）：

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

若需要服务，将在CI流水线中配置为服务容器。

2.9 Build Output

2.9 构建输出

Does the project have a build step?

Language	Has Build	Build Command
Node.js (with `build` script)	Yes	`npm run build` / `pnpm build`
Go	Yes	`go build ./...`
Rust	Yes	`cargo build --release`
Java	Yes	`mvn package -DskipTests -B` / `./gradlew assemble`
PHP	Usually no	—
Python	Usually no	—

项目是否包含构建步骤？

语言	是否需要构建	构建命令
Node.js（含 `build` 脚本）	是	`npm run build` / `pnpm build`
Go	是	`go build ./...`
Rust	是	`cargo build --release`
Java	是	`mvn package -DskipTests -B` / `./gradlew assemble`
PHP	通常不需要	—
Python	通常不需要	—

Summary

总结

Build

PROJECT_PROFILE

language

language_version

language_versions

(for matrix)

```
package_manager
```
,
```
lock_file
```
,
```
install_cmd
```
```
linters
```
: list of {name, command, config_file}
```
static_analyzers
```
: list of {name, command}
```
test_framework
```
,
```
test_cmd
```
,
```
coverage_cmd
```
```
security_tools
```
: list of {name, command}
```
has_build_step
```
,
```
build_cmd
```
```
has_typescript
```
: boolean (for typecheck job)
```
services_needed
```
: list of services for CI
```
source_dir
```
: main source directory (src/, app/, lib/)

构建

PROJECT_PROFILE

：

language

language_version

language_versions

（用于矩阵构建）

```
package_manager
```
,
```
lock_file
```
,
```
install_cmd
```
```
linters
```
: {名称, 命令, 配置文件}列表
```
static_analyzers
```
: {名称, 命令}列表
```
test_framework
```
,
```
test_cmd
```
,
```
coverage_cmd
```
```
security_tools
```
: {名称, 命令}列表
```
has_build_step
```
,
```
build_cmd
```
```
has_typescript
```
: 布尔值（用于类型检查任务）
```
services_needed
```
: CI所需服务列表
```
source_dir
```
: 主源码目录（src/, app/, lib/）

Step 3: Read Best Practices & Templates

步骤3：读取最佳实践与模板

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

Select templates matching the platform and language:

GitHub Actions:

Language	Template
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:

Language	Template
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 the selected template:

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

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

Step 4: Generate Pipeline (Generate Mode)

步骤4：生成流水线（生成模式）

Using the

PROJECT_PROFILE

, best practices, and template as a base, generate a customized CI pipeline.

以

PROJECT_PROFILE

、最佳实践和模板为基础，生成定制化CI流水线。

4.1 GitHub Actions Generation

4.1 GitHub Actions生成

One workflow per concern — each file has its own triggers, permissions, concurrency:

File	Name	Jobs	When to create
`lint.yml`	Lint	code-style, static-analysis, rector	Linters or SA detected
`tests.yml`	Tests	tests (+ service containers)	Always
`build.yml`	Build	build	`has_build_step`
`security.yml`	Security	dependency-audit, dependency-review	`WANT_SECURITY`

Why one file per concern:

Each check is a separate status check in PR — instantly see what failed
Independent triggers — security on schedule, tests on push/PR, build only after tests
Independent permissions — security may need
```
security-events: write
```
Can disable/re-run one workflow without touching others
Branch protection rules can require specific workflows (e.g. require
```
tests
```
but not
```
security
```
)

When to keep single file: Only for very small projects with just lint + tests (2 jobs). As soon as there are 3+ concerns — split.

Every workflow gets the same header pattern:

yaml

name: <Name>

on:
  push:
    branches: [main]
  pull_request:

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

permissions:
  contents: read

Per-file job organization:

lint.yml
— all code quality checks in parallel:

Job	Purpose	When to include
`code-style`	Formatting (CS-Fixer, Prettier, Ruff format, rustfmt)	Formatter detected
`lint`	Linting (ESLint, Ruff check, Clippy, golangci-lint)	Linter detected
`static-analysis`	Type checking / SA (PHPStan, Psalm, mypy, tsc)	SA tools detected
`rector`	Rector dry-run (PHP only)	Rector detected

All jobs run in parallel (no

needs

). If only one tool detected (e.g. Go with just golangci-lint) — single job in the file is fine.

tests.yml
— test suite:

Job	Purpose	When to include
`tests`	Unit/integration tests	Always
`tests-<service>`	Tests requiring service containers	`services_needed` detected

Matrix builds (multiple language versions) only in this file.

build.yml
— build verification:

Job	Purpose	Notes
`build`	Verify compilation/bundling	Can depend on external workflow via `workflow_run` or just run independently

security.yml
— security scanning:

Job	Purpose	Extra triggers
`dependency-audit`	Vulnerability scan	`schedule: cron '0 6 * * 1'` (weekly)
`dependency-review`	PR dependency diff	Only on `pull_request`

Per-job rules:

Each job gets its own setup (checkout, language setup, cache, dependency install)

Use language-specific setup actions with built-in cache:

PHP:
```
shivammathur/setup-php@v2
```
with
```
tools:
```
parameter
Node.js:
```
actions/setup-node@v4
```
with
```
cache:
```
parameter

Python:

astral-sh/setup-uv@v5

(if uv) or

actions/setup-python@v5

(if pip)

Go:
```
actions/setup-go@v5
```
(auto-caches)

Rust:

dtolnay/rust-toolchain@stable

Swatinem/rust-cache@v2

Java:
```
actions/setup-java@v4
```
with
```
cache:
```
parameter

Use
```
fail-fast: false
```
in matrix builds
Upload coverage as artifact when
```
WANT_COVERAGE
```

Matrix builds (when

WANT_MATRIX

Only the

tests

job uses a matrix. Lint/SA jobs run on the latest version only.

yaml

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

Combining linter jobs:

If the project has both a formatter AND a linter from the same ecosystem, combine them into one job:

PHP:
```
php-cs-fixer
```
check + other lint ->
```
code-style
```
job
Node.js:
```
eslint
```
+
```
prettier
```
->
```
lint
```
job. Biome replaces BOTH ESLint and Prettier — if Biome is detected, use only
```
npx biome check .
```
in a single
```
lint
```
job
Python:
```
ruff check
```
+
```
ruff format --check
```
->
```
lint
```
job (Ruff handles both)
Rust:
```
cargo fmt
```
+
```
cargo clippy
```
-> can be separate (fmt is fast, clippy needs compilation)

Do NOT combine lint/SA with tests — they should fail independently with clear feedback.

Use the templates in

templates/github/

and

templates/gitlab/

as a base for generating workflow files. Follow the header pattern (name, on, concurrency, permissions) and per-file job organization described above.

按关注点拆分工作流 — 每个文件有独立的触发器、权限、并发设置：

文件	名称	任务	创建条件
`lint.yml`	代码检查	code-style, static-analysis, rector	检测到代码检查器或静态分析工具
`tests.yml`	测试	tests（+服务容器）	始终创建
`build.yml`	构建	build	`has_build_step` 为真
`security.yml`	安全	dependency-audit, dependency-review	`WANT_SECURITY` 为真

按关注点拆分文件的原因：

每个检查在PR中是独立的状态检查 — 可立即查看哪项失败
独立触发器 — 安全扫描按计划执行，测试在推送/PR时执行，构建仅在测试通过后执行
独立权限 — 安全任务可能需要
```
security-events: write
```
权限
可单独禁用/重新运行一个工作流，无需修改其他工作流
分支保护规则可要求特定工作流（例如要求
```
tests
```
但不要求
```
security
```
）

何时使用单个文件： 仅适用于极小项目（仅代码检查 + 测试两个任务）。一旦有3个及以上关注点 — 拆分文件。

所有工作流使用相同的头部模式：

yaml

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`	类型检查/静态分析（PHPStan、Psalm、mypy、tsc）	检测到静态分析工具
`rector`	Rector预运行（仅PHP）	检测到Rector

所有任务并行运行（无

needs

依赖）。若仅检测到一个工具（例如仅使用golangci-lint的Go项目） — 文件中单个任务即可。

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` 时触发

任务规则：

每个任务有独立的初始化步骤（代码检出、语言环境设置、缓存、依赖安装）

使用内置缓存的语言特定初始化Action：

PHP:
```
shivammathur/setup-php@v2
```
，带
```
tools:
```
参数
Node.js:
```
actions/setup-node@v4
```
，带
```
cache:
```
参数
Python: 若使用uv则用
```
astral-sh/setup-uv@v5
```
，若使用pip则用
```
actions/setup-python@v5
```
Go:
```
actions/setup-go@v5
```
（自动缓存）

Rust:

dtolnay/rust-toolchain@stable

Swatinem/rust-cache@v2

Java:
```
actions/setup-java@v4
```
，带
```
cache:
```
参数

矩阵构建中使用
```
fail-fast: false
```
当
```
WANT_COVERAGE
```
为真时，上传覆盖率作为工件

矩阵构建（当

WANT_MATRIX

为真时）：

仅

tests

任务使用矩阵。代码检查/静态分析任务仅在最新版本上运行。

yaml

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

合并代码检查任务：

若项目同时使用同一生态系统的格式化工具和代码检查器，将它们合并为一个任务：

PHP:
```
php-cs-fixer
```
检查 + 其他代码检查 ->
```
code-style
```
任务
Node.js:
```
eslint
```
+
```
prettier
```
->
```
lint
```
任务。Biome可替代ESLint和Prettier — 若检测到Biome，仅在单个
```
lint
```
任务中使用
```
npx biome check .
```
Python:
```
ruff check
```
+
```
ruff format --check
```
->
```
lint
```
任务（Ruff同时处理两者）
Rust:
```
cargo fmt
```
+
```
cargo clippy
```
-> 可分开（fmt速度快，clippy需要编译）

请勿合并代码检查/静态分析与测试任务 — 它们应独立失败并提供清晰反馈。

使用

templates/github/

和

templates/gitlab/

中的模板作为生成工作流文件的基础。遵循上述头部模式（名称、触发器、并发、权限）和按文件组织任务的规则。

4.2 GitLab CI Generation

4.2 GitLab CI生成

Output file:

.gitlab-ci.yml

For GitLab-specific pipeline structure, cache strategy, report format integration, and language-specific patterns → read

references/GITLAB-PATTERNS.md

Pipeline stages: install → lint → test → build → security

输出文件：

.gitlab-ci.yml

GitLab特定的流水线结构、缓存策略、报告格式集成和语言特定模式 → 阅读

references/GITLAB-PATTERNS.md

流水线阶段：install → lint → test → build → security

4.3 Service Containers

4.3 服务容器

services_needed

is not empty, add service containers to the test job. For GitHub Actions and GitLab CI service container syntax → read

references/SERVICE-CONTAINERS.md

若

services_needed

不为空，在测试任务中添加服务容器。GitHub Actions和GitLab CI的服务容器语法 → 阅读

references/SERVICE-CONTAINERS.md

Quality Checks (Before Writing)

质量检查（写入前）

Verify generated pipeline before writing:

Correctness:

Every job has checkout/setup/install steps
Cache is configured for the correct lock file
All commands match tools actually present in the project
Matrix versions match the project's version constraints
Service containers have health checks

Best practices:

```
concurrency
```
group set (GitHub Actions)
```
permissions: contents: read
```
set (GitHub Actions)
```
interruptible: true
```
set (GitLab CI)
```
workflow.rules
```
defined (GitLab CI)
Jobs are parallel where possible (no unnecessary
```
needs
```
)
```
fail-fast: false
```
on matrix builds

No over-engineering:

No jobs for tools not present in the project
No matrix builds if the project only targets one version
No security scanning unless requested or tools are installed
No build job if the project has no build step

写入前验证生成的流水线：

正确性：

每个任务都有检出/初始化/安装步骤
缓存针对正确的锁定文件配置
所有命令与项目中实际存在的工具匹配
矩阵版本与项目的版本约束匹配
服务容器包含健康检查

最佳实践：

设置了
```
concurrency
```
组（GitHub Actions）
设置了
```
permissions: contents: read
```
（GitHub Actions）
设置了
```
interruptible: true
```
（GitLab CI）
定义了
```
workflow.rules
```
（GitLab CI）
任务尽可能并行执行（无不必要的
```
needs
```
依赖）
矩阵构建中设置了
```
fail-fast: false
```

避免过度设计：

不为项目中不存在的工具创建任务
若项目仅针对一个版本，不使用矩阵构建
除非用户请求或已安装工具，否则不添加安全扫描
若项目无构建步骤，不创建构建任务

Step 5: Enhance / Audit Existing Pipeline

步骤5：增强/审核现有流水线

When

MODE = "enhance"

MODE = "audit"

, analyze

EXISTING_CONTENT

against the project profile and best practices.

当

MODE = "enhance"

或

MODE = "audit"

时，对照项目配置文件和最佳实践分析

EXISTING_CONTENT

。

5.1 Gap Analysis

5.1 差距分析

Compare existing pipeline against

PROJECT_PROFILE

Missing jobs:

Linter installed but no lint job in CI?
SA tool installed but no SA job?
Tests exist but no test job?
Security tools installed but no security job?

Configuration issues:

No caching configured?
No concurrency group (GitHub Actions)?
Using deprecated actions (e.g.,
```
actions-rs
```
instead of
```
dtolnay/rust-toolchain
```
)?
Hardcoded language versions instead of variable/matrix?
Missing
```
fail-fast: false
```
on matrix?
Using
```
policy: pull-push
```
on all GitLab jobs instead of
```
pull
```
on non-install jobs?

Missing features:

No coverage reporting when coverage tools are available?
No JUnit/codequality report integration (GitLab)?
No path filtering for monorepos?
No
```
workflow_dispatch
```
trigger (GitHub Actions)?

将现有流水线与

PROJECT_PROFILE

对比：

缺失任务：

已安装代码检查器但CI中无代码检查任务？
已安装静态分析工具但CI中无静态分析任务？
存在测试但CI中无测试任务？
已安装安全工具但CI中无安全任务？

配置问题：

未配置缓存？
无并发组（GitHub Actions）？
使用已弃用的Action（例如用
```
actions-rs
```
而非
```
dtolnay/rust-toolchain
```
）？
硬编码语言版本而非使用变量/矩阵？
矩阵构建中缺失
```
fail-fast: false
```
？
GitLab所有任务使用
```
policy: pull-push
```
而非非安装任务使用
```
pull
```
？

缺失功能：

有覆盖率工具但无覆盖率报告？
无JUnit/codequality报告集成（GitLab）？
无单体仓库的路径过滤？
无
```
workflow_dispatch
```
触发器（GitHub Actions）？

5.2 Audit Report & Fix

5.2 审核报告与修复

For audit report format, fix flow options, and display templates → read

references/AUDIT-REPORT.md

Present results as tables with ✅/❌/⚠️ per check. Categorize recommendations by severity (CRITICAL, HIGH, MEDIUM, LOW). Ask user to choose: fix all, fix critical only, or show details first.

If fixing: preserve existing structure, job names, and ordering conventions.

审核报告格式、修复流程选项和展示模板 → 阅读

references/AUDIT-REPORT.md

以表格形式展示结果，每项检查标记✅/❌/⚠️。按严重性（CRITICAL、HIGH、MEDIUM、LOW）分类建议。询问用户选择：修复全部、仅修复严重问题，或先查看详情。

修复时： 保留现有结构、任务名称和排序约定。

Step 6: Write Files

步骤6：写入文件

6.1 Generate Mode — Write Pipeline

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

Only create files for detected concerns. If only lint + tests — two files. If the project is trivially small (single lint + single test job) — a single

ci.yml

is acceptable.

GitLab CI:

Write .gitlab-ci.yml

GitLab CI uses a single

.gitlab-ci.yml

— stages and DAG (

needs:

) handle separation.

GitHub Actions：

Bash: mkdir -p .github/workflows
Write .github/workflows/lint.yml        # 若检测到代码检查器/静态分析工具
Write .github/workflows/tests.yml       # 始终写入
Write .github/workflows/build.yml       # 若has_build_step为真
Write .github/workflows/security.yml    # 若WANT_SECURITY为真

仅为检测到的关注点创建文件。若仅需代码检查 + 测试 — 创建两个文件。若项目极小（单个代码检查 + 单个测试任务） — 可使用单个

ci.yml

文件。

GitLab CI：

Write .gitlab-ci.yml

GitLab CI使用单个

.gitlab-ci.yml

文件 — 通过阶段和DAG（

needs:

）实现任务分离。

6.2 Enhance / Audit Mode — Update Existing

6.2 增强/审核模式 — 更新现有文件

Edit existing files using the

Edit

tool. Preserve the original structure and only add/modify what's needed.

使用

Edit

工具编辑现有文件。保留原始结构，仅添加/修改必要内容。

Step 7: Summary & Follow-Up

步骤7：总结与后续建议

7.1 Display Summary

7.1 展示总结

Display summary using format from

references/AUDIT-REPORT.md

(Summary Display Template section). Show platform, files created, features, and quick start commands.

使用

references/AUDIT-REPORT.md

中的格式（总结展示模板部分）展示总结。显示平台、创建的文件、功能和快速开始命令。

7.2 Suggest Follow-Up Skills

7.2 建议后续技能

Suggest:

/aif-build-automation

for CI targets in Makefile/Taskfile,

/aif-dockerize

for containerization.

建议：

/aif-build-automation

用于Makefile/Taskfile中的CI目标，

/aif-dockerize

用于容器化。

Artifact Ownership and Config Policy

工件所有权与配置策略

Primary ownership: CI pipeline artifacts such as
```
.github/workflows/*
```
and
```
.gitlab-ci.yml
```
.
Allowed companion updates: none by default outside CI files.
Config policy: config-agnostic by design. This skill relies on repository detection and explicit user choices, not
```
config.yaml
```
.

主要所有权：CI流水线工件，如
```
.github/workflows/*
```
和
```
.gitlab-ci.yml
```
。
允许的伴随更新：默认情况下CI文件外无其他更新。
配置策略：设计为与配置无关。本技能依赖仓库检测和用户明确选择，而非
```
config.yaml
```
。