CI/CD Generator

Generate production-grade GitHub Actions workflows by analyzing the current project structure. Supports any stack, any deploy target.

Step 1: Detect Project Stack

Read the project root and identify what exists. Run these checks in parallel:

CODEBLOCK0

Build a detection summary:

Read package.json to extract:

• - Package manager (packageManager field, or check for pnpm-lock.yaml, yarn.lock, bun.lockb, package-lock.json)
• Scripts available (lint, test, build, typecheck, format)
• Node version requirements (engines.node)
• Framework and key dependencies

For Python, read pyproject.toml or requirements.txt to determine Python version and test framework (pytest, unittest).

Step 2: Ask the User

Present the detection results and ask:

1. 1. Deploy target (if not obvious from vercel.json/railway.toml):

1. 2. Environments: Preview on PR + Production on main? Or just main?

1. 3. Matrix testing: Test across multiple runtime versions? (e.g., Node 20 + 22, Python 3.11 + 3.12)

1. 4. Additional checks: Security scanning? Dependency audit? Coverage reporting?

Step 3: Generate Workflows

Create .github/workflows/ directory and generate the appropriate workflow files.

Action Versions Reference (current as of 2026)

Always use these versions:

CODEBLOCK1

3A: Node.js / Next.js / Frontend Projects

File: INLINECODE30

CODEBLOCK2

Package manager install commands:

• - npm: INLINECODE31
• pnpm: INLINECODE32
• yarn: INLINECODE33
• bun: INLINECODE34

Cache key for setup-node:

• - npm: INLINECODE35
• pnpm: INLINECODE36
• yarn: INLINECODE37

For pnpm, add the corepack enable step before install:
CODEBLOCK3

If the project has no test script, omit the test job. If no lint script, omit lint. Same for typecheck. Always keep build.

3B: Python Projects

File: INLINECODE40

CODEBLOCK4

For pyproject.toml projects, replace pip install -r requirements.txt with pip install -e ".[dev]" or the appropriate extras.

For poetry projects:
CODEBLOCK5

3C: Docker Projects

File: INLINECODE43

CODEBLOCK6

For Docker Hub instead of GHCR:
CODEBLOCK7

For ECR:
CODEBLOCK8

3D: Monorepo Projects

For monorepos (Turborepo, pnpm workspaces, Nx), add path filters to avoid running everything on every change:

CODEBLOCK9

Adapt the app names and filter paths based on the actual monorepo structure. Read pnpm-workspace.yaml or turbo.json to discover workspace packages.

For Turborepo specifically, leverage turbo run:
CODEBLOCK10

Step 4: Generate Deploy Workflows

Vercel Deploy

If deploying via Vercel CLI (not git-push auto-deploy):

File: INLINECODE47

CODEBLOCK11

Required secrets: VERCEL_TOKEN, VERCEL_ORG_ID, INLINECODE50

If the project uses Vercel's git integration (auto-deploy on push), skip this workflow and tell the user -- CI workflow alone is sufficient since Vercel handles deploys automatically.

Railway Deploy

File: INLINECODE51

CODEBLOCK12

Required secrets: INLINECODE52

If Railway auto-deploys from GitHub, tell the user to enable "Wait for CI" in Railway service settings so it waits for the CI workflow to pass before deploying.

VPS via SSH

File: INLINECODE53

CODEBLOCK13

For rsync-based deploys (push built artifacts):
CODEBLOCK14

Required secrets: VPS_HOST, VPS_USER, VPS_SSH_KEY, INLINECODE57

Docker Registry Deploy

Use the Docker workflow from Step 3C. If deploying to a server after push, add a post-push job:

CODEBLOCK15

Step 5: Secrets Checklist

After generating workflows, output a checklist of secrets the user needs to configure in GitHub repo settings (Settings > Secrets and variables > Actions):

CODEBLOCK16

Only list secrets relevant to the chosen deploy target.

Step 6: Status Badge

Offer to add a CI status badge to the project README:

CODEBLOCK17

Read the git remote to determine OWNER/REPO automatically:
CODEBLOCK18

Rules

1. 1. Never hardcode secrets. Always use ${{ secrets.NAME }} references.
2. Always use concurrency groups to cancel redundant runs on the same branch/PR.
3. Always pin action versions to major tags (e.g., @v6), never @latest or @main.
4. Use fail-fast: false in matrix builds so one version failing doesn't cancel others.
5. Separate CI from deploy. CI runs on PRs and pushes. Deploy only runs on main (or tags).
6. Use GitHub Environments for production deploys to enable approval gates and env-specific secrets.
7. Cache aggressively. Use setup-node/setup-python built-in cache for dependencies. Use GHA cache for Docker layers.
8. Run lint/typecheck/test in parallel as separate jobs for faster feedback. Build depends on all passing.
9. For monorepos, always add path filters. Never run all workspace CI on every file change.
10. If workflows already exist (.github/workflows/ is non-empty), read them first and ask the user whether to replace or extend.
11. Replace placeholder values (NODEVERSION, PACKAGEMANAGER, etc.) with actual detected values from the project. Never leave placeholders in the generated output.
12. Only include jobs that the project supports. If there is no test script, no test job. If there is no lint script, no lint job. Don't generate dead jobs.