Developer pack
Claude Skill
CI/CD Pipeline Architect
Designs a CI/CD pipeline from scratch — build, test, gate, deploy — matched to your team size and stack.
What it does
Takes your repo, deploy target, and team constraints, and produces a working CI/CD pipeline definition (GitHub Actions / GitLab CI / CircleCI / etc.). Covers build, test, security gates, environment promotion, rollback. Avoids the two common failures: over-engineered pipelines that no one maintains, and under-engineered ones that miss the bug that takes down prod.
When to use
- ✓New project setting up CI/CD for the first time
- ✓Existing pipeline got out of hand and you want to redesign before adding more
- ✓Migrating between CI providers and want a clean rebuild
When not to use
- ✗You have a working pipeline that just needs incremental fixes — use focused-fix instead
- ✗Team is one developer with no production deploys yet — premature
Install
Download the .zip, then unzip into your Claude skills folder.
mkdir -p ~/.claude/skills
unzip ~/Downloads/ci-cd-pipeline-architect.zip -d ~/.claude/skills/
# Restart Claude Code session.
# Skill is now available — Claude will use it when relevant.SKILL.md
SKILL.md
---
name: ci-cd-pipeline-architect
description: Use when designing or redesigning a CI/CD pipeline. Triggers on "CI/CD", "GitHub Actions", "pipeline", "deploy automation".
---
# CI/CD Pipeline Architect
The pipeline is infrastructure for trust — it's how the team knows what's safe to deploy. Two common failure modes: over-engineered (40 jobs, half flaky, nobody maintains them) or under-engineered (one big job that says "tests pass" but doesn't actually catch the bug that hits prod).
## Required inputs
1. **Repo structure + stack** — language, framework, build tool, test runner
2. **Deploy target** — Vercel / AWS / Railway / Kubernetes / on-prem
3. **Team size + cadence** — solo deploys vs. 20-person team with PR queue
4. **Environments** — dev / staging / prod, or different shape
5. **What's broken now** (if redesigning) — flaky jobs, slow builds, missed regressions
## Output
### Pipeline structure
- **On every PR:** lint, type-check, unit tests, security scan, preview deploy
- **On main:** integration tests, build, deploy to staging, smoke tests, manual prod gate (or auto if you've earned it)
- **Nightly:** dependency audit, e2e tests, security scans that take longer
### Specific jobs with rationale
For each job: what it catches, how long it takes, what to do when it fails (block PR vs. warn vs. notify).
### Gates and approvals
- Auto-promote staging → prod when smoke tests pass + N business hours since last deploy?
- Or manual approval gate? Who approves?
- Rollback path: how, by whom, in how long.
### Anti-patterns to avoid
- 30 jobs that all run on every PR
- Tests that pass in CI but fail locally (or vice versa)
- Secrets in environment variables that get logged
- Manual deploy scripts that bypass CI
## When to keep it simple
If team < 5 and deploys < daily, a 3-job pipeline (lint, test, deploy) is right. Don't add jobs preemptively. Add them when you've been burned by what they would have caught.
Example prompts
Once installed, try these prompts in Claude:
- Design a CI/CD pipeline for a Next.js + Postgres app deploying to Vercel + Railway. Team of 4. [paste repo structure]
- My GitHub Actions setup has 23 workflows and 9 of them are flaky. Help me redesign. [paste workflow list + recent failure log]