---
name: devops-pipeline-forge
description: "Scaffold GitHub Actions, Dockerfiles, and Terraform for production deploys. Writes a full CI/CD pipeline for your stack, generates Dockerfiles, and produces Terraform for AWS/GCP/Vercel."
license: MIT
---

# 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

```bash
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.