dtsong/my-claude-setup · Archived

cicd-generation

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'.

First seen Mar 10, 2026

Installation

$ npx skills add dtsong/my-claude-setup --skill cicd-generation

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from dtsong/my-claude-setup · top by installs.

npx skills add dtsong/my-claude-setup

Browse all from dtsong/my-claude-setup

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 5
License LICENSE
Default branch main
Open issues 5
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,865 B
  • docs SUMMARY.md 271 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 2 installs

SKILL.md

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:
      - uses: actions/checkout@v4
      - name: Setup
        # Language-specific setup
      - name: Build
        run: <build-command>

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
  • GITHUBTOKEN permissions differ between pullrequest and pullrequesttarget 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.)