lee-to/ai-factory/aif-ci

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:

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

2.2 Language Version

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

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

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?

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:

GitLab CI:

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:

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:

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:

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

`build.yml` — build verification:

`security.yml` — security scanning: