ci-generate

Files (4)

• SKILL.md
• evals.json · evals/
• trigger-eval.json · evals/
• platform-patterns.md · references/

SKILL.md (first lines)

# CI/CD Pipeline Generator

Generate a CI/CD pipeline config for the detected project stack, covering lint, test, build, security, and (when requested) deploy. Start by parsing the arguments passed to this skill invocation (platform, `--deploy`, `--monorepo`): see Phase 0 below.

## Anti-hallucination guidelines

Pipeline configurations must always match actual project tooling. This is critical:
1. Discover before generating: never assume the project's tooling, check what it actually uses first.
2. Verify commands exist: check the project's own config (e.g. `package.json` scripts, `Makefile` targets) before referencing them.
3. Match real versions: use the actual language/runtime version pinned in the project's own config files, not a guess.
4. No phantom dependencies: only include services (Redis, PostgreSQL, etc.) confirmed in project dependencies.
5. Platform-specific syntax: each CI platform has distinct YAML structure, so never mix syntax between platforms.

## Workflow

### Phase 0: Parse Arguments

Extract configuration from the arguments passed to this skill:

```
Arguments:
- <platform>: Target CI platform (default: auto-detect from existing config)
 - "github" or "gh": GitHub Actions
 - "gitlab" or "gl": GitLab CI
 - "circle" or "circleci": CircleCI
 - "jenkins": Jenkins (Jenkinsfile)
- "--deploy <target>": Deployment target (optional)
 - "vercel", "netlify", "aws", "gcp", "azure", "docker", "k8s", "fly", "railway"
- "--monorepo": Generate matrix/path-filtered workflows
- No args: Auto-detect platform from existing CI config files, default to GitHub Actions

If no platform specified, detect from existing files:
- `.github/workflows/*.yml` → GitHub Actions
- `.gitlab-ci.yml` → GitLab CI
- `.circleci/config.yml` → CircleCI
- `Jenkinsfile` → Jenkins
- No CI config found → Default to GitHub Actions
```

### Phase 1: Project Stack Detection

Explore the codebase to discover the complete project technology stack.

### Phase 2: Research Best Practices (only if needed)

`references/platform-patterns.md` already ships current, comprehensive patterns for Node/Python/matrix/Docker/deploy across all four platforms: check it first. Only reach for WebSearch when the detected stack/platform combo isn't covered there (e.g. an unusual language or a deploy target not in the reference):

```
Use WebSearch:
- query: "[detected platform] CI/CD best practices [detected language] [current year]"

Use WebSearch:
- query: "[detected platform] security scanning pipeline [detected language] [current year]"
```

Focus on:
- Caching strategies for the detected package manager
- Recommended runner images and versions
- Security scanning tools appropriate for the language
- Deployment best practices for the target platform
- Matrix testing strategies if multiple versions needed

### Phase 3: Design Pipeline Architecture

Based on discovery and research, derive the stages from what the repo actually uses. For platform-specific triggers and syntax conventions (caching included), see [references/platform-patterns.md](references/platform-patterns.md).

The generated pipeline must meet these goals. Map each to the repo's own tooling from Phase 1; skip a goal only when the repo has nothing to satisfy it, and say so in the summary:

- Fails fast: lint and type checks run first or in parallel, and a failure there cancels the slow jobs.
- Runs the test suite the repo already uses, with its real command and any service containers (database, cache) the tests need, plus coverage if configured. Use a runtime-version matrix only if the project supports several versions.
- Builds what ships (app build, Docker image if a Dockerfile exists) and keeps the artifacts later jobs need.
- Catches vulnerable dependencies and leaked secrets, plus static-analysis findings where the language has a standard tool. Scan the container image if one is built.
- Caches dependency installs keyed on the lockfile.
- Pins third-party actions, orbs and images to a SHA or exact tag, never `latest` or a moving branch.
- Grants least-privilege permissions: a read-only token by default on GitHub Actions, widened per job only where a step needs it.
- Deploys only when `--deploy` is given or deployment config is detected: staging and production are separate, a health check follows the deploy, and the built artifact reference is threaded into the deploy step. The Build job must expose the image tag/digest it produced (job `outputs`, `GITHUB_OUTPUT`, an artifact file, etc.), and the deploy step must consume that same reference: rendering it into a task definition, `helm upgrade --set image.tag=<ref>`, `kubectl set image deployment/<name> <container>=<ref>`, or equivalent. Never emit a blind restart (`aws ecs update-service --force-new-deployment`, `kubectl rollout restart` with no image change) as the whole deploy step: if the target pins an image tag/digest, a blind restart just re-pulls the OLD image and ships nothing new.

Design decisions:

- Parallelism: lint, test, and security scan run in parallel when possible.
- Branch strategy: main/master triggers deploy, while PRs trigger lint+test+build.
- Artifacts: build outputs passed between stages where needed.

### Phase 4: Generate Pipeline Configuration

Generate the complete CI/CD configuration file based on the designed architecture.

For platform-specific syntax and patterns, consult:
- [references/platform-patterns.md](references/platform-patterns.md) - Detailed YAML patterns for each platform

File locations by platform:

| Platform | File Path |
|----------|-----------|
| GitHub Actions | `.github/workflows/ci.yml` |
| GitLab CI | `.gitlab-ci.yml` |
| CircleCI | `.circleci/config.yml` |
| Jenkins | `Jenkinsfile` |

Generation guidelines:

1. Use discovered commands exactly (do not invent scripts)
2. Pin action/orb/image versions (see the pinning goal in Phase 3)
3. Include inline comments explaining non-obvious configuration
4. Set appropriate timeouts for each job
5. Use environment variables for configurable values
6. Follow the platform's recommended project structure

If an existing CI config exists:
- Read the existing file first
- Ask the user whether to replace or augment
- Preserve any custom configuration the user has added
- Merge new stages with existing ones where appropriate

### Phase 5: Validate & Present

#### Step 5.1: Validate, Fix, Re-validate

Run the platform's validator on the generated file, fix every reported error in the file, and run it again. Stop when it is clean or after 3 rounds, then report what still fails.

From mgiovani/cc-arsenal, MIT.

More from mgiovani/cc-arsenal