/ci

name: ci
description: "Detect/generate/debug CI pipeline config (GitHub Actions, GitLab CI). Triggers: CI setup, build pipeline, GitHub Actions config, debug CI, GitLab CI."
effort: medium
disable-model-invocation: true
argument-hint: "[platform]"
allowed-tools: Bash, Read, Write
agent: devops-implementer
context: fork
scripts:
  - scripts/ci-detect.py

/ci - CI/CD Pipeline Management

$ARGUMENTS

What This Command Does

Generate, update, or troubleshoot CI/CD pipeline configuration based on project type.

Project context

• CI config: !`cat .github/workflows/*.yml 2>/dev/null || cat .gitlab-ci.yml 2>/dev/null || echo "no-ci"`

CI Detection Script

Detect CI platform and analyze configuration:

python3 ${CLAUDE_SKILL_DIR}/scripts/ci-detect.py [directory]

Returns JSON with:

• `platform` - detected CI platform (github-actions, gitlab-ci, jenkins, bitbucket, circleci)
• `config_files[]` - CI config file paths
• `project_type` - detected project type (python, node, flutter, go, rust, php, docker)
• `jobs_found[]` - job/stage names extracted from config
• `stages_detected[]` - best-practice stages found (lint, test, build, deploy)
• `missing_stages[]` - recommended stages not yet configured
• `suggested_template` - pointer to ci-cd-patterns skill for templates

Auto-Detection

| File Found | Project Type | Pipeline | |------------|-------------|----------| | `package.json` | Node.js/TypeScript | npm ci, lint, test, build | | `pyproject.toml` / `setup.py` | Python | pip install, ruff, mypy, pytest | | `pubspec.yaml` | Flutter/Dart | dart analyze, flutter test, build | | `composer.json` | PHP | composer install, phpstan, phpunit | | `go.mod` | Go | go vet, go test, go build | | `Cargo.toml` | Rust | cargo clippy, cargo test, cargo build | | `Dockerfile` | Docker | Build and push image |

Supported Platforms

• **GitHub Actions** (default): `.github/workflows/ci.yml`
• **GitLab CI**: `.gitlab-ci.yml`

Pipeline Stages

1. **Lint** - Static analysis, formatting checks 2. **Test** - Unit tests, integration tests with coverage 3. **Build** - Compile, bundle, Docker image 4. **Deploy** (optional) - Deploy to staging/production

Usage Examples

/ci                          # Generate CI config for detected project type
/ci github-actions           # Explicitly use GitHub Actions
/ci add deploy staging       # Add deployment stage for staging
/ci fix                      # Troubleshoot failing pipeline
/ci add matrix node 18,20,22 # Add matrix testing

Reference Skill

Use `ci-cd-patterns` skill for pipeline templates and best practices.

Rules

• **MUST** detect existing CI platform before generating a new config — do not overwrite silently
• **NEVER** commit generated CI configs that embed hardcoded secrets or tokens
• **CRITICAL**: preserve existing job names and triggers unless the user explicitly asks for a restructure
• **MANDATORY**: every generated pipeline must include lint + test stages at minimum
• **MUST** collect every failing job before diagnosing — do not stop at the first red check. A pipeline usually breaks in more than one place, and reporting only the first one costs a full cycle per remaining failure

Gotchas

• GitHub Actions YAML parses `on:` as a reserved word only when unquoted. Writing `"on":` (quoted) produces a valid-looking file whose workflow **never triggers**. YAML anchors in this field also silently break.
• GitLab CI's `rules:` and `only:/except:` are mutually exclusive at the job level. Mixing them fails parse on pipeline run but not at `git push` time — test with `gitlab-ci-lint` before committing.
• `secrets.*` in GitHub Actions is undefined in workflows triggered from **forked** PRs (security boundary). Jobs that need secrets must gate on `github.event.pull_request.head.repo.full_name == github.repository` or use `pull_request_target` carefully.
• `actions/checkout@v6` defaults to `fetch-depth: 1` (shallow). Commands that need history (`git log`, `git describe`, conventional-commit tools) fail with misleading errors — set `fetch-depth: 0` for those jobs.

When NOT to Use

• For running tests locally — use `/test`
• For general CI/CD patterns and theory — use `/ci-cd-patterns` (knowledge skill)
• For deployment orchestration only — use `/deploy`
• When the project has no VCS-hosted CI platform — generate locally-runnable scripts instead