ci cd Pipeline Architect

The Problem

You start a new Python project and need CI/CD on day one. You open the GitHub Actions docs, copy a template, and spend two hours customizing it. You miss the concurrency group, so every push triggers a full pipeline run. You forget the permissions block, so the workflow has write access to everything. You don't add dependency scanning because the docs don't explain where it fits. Three months later, you're migrating from Jenkins and the existing Jenkinsfile has stages that your new pipeline doesn't cover. You need a pipeline that matches YOUR project's actual structure, not a generic template that covers every possible stack.

What You Get

• Project structure analysis that reads your package manifests, test configs, linting setup, build tools, and deployment targets to detect your exact stack — Python (pytest/Ruff), Node.js (Jest/ESLint), Go (go test/golangci-lint), Rust (cargo test/Clippy), Java (Maven/Gradle), Ruby (RSpec/RuboCop) — and generates a pipeline tailored to what's actually in your project
• Multi-platform output generating GitHub Actions (.github/workflows/ci.yml), GitLab CI (.gitlab-ci.yml), or CircleCI (.circleci/config.yml) in native format with platform-specific best practices: actions/cache with lockfile hashes, GitLab DAG pipelines with needs:, CircleCI orbs and parallelism
• Eight-stage pipeline covering Checkout → Setup → Lint → Test → Security → Build → Artifact → Deploy — with security gates (dependency scanning, SAST, secret detection, container scanning) that block production deployment on failure
• Environment promotion strategy with auto-deploy to dev on merge to main, auto-deploy to staging with integration tests, and production deployment requiring manual approval from tagged releases only
• Dockerfile generation with multi-stage builds, non-root user, pinned base image versions, health check endpoints, and .dockerignore — following Dockerfile best practices
• Platform migration mapping for Jenkins-to-GitHub-Actions transitions: credentials → secrets mapping, agent labels → runner labels, plugins → marketplace actions, parallel stages → matrix jobs

Why This Beats Prompting It Yourself

When you ask an LLM to "write a GitHub Actions workflow for my Python project," it produces a workflow that covers linting and testing but misses dependency scanning, secret detection, concurrency control, permission scoping, and cache invalidation with lockfile hashes. It generates a single job instead of parallel jobs for lint/test/security/build. It uses actions/checkout@main instead of pinned @v4. It doesn't know whether your project uses pytest or unittest, Ruff or flake8, Poetry or pip. This skill reads your actual project configuration and generates a pipeline that matches your stack, not a generic template.

Example Session

You: "Generate a GitHub Actions pipeline for this Node.js Express API. We deploy to AWS ECS."

Agent output (.github/workflows/ci.yml):

name: CI/CD Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

permissions:
  contents: read
  packages: write

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run format:check

  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test -- --coverage
      - uses: actions/upload-artifact@v4
        with:
          name: coverage-${{ matrix.node }}
          path: coverage/

  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm audit --audit-level=high
      - uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          severity: HIGH,CRITICAL

  build:
    needs: [lint, test, security]
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/tags/')
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: us-east-1
      - run: aws ecr get-login-password | docker login --username AWS --password-stdin ${{ secrets.ECR_URL }}
      - run: docker build -t ${{ secrets.ECR_URL }}:${{ github.sha }} .
      - run: docker push ${{ secrets.ECR_URL }}:${{ github.sha }}

  deploy-staging:
    needs: [build]
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - run: aws ecs update-service --cluster staging --service api --force-new-deployment

  deploy-production:
    needs: [build]
    if: startsWith(github.ref, 'refs/tags/v')
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: aws ecs update-service --cluster production --service api --force-new-deployment

Use Cases

• Starting a new project and needing CI/CD from day one with correct configuration
• Migrating from one CI platform to another (Jenkins → GitHub Actions, CircleCI → GitLab CI)
• Adding security scanning and deployment automation to a project that only runs tests
• Setting up multi-environment promotion (dev → staging → production) with approval gates
• Generating Dockerfiles for containerized deployment with multi-stage builds

Known Limitations

Generated pipelines should be validated with platform-specific linters before deployment: actionlint for GitHub Actions, gitlab-ci-lint for GitLab CI, circleci config validate for CircleCI. The pipeline assumes a standard project layout; non-standard build systems or deployment targets may require manual customization. Cloud provider secrets (AWS_ROLE_ARN, ECR_URL, etc.) must be configured in the platform's secret store — the skill references them but does not create them.