bigeasyfreeman/skills/ci-cd-pipeline

Skill: CI/CD Pipeline Generation

Generates or updates GitHub Actions workflows and Argo CD configurations from Build Brief infrastructure tasks. Ensures new features have proper build, test, and deploy pipelines before coding begins.

---

Trigger

Activated after work-item artifacts are created. Consumes Section 8 (Infra tasks) and Section 6 (SLOs) from the brief.

Input Contract

{
  "build_brief_id": "string",
  "repo_url": "string",
  "branch_strategy": "trunk | gitflow | feature_branch",
  "infra_tasks": [
    {
      "task_id": "string",
      "task_description": "string",
      "acceptance_criteria": ["string"],
      "service_name": "string",
      "deployment_target": "kubernetes | lambda | ecs | static"
    }
  ],
  "slo_targets": {
    "availability": "string",
    "latency_p99": "string",
    "error_rate": "string"
  },
  "environments": ["dev", "staging", "production"],
  "existing_pipelines": "auto-detect | path/to/workflows"
}

Output Contract

{
  "github_actions": [
    {
      "file_path": ".github/workflows/feature-name-ci.yml",
      "content": "string (YAML)",
      "type": "ci | cd | scheduled | manual"
    }
  ],
  "argo_configs": [
    {
      "file_path": "argo/applications/feature-name.yml",
      "content": "string (YAML)",
      "type": "application | rollout | analysis_template"
    }
  ],
  "summary": "string"
}

Behavior

1. Detect Existing Pipeline Patterns

Before generating anything, analyze the repo:

# Find existing GHA workflows
find .github/workflows -name "*.yml" -o -name "*.yaml" 2>/dev/null

# Find Argo configs
find . -path "*/argo/*" -name "*.yml" -o -path "*/argocd/*" -name "*.yaml" 2>/dev/null

# Find Dockerfile and build configs
find . -name "Dockerfile*" -o -name "docker-compose*" -o -name "Makefile"

# Find Helm charts
find . -path "*/charts/*" -o -path "*/helm/*" -name "*.yaml"

# Find existing test commands
grep -r "test" package.json Makefile pyproject.toml build.sbt 2>/dev/null | head -10

2. Generate GitHub Actions Workflows

CI Workflow (always generated)

Must include:

• Trigger on PR to target branch
• Checkout + dependency install
• Lint (using repo's existing linter config)
• Type check (if applicable)
• Unit tests
• Integration tests (if test fixtures were generated by QA skill)
• Build artifact
• Security scan (if snyk, trivy, or similar found in repo)

CD Workflow (if deployment target specified)

Must include:

• Trigger on merge to main/release branch
• Build + push container image (if Dockerfile exists)
• Environment-specific deployment steps
• Smoke test post-deploy
• Rollback trigger (manual or automatic based on SLO targets)

Workflow rules:

• Reuse existing workflow patterns from the repo (don't invent new conventions)
• Use existing secret names found in other workflows
• Match existing runner labels (runs-on)
• Follow existing naming conventions for workflow files
• Include concurrency groups to prevent duplicate runs

3. Generate Argo CD Configs

Application manifest (if Argo detected in repo)

• Reference existing Argo project and destination cluster
• Match existing sync policy patterns
• Include health checks aligned with SLO targets
• Configure automated sync for non-production, manual for production

Argo Rollout (if progressive delivery needed)

• Canary or blue-green based on existing patterns in repo
• Analysis template that checks SLO metrics
• Automatic rollback if error budget burns during rollout
• Match existing rollout configurations

4. Generate Rollback Configuration

Based on Section 4 (Risk) of the brief:

• If rollback is feature flag: generate flag toggle in deploy pipeline
• If rollback is revert: generate revert workflow
• If rollback is migration: generate migration rollback step
• If rollback is non-trivial: generate manual rollback runbook trigger

5. Wire SLO Checks into Pipeline

From Section 6 (SLOs):

• Add post-deploy verification step that checks baseline metrics
• If Argo: create AnalysisTemplate that queries metrics backend
• Add alerting webhook on deploy failure
• Include error budget check before allowing production deploy

MCP Server Contract

Tool: generate_pipeline

{
  "name": "generate_pipeline",
  "description": "Generate CI/CD pipeline configs from Build Brief infra tasks",
  "inputSchema": {
    "type": "object",
    "properties": {
      "build_brief_section": {
        "type": "string",
        "description": "Infra section (Section 8) + SLO section (Section 6) as markdown"
      },
      "repo_path": {
        "type": "string",
        "description": "Path to the repository root"
      },
      "output_directory": {
        "type": "string",
        "description": "Where to write generated pipeline files (default: repo root)"
      },
      "dry_run": {
        "type": "boolean",
        "default": true,
        "description": "If true, output configs without writing files"
      }
    },
    "required": ["build_brief_section", "repo_path"]
  }
}

Tool: validate_pipeline

{
  "name": "validate_pipeline",
  "description": "Validate generated pipeline configs against repo conventions and syntax",
  "inputSchema": {
    "type": "object",
    "properties": {
      "pipeline_path": {
        "type": "string",
        "description": "Path to generated pipeline file"
      },
      "repo_path": {
        "type": "string",
        "description": "Path to repository root for context"
      }
    },
    "required": ["pipeline_path", "repo_path"]
  }
}

CLI Interface

# Generate pipelines from build brief
adlc-pipeline generate --brief ./build-brief.md --repo ./my-repo --dry-run

# Apply generated pipelines to repo
adlc-pipeline apply --brief ./build-brief.md --repo ./my-repo

# Validate existing pipeline against brief SLOs
adlc-pipeline validate --pipeline .github/workflows/ci.yml --repo ./my-repo

Quality Gates

• [ ] CI workflow triggers on correct branches
• [ ] All test steps match commands found in repo
• [ ] Existing secrets and runner labels are reused
• [ ] Rollback mechanism matches the brief's rollback plan
• [ ] SLO checks are wired into post-deploy verification
• [ ] Production deploys require manual approval (human gate)
• [ ] Workflow YAML passes actionlint or equivalent
• [ ] Argo configs pass argocd app diff --local validation

Framework Hardening Addendum

• Contract versioning: Pipeline generation contracts include contract_version and compatibility checks.
• Schema validation: Validate Build Brief infra tasks and rollback settings against contract schemas before generating configs.
• Idempotency: Pipeline/scaffold generation must use idempotency keys and dedupe by target file/path so retries are safe.
• Stop reasons: Emit structured reasons for terminal failures (e.g., missing_target_repo, invalid_rollout_strategy, permission_denied).