CI — Pipeline Configuration Generator

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

Step 0: Load Project Context

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.

Step 1: Detect Existing CI & Determine Mode

1.1 Scan for Existing CI Configuration

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

1.2 Determine Mode

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."

1.3 Interactive Setup (Generate Mode Only)

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

1.4 Read Existing Files (Enhance / Audit Modes)

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.

Step 2: Deep Project Analysis

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

2.1 Language & Runtime

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)

2.2 Language Version

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.

2.3 Package Manager & Lock File

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

2.4–2.7 Tool Detection

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).

2.8 Services Detection

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.

2.9 Build Output

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	—

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/)

Step 3: Read Best Practices & Templates

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

Step 4: Generate Pipeline (Generate Mode)

Using the

PROJECT_PROFILE

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

4.1 GitHub Actions Generation

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.

4.2 GitLab CI Generation

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

4.3 Service Containers

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

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

Step 5: Enhance / Audit Existing Pipeline

When

MODE = "enhance"

MODE = "audit"

, analyze

EXISTING_CONTENT

against the project profile and best practices.

5.1 Gap Analysis

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)?

5.2 Audit Report & Fix

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.

Step 6: Write Files

6.1 Generate Mode — Write Pipeline

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.

6.2 Enhance / Audit Mode — Update Existing

Edit existing files using the

Edit

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

Step 7: Summary & Follow-Up

7.1 Display Summary

Display summary using format from

references/AUDIT-REPORT.md

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

7.2 Suggest Follow-Up Skills

Suggest:

/aif-build-automation

for CI targets in Makefile/Taskfile,

/aif-dockerize

for containerization.

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
```
.

aif-ci

NPX Install

Tags

SKILL.md Content