ci-cd-pipeline-builder
SKILL.md
CI/CD Pipeline Builder
Tier: POWERFUL Category: Engineering / DevOps Maintainer: Claude Skills Team
Overview
Generate production-grade CI/CD pipelines from detected project stack signals. Analyzes lockfiles, manifests, and scripts to produce optimized pipelines with proper caching, matrix strategies, security scanning, and deployment gates. Supports GitHub Actions, GitLab CI, CircleCI, and Buildkite with deployment strategies including blue-green, canary, and rolling updates.
Keywords
CI/CD, GitHub Actions, GitLab CI, pipeline, deployment, caching, matrix builds, blue-green deployment, canary deployment, security scanning, SAST, container builds, environment gates
Core Capabilities
1. Stack Detection
- Language/runtime detection from lockfiles and manifests
- Package manager inference from lock file format
- Build/test/lint command extraction from scripts
- Framework detection (Next.js, FastAPI, Go modules, etc.)
- Infrastructure detection (Docker, Kubernetes, Terraform)
2. Pipeline Generation
- Lint, test, build, deploy stages with correct dependencies
- Caching strategies matched to package manager
- Matrix builds for multi-version support
- Artifact passing between jobs
- Conditional execution (path filters, branch rules)
3. Deployment Strategies
- Blue-green with instant rollback
- Canary with percentage-based traffic shifting
- Rolling updates with health checks
- Feature flags integration
- Manual approval gates for production
4. Security Integration
- SAST scanning (CodeQL, Semgrep, Snyk)
- Dependency vulnerability scanning
- Container image scanning (Trivy, Grype)
- Secret scanning in CI
- SBOM generation
When to Use
- Bootstrapping CI/CD for a new repository
- Migrating between CI platforms
- Optimizing slow or flaky pipelines
- Adding deployment stages to an existing CI-only pipeline
- Implementing security scanning in the pipeline
- Setting up multi-environment deployment (staging, production)
Stack Detection Heuristics
File Found → Inference
─────────────────────────────────────────────────
package-lock.json → Node.js + npm
pnpm-lock.yaml → Node.js + pnpm
yarn.lock → Node.js + yarn
bun.lockb → Bun
requirements.txt / Pipfile → Python + pip/pipenv
pyproject.toml + uv.lock → Python + uv
poetry.lock → Python + poetry
go.mod → Go
Cargo.lock → Rust
Gemfile.lock → Ruby
composer.lock → PHP
next.config.* → Next.js (Node.js)
nuxt.config.* → Nuxt (Node.js)
Dockerfile → Container build needed
docker-compose.yml → Multi-service setup
terraform/*.tf → Infrastructure as Code
k8s/ or kubernetes/ → Kubernetes deployment
GitHub Actions Pipeline Templates
Node.js (pnpm + Vitest + Next.js)
name: CI/CD
on:
push:
branches: [main, dev]
pull_request:
branches: [main, dev]
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
env:
NODE_VERSION: '20'
PNPM_VERSION: '9'
jobs:
lint-and-typecheck:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v4
with:
version: ${{ env.PNPM_VERSION }}
- uses: actions/setup-node@v4
with:
node-version: ${{ env.NODE_VERSION }}
cache: 'pnpm'
- run: pnpm install --frozen-lockfile
- run: pnpm lint
- run: pnpm typecheck
test:
runs-on: ubuntu-latest
needs: lint-and-typecheck
services:
postgres:
image: postgres:16
env:
POSTGRES_USER: test
POSTGRES_PASSWORD: test
POSTGRES_DB: testdb
ports: ['5432:5432']
options: >-
--health-cmd pg_isready
--health-interval 10s
--health-timeout 5s
--health-retries 5
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v4
with:
version: ${{ env.PNPM_VERSION }}
- uses: actions/setup-node@v4
with:
node-version: ${{ env.NODE_VERSION }}
cache: 'pnpm'
- run: pnpm install --frozen-lockfile
- run: pnpm test:ci
env:
DATABASE_URL: postgresql://test:test@localhost:5432/testdb
build:
runs-on: ubuntu-latest
needs: test
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v4
with:
version: ${{ env.PNPM_VERSION }}
- uses: actions/setup-node@v4
with:
node-version: ${{ env.NODE_VERSION }}
cache: 'pnpm'
- run: pnpm install --frozen-lockfile
- run: pnpm build
- uses: actions/upload-artifact@v4
with:
name: build-output
path: .next/
retention-days: 1
security-scan:
runs-on: ubuntu-latest
permissions:
security-events: write
steps:
- uses: actions/checkout@v4
- uses: github/codeql-action/init@v3
with:
languages: javascript-typescript
- uses: github/codeql-action/analyze@v3
deploy-staging:
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
needs: [build, security-scan]
runs-on: ubuntu-latest
environment:
name: staging
url: https://staging.myapp.com
steps:
- uses: actions/checkout@v4
- uses: actions/download-artifact@v4
with:
name: build-output
path: .next/
- name: Deploy to staging
run: |
# Replace with your deployment command
echo "Deploying to staging..."
env:
DEPLOY_TOKEN: ${{ secrets.STAGING_DEPLOY_TOKEN }}
deploy-production:
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
needs: deploy-staging
runs-on: ubuntu-latest
environment:
name: production
url: https://myapp.com
steps:
- uses: actions/checkout@v4
- uses: actions/download-artifact@v4
with:
name: build-output
path: .next/
- name: Deploy to production
run: |
echo "Deploying to production..."
env:
DEPLOY_TOKEN: ${{ secrets.PROD_DEPLOY_TOKEN }}
Python (uv + pytest + FastAPI)
name: CI/CD
on:
push:
branches: [main]
pull_request:
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: astral-sh/setup-uv@v4
- run: uv sync --frozen
- run: uv run ruff check .
- run: uv run ruff format --check .
- run: uv run mypy src/
test:
runs-on: ubuntu-latest
needs: lint
strategy:
matrix:
python-version: ['3.11', '3.12', '3.13']
services:
postgres:
image: postgres:16
env:
POSTGRES_USER: test
POSTGRES_PASSWORD: test
POSTGRES_DB: testdb
ports: ['5432:5432']
options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
steps:
- uses: actions/checkout@v4
- uses: astral-sh/setup-uv@v4
with:
python-version: ${{ matrix.python-version }}
- run: uv sync --frozen
- run: uv run pytest --cov --cov-report=xml -v
env:
DATABASE_URL: postgresql://test:test@localhost:5432/testdb
- uses: codecov/codecov-action@v4
if: matrix.python-version == '3.12'
with:
file: coverage.xml
build-container:
needs: test
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
steps:
- uses: actions/checkout@v4
- uses: docker/setup-buildx-action@v3
- uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- uses: docker/build-push-action@v6
with:
context: .
push: ${{ github.ref == 'refs/heads/main' }}
tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
cache-from: type=gha
cache-to: type=gha,mode=max
container-scan:
needs: build-container
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: aquasecurity/trivy-action@master
with:
image-ref: ghcr.io/${{ github.repository }}:${{ github.sha }}
severity: 'CRITICAL,HIGH'
exit-code: '1'
Deployment Strategy Decision Framework
How critical is zero-downtime?
│
├─ Critical (payment processing, real-time systems)
│ └─ BLUE-GREEN DEPLOYMENT
│ Pro: Instant rollback, zero-downtime guaranteed
│ Con: Requires 2x infrastructure during deployment
│
├─ Important but can tolerate brief errors
│ ├─ Need to validate with real traffic first?
│ │ └─ CANARY DEPLOYMENT
│ │ Pro: Test with small % of traffic before full rollout
│ │ Con: Complex routing, need observability for canary metrics
│ │
│ └─ Standard web app with health checks
│ └─ ROLLING UPDATE
│ Pro: Simple, built into K8s/ECS, gradual rollout
│ Con: Both versions serve traffic during rollout
│
└─ Development/staging environment
└─ RECREATE (stop old, start new)
Pro: Simplest, cleanest
Con: Brief downtime during deployment
Caching Strategy Reference
| Package Manager | Cache Path | Key Pattern |
|---|---|---|
| npm | ~/.npm |
${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }} |
| pnpm | Detected by setup-node | cache: 'pnpm' in setup-node |
| yarn | ~/.cache/yarn |
${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }} |
| pip | ~/.cache/pip |
${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }} |
| uv | ~/.cache/uv |
Handled by setup-uv |
| Go | ~/go/pkg/mod |
${{ runner.os }}-go-${{ hashFiles('go.sum') }} |
| Cargo | ~/.cargo/registry |
${{ runner.os }}-cargo-${{ hashFiles('Cargo.lock') }} |
| Docker | GHA cache | cache-from: type=gha in build-push-action |
Pipeline Optimization Techniques
1. Path Filtering (Skip Unnecessary Runs)
on:
push:
paths:
- 'src/**'
- 'tests/**'
- 'package.json'
- 'pnpm-lock.yaml'
paths-ignore:
- '**.md'
- 'docs/**'
- '.github/ISSUE_TEMPLATE/**'
2. Job Dependency Graph
lint ──────┐
├──→ test ──→ build ──→ deploy-staging ──→ deploy-production
typecheck ─┘ │
└──→ security-scan
3. Matrix Strategy with Fail-Fast
strategy:
fail-fast: true # cancel all if one fails
matrix:
node-version: [18, 20, 22]
os: [ubuntu-latest]
include:
- node-version: 20
os: macos-latest # test one combo on macOS
GitLab CI Equivalent
stages:
- validate
- test
- build
- deploy
variables:
NODE_VERSION: "20"
.node-setup: &node-setup
image: node:${NODE_VERSION}
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
- .pnpm-store/
before_script:
- corepack enable
- pnpm install --frozen-lockfile
lint:
stage: validate
<<: *node-setup
script:
- pnpm lint
- pnpm typecheck
test:
stage: test
<<: *node-setup
services:
- postgres:16
variables:
POSTGRES_DB: testdb
POSTGRES_USER: test
POSTGRES_PASSWORD: test
DATABASE_URL: postgresql://test:test@postgres:5432/testdb
script:
- pnpm test:ci
coverage: '/All files[^|]*\|[^|]*\s+([\d\.]+)/'
build:
stage: build
<<: *node-setup
script:
- pnpm build
artifacts:
paths:
- .next/
expire_in: 1 hour
deploy_staging:
stage: deploy
environment:
name: staging
url: https://staging.myapp.com
rules:
- if: $CI_COMMIT_BRANCH == "main"
script:
- echo "Deploy to staging"
deploy_production:
stage: deploy
environment:
name: production
url: https://myapp.com
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual
needs: [deploy_staging]
script:
- echo "Deploy to production"
Validation Checklist
Before merging a generated pipeline:
- YAML parses without syntax errors
- All referenced commands exist in the repository (
test,lint,build) - Cache strategy matches the detected package manager
- Required secrets are documented (not embedded in YAML)
- Branch protection rules match organization policy
- Deployment jobs are gated by protected environments
- Security scanning runs on the appropriate code paths
- Artifact retention is set (do not keep build artifacts indefinitely)
- Concurrency group prevents duplicate runs on the same branch
- Path filters exclude documentation-only changes from full CI runs
Common Pitfalls
- Copying pipelines between projects without adapting to the actual stack
- No concurrency control leading to redundant parallel runs on rapid pushes
- Missing cache keys causing cache misses on every run (slow builds)
- Running full matrix on every PR when only main needs multi-version testing
- Hardcoding secrets in YAML instead of using CI secret stores
- No path filtering so documentation changes trigger full build+test+deploy
- Deploy jobs without environment gates allowing accidental production deployments
- No artifact retention policy causing storage costs to grow indefinitely
Best Practices
- Detect stack first, then generate pipeline — never guess at build commands
- Keep the generated baseline under version control and customize incrementally
- One optimization at a time — add caching, then matrix, then split jobs
- Require green CI before any deployment job can execute
- Use protected environments for production credentials and manual approval gates
- Track pipeline duration and flakiness as first-class engineering metrics
- Separate deploy jobs from CI jobs to keep feedback fast for developers
- Regenerate the pipeline when the stack changes significantly (new language, new framework)
Weekly Installs
8
Repository
borghei/claude-skillsGitHub Stars
38
First Seen
6 days ago
Security Audits
Installed on
gemini-cli8
github-copilot8
amp8
cline8
codex8
kimi-cli8