cicd-generation

name	cicd-generation
description	Use when creating GitHub Actions workflows, adding CI/CD to a project, or reviewing pipeline security. Produces fail-fast, security-hardened workflows with OIDC auth and SHA-pinned actions. Triggers on 'add CI', 'create workflow', 'github actions'.
metadata	{"author":"dtsong"}

CI/CD Generation Skill

Generate production-ready GitHub Actions workflows.

Input Sanitization

• Workflow file names: alphanumeric, hyphens, and underscores only — reject .., shell metacharacters, or null bytes
• Action references: owner/action@ref format — reject shell metacharacters and null bytes
• Secret names: uppercase alphanumeric and underscores only

Core Principles

1. Fail-fast: Quick checks (lint, type) before slow ops (build, test)
2. Security hardening: OIDC auth, minimal permissions, pinned action versions
3. Caching: Based on detected package manager
4. Matrix testing: When multiple versions/platforms needed
5. Verification-first: Examine repo before generating workflow

Process

Step 1: Analyze Repository

Before generating ANY workflow, verify:

[ ] Language/framework detected
[ ] Package manager identified (npm, yarn, pnpm, pip, poetry, go mod)
[ ] Test command exists and verified
[ ] Lint/format commands exist
[ ] Build output/artifacts identified
[ ] Deployment target identified (if applicable)

Step 2: Workflow Structure

Standard CI workflow (.github/workflows/ci.yml):

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  contents: read

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup
        # Language-specific setup
      - name: Lint
        run: <lint-command>

  test:
    runs-on: ubuntu-latest
    needs: lint  # Fail-fast: lint before test
    steps:
      - uses: actions/checkout@v4
      - name: Setup
        # Language-specific setup with caching
      - name: Test
        run: <test-command>

  build:
    runs-on: ubuntu-latest
    needs: test  # Fail-fast: test before build
    steps:
        
        
        
        
         

Step 3: Language-Specific Patterns

Node.js:

- uses: actions/setup-node@v4
  with:
    node-version: '20'
    cache: 'npm'  # or yarn, pnpm
- run: npm ci

Python:

- uses: actions/setup-python@v5
  with:
    python-version: '3.12'
    cache: 'pip'
- run: pip install -r requirements.txt

Go:

- uses: actions/setup-go@v5
  with:
    go-version: '1.22'
    cache: true

Step 4: Security Hardening

Required practices:

• Pin action versions to SHA: actions/checkout@<sha>
• Minimal permissions block at workflow and job level
• Use OIDC for cloud deployments (no long-lived secrets)
• Never echo secrets

OIDC example (AWS):

permissions:
  id-token: write
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::ACCOUNT:role/ROLE
      aws-region: us-east-1

Step 5: Matrix Testing

When multiple versions/platforms needed:

strategy:
  fail-fast: false
  matrix:
    os: [ubuntu-latest, macos-latest]
    node: [18, 20, 22]

Gotchas

• @v4 action references are mutable tags — a compromised action repo can push new code to the same tag. Pin to full SHA for security-critical workflows
• permissions: write-all grants the workflow token access to everything — always use minimal, explicit permissions per job
• continue-on-error: true hides real failures in CI — only use for explicitly optional steps with a comment explaining why
• actions/checkout with default fetch-depth: 1 breaks git log, git diff, and changelog generation — use fetch-depth: 0 for full history
• Caching node_modules instead of the npm/yarn cache leads to stale dependencies — cache the package manager cache, not installed packages
• GITHUB_TOKEN permissions differ between pull_request and pull_request_target events — the latter runs with base branch permissions (security risk for fork PRs)

Anti-patterns to Avoid

• @latest or @v4 without SHA pinning for security-critical workflows
• permissions: write-all
• Storing secrets in workflow files
• Running all jobs in parallel when dependencies exist
• Missing caching for package managers
• continue-on-error: true hiding real failures

Output Format

When generating a workflow, output:

1. Analysis summary: What was detected in repo
2. Workflow file(s): Full YAML content
3. File path: Where to save (.github/workflows/<name>.yml)
4. Setup notes: Any required secrets or configuration
5. Verification: Command to test workflow locally (act, etc.)

---

Converted and distributed by TomeVault — claim your Tome and manage your conversions.