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:

If $ARGUMENTS contains github -> set PLATFORM = "github" If $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:

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.

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

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