DevOps Pipeline Forge

DevOps Pipeline Forge scaffolds the deployment plumbing most teams hand-write from scratch: GitHub Actions workflows, multi-stage Dockerfiles, and Terraform modules for AWS, GCP, or Vercel. It inspects your repository first—language, package manager, framework, and existing config—then generates files that match what's already there instead of dropping in a generic template. It's aimed at developers who have a working app but no reproducible path from git push to a running production service.

When to use it

• You've built an app locally and need a CI/CD pipeline before the first real deploy.
• You're containerizing a service and want a Dockerfile that actually leverages layer caching for your stack.
• You're standing up infrastructure (an ECS service, a Cloud Run instance, a Vercel project) and want it codified in Terraform rather than clicked together in a console.
• You're migrating a manual deploy to GitHub Actions with environments, secrets, and OIDC instead of long-lived keys.

How it works

The skill reads your project (package.json, pyproject.toml, go.mod, Gemfile, etc.) to detect the toolchain, then emits:

• .github/workflows/*.yml — jobs using actions/checkout, actions/setup-node / setup-python / setup-go, dependency caching via actions/cache, and a build/test/deploy split keyed on on: push and workflow_dispatch. AWS deploys are wired through aws-actions/configure-aws-credentials with OIDC role assumption (permissions: id-token: write) so no static secrets sit in the repo.
• Dockerfile — multi-stage builds (builder + slim runtime), ordered to cache dependency installs ahead of source copies, with a non-root USER and a sensible HEALTHCHECK.
• *.tf — provider blocks, a remote state backend stub (S3 + DynamoDB lock for AWS), and resources for the target: ECS/Fargate or App Runner on AWS, Cloud Run on GCP, or a vercel_project on Vercel.

Example

curl -fsSL --create-dirs -o ~/.claude/skills/devops-pipeline-forge/SKILL.md https://claudeskil.com/skills/devops-pipeline-forge/SKILL.md

# In your repo:
> Forge a CI/CD pipeline for this Node app: build + test on PRs,
> deploy to AWS ECS Fargate on merge to main, using OIDC.

It produces .github/workflows/deploy.yml, a Dockerfile, and infra/ Terraform you can terraform init && terraform plan against.

Tips & gotchas

• The OIDC path assumes a GitHub-trusted IAM role already exists. The skill emits the role's trust-policy JSON, but you must create it once in AWS before the first deploy run.
• Generated Terraform leaves the backend bucket/table as placeholders—create them out-of-band, since Terraform can't bootstrap its own state store.
• It writes .dockerignore alongside the Dockerfile; if you skip it, your build context can balloon and break layer caching.

FAQ

Does it push secrets anywhere? No. It references ${{ secrets.* }} and prefers OIDC; you populate values in GitHub repo/environment settings.

Can I target more than one cloud? Yes—ask for separate Terraform modules per provider; each gets its own directory and provider block.

Will it overwrite my existing workflow? It proposes diffs and asks before replacing files it didn't create.