cicd-generation
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@refformat — reject shell metacharacters and null bytes - Secret names: uppercase alphanumeric and underscores only
Core Principles
- Fail-fast: Quick checks (lint, type) before slow ops (build, test)
- Security hardening: OIDC auth, minimal permissions, pinned action versions
- Caching: Based on detected package manager
- Matrix testing: When multiple versions/platforms needed
- 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
@v4action references are mutable tags — a compromised action repo can push new code to the same tag. Pin to full SHA for security-critical workflowspermissions: write-allgrants the workflow token access to everything — always use minimal, explicit permissions per jobcontinue-on-error: truehides real failures in CI — only use for explicitly optional steps with a comment explaining whyactions/checkoutwith defaultfetch-depth: 1breaksgit log,git diff, and changelog generation — usefetch-depth: 0for full history- Caching
node_modulesinstead of the npm/yarn cache leads to stale dependencies — cache the package manager cache, not installed packages GITHUB_TOKENpermissions differ betweenpull_requestandpull_request_targetevents — the latter runs with base branch permissions (security risk for fork PRs)
Anti-patterns to Avoid
@latestor@v4without SHA pinning for security-critical workflowspermissions: write-all- Storing secrets in workflow files
- Running all jobs in parallel when dependencies exist
- Missing caching for package managers
continue-on-error: truehiding real failures
Output Format
When generating a workflow, output:
- Analysis summary: What was detected in repo
- Workflow file(s): Full YAML content
- File path: Where to save (
.github/workflows/<name>.yml) - Setup notes: Any required secrets or configuration
- Verification: Command to test workflow locally (act, etc.)
More from dtsong/my-claude-setup
web-security-hardening
Security audit checklist for web applications. Use when reviewing, auditing, or hardening a web app's security posture. Covers rate limiting, auth headers, IP blocking, CORS, security middleware, input validation, file upload limits, ORM usage, and password hashing. Triggers on requests like "review security", "harden this app", "security audit", "check for vulnerabilities", or when building/reviewing API endpoints.
26web-design-guidelines
Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
8soc-security-skills
>
6tdd
>
3vercel-react-best-practices
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
3workflow
Use when planning implementation steps, deciding commit format, or structuring development approach. Provides brainstorm-plan-implement flow with conventional commits. Triggers on 'how should I approach this', 'commit format'.
2