ci-setup

name	ci-setup
description	Generate a standalone .github/workflows/ci.yml that runs lint / typecheck / test / build on pull requests. Reads the project's package.json to assemble the right step set for the detected package manager (bun / pnpm / yarn / npm). Produces a self-contained workflow — no dependency on cc-ecosystem reusable workflows or composite actions. Triggers: "ci.yml 만들어줘", "GitHub Actions 셋업", "/ci-setup", "set up CI for this project". Do NOT use this skill for deploy/release workflows (cf-deploy, eas-deploy, etc. are separate target-specific skills).
allowed-tools	["Bash","Read","Write","AskUserQuestion"]

/ci-setup — CI Workflow Generator

Generates .github/workflows/ci.yml in the current working directory based on package.json scripts. Stand-alone — no cc-ecosystem dependency at runtime.

Out of scope: deploy / release workflows (release.yml, deploy.yml). Those live in target-specific skills (cf-deploy for Cloudflare Workers, future eas-deploy / npm-publish / docker-publish). /ci-setup only handles the PR-time quality gate.

Trigger Phrases

• "ci.yml 만들어줘"
• "GitHub Actions 셋업해줘"
• "set up CI for this project"
• "/ci-setup"

Inputs

Source	Used for
./package.json (required)	Detect scripts (lint, typecheck, test, build). Missing scripts are skipped (not an error).
./bun.lock / pnpm-lock.yaml / yarn.lock / package-lock.json	Detect package manager. Falls back to npm if none.
Node version (CLI flag)	setup-node node-version field. Default: 20. Agent should read .nvmrc if present and pass it through — see Step 4 below.

Agent Workflow

1. Detect package.json in the current directory.
   • If absent: tell the user where to invoke /ci-setup from (the project root) and stop.
2. Read scripts — note which of lint, typecheck, test, build exist.
3. Detect package manager — by lockfile presence (bun > pnpm > yarn > npm fallback).
4. Determine Node version:

   NV=$(tr -d '[:space:]v' < .nvmrc 2>/dev/null)
   [[ -z "$NV" ]] && NV=20    # fallback default; ask the user only if you want to override
   

5. Confirm overwrite if .github/workflows/ci.yml already exists (AskUserQuestion).
6. Invoke the renderer:

   python3 "${CLAUDE_PLUGIN_ROOT}/skills/ci-setup/scripts/generate_ci.py" \
     --package-json ./package.json \
     --output ./.github/workflows/ci.yml \
     --node-version "$NV"
   

7. Report which steps were included / skipped and the output path.

Output

# .github/workflows/ci.yml — pull_request trigger, runs the detected
# subset of: bun install / lint / typecheck / test / build

The generated workflow:

• Triggers on pull_request targeting main only (trunk-based)
• Installs dependencies via the detected package manager (bun install --frozen-lockfile / pnpm install --frozen-lockfile / etc.)
• Runs only the scripts present in package.json (no bun run typecheck if there is no typecheck script)
• Caches the package manager's store via actions/setup-node's built-in cache (or oven-sh/setup-bun@v2 for bun)
• Uses ubuntu-latest runner

What the renderer rejects

• package.json not parseable → exit 1 with a [REJECT] line on stderr
• package.json scripts field is not an object
• package.json has none of lint, typecheck, test, build scripts — the agent should suggest adding at least one (typically test) before retry
• --output path collides with an existing file unless --force is passed
• --node-version is not a numeric form like 20 or 20.18.0
• Unknown CLI flags

Reference Documents

• references/template-notes.md — design decisions for the generated workflow (why pull_request only, why no concurrency cancellation by default, etc.)