agentleFS
Sign inStart free
DROOdotFOODROOdotFOO/agent-skills/skills/ci-cd-pipeline-builder/SKILL.md

ci-cd-pipeline-builder

Skill1 starsChanged 2 months agoMITView on GitHub

Detect project stack and generate CI/CD pipeline configuration for GitHub Actions or GitLab CI. TRIGGER when: user asks to set up CI/CD, create a pipeline, add GitHub Actions, configure GitLab CI, or automate testing and deployment. DO NOT TRIGGER when: user is debugging an existing pipeline failure, or asking about deployment infrastructure (servers, containers, cloud).

We split this skill into the rules it gives an agent

17 rules. 0 are common, 16 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 16

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Start with a minimal reliable pipeline that runs tests on every push.

    line 22
  2. Distinctive:

    Test framework and test command

    line 31
  3. Distinctive:

    Default to GitHub Actions unless the project already uses GitLab CI or the user requests otherwise.

    line 38
  4. Distinctive:

    If a pipeline already exists, extend it rather than replacing it.

    line 42
  5. Distinctive:

    Start with the minimal reliable baseline from pipeline-templates.md:

    line 46
  6. Distinctive:

    Run linter/formatter check

    line 48
  7. Distinctive:

    Use the detected runtime version.

    line 52
  8. Distinctive:

    Before presenting the pipeline to the user:

    line 56
  9. Distinctive:

    Verify all referenced tools are in the project's dependencies

    line 57
  10. Very specific:

    Check that test/lint/build commands match the project's configuration

    line 58
  11. Distinctive:

    Ensure secrets are referenced by name, not hardcoded

    line 59
  12. Distinctive:

    Only if the user requests deployment.

    line 64
  13. Distinctive:

    Keep deployment stages separate from CI stages.

    line 69
  14. Distinctive:

    Always cache dependencies.

    line 93
  15. Distinctive:

    Keep pipelines under 10 minutes.

    line 95
  16. Distinctive:

    Never store secrets in pipeline files.

    line 96
  17. Distinctive:

    Run the full test suite, not a subset.

    line 97

“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

CI/CD Pipeline Builder

What You Get

  • GitHub Actions or GitLab CI YAML file ready to commit
  • Dependency caching, pinned versions, test + lint + build stages

Philosophy

Start with a minimal reliable pipeline that runs tests on every push. Add complexity only when justified. A pipeline that is fast and trustworthy is better than one that is comprehensive and flaky.

Workflow: 5 Phases

Phase 1: Detect Stack

Scan the repository for manifests, lockfiles, and configuration files. See stack-detection.md for the full signal table. Identify:

  • Primary language(s) and runtime versions
  • Package manager and lockfile
  • Test framework and test command
  • Linter and formatter
  • Build tool and build command
  • Monorepo structure (if applicable)

Phase 2: Choose Platform

Default to GitHub Actions unless the project already uses GitLab CI or the user requests otherwise. Check for existing pipeline files:

  • .github/workflows/*.yml -- GitHub Actions
  • .gitlab-ci.yml -- GitLab CI

If a pipeline already exists, extend it rather than replacing it.

Phase 3: Generate Pipeline

Start with the minimal reliable baseline from pipeline-templates.md:

  1. Install dependencies (with caching)
  2. Run linter/formatter check
  3. Run tests
  4. Build (if applicable)

Use the detected runtime version. Pin action versions to specific SHAs or major versions. Use lockfile-based caching.

Phase 4: Validate

Before presenting the pipeline to the user:

  • Verify all referenced tools are in the project's dependencies
  • Check that test/lint/build commands match the project's configuration
  • Ensure secrets are referenced by name, not hardcoded
  • Confirm the runner OS matches the project's requirements

Phase 5: Add Deployment Stages

Only if the user requests deployment. Add stages for:

  • Staging deployment (on merge to main)
  • Production deployment (on tag or manual trigger)
  • Environment-specific secrets and approvals

Keep deployment stages separate from CI stages. CI should pass before deployment is attempted.

WRONG: floating versions

# WRONG: unpinned action version, no caching, floating runtime
- uses: actions/setup-node@latest
- run: npm ci && npm test

CORRECT: pinned and cached

# CORRECT: pinned action, lockfile cache, explicit runtime
- uses: actions/setup-node@v4
  with:
    node-version-file: '.nvmrc'
    cache: 'npm'
- run: npm ci
- run: npm test

Rules

  • Always cache dependencies. Uncached CI is a waste of compute.
  • Pin versions: actions, runtimes, dependencies. Floating versions cause flaky builds.
  • Keep pipelines under 10 minutes. If slower, parallelize or split.
  • Never store secrets in pipeline files. Use the platform's secrets manager.
  • Run the full test suite, not a subset. Partial CI is worse than no CI.

Sub-files

FileTopic
stack-detection.mdFile signals per ecosystem
pipeline-templates.mdGitHub Actions and GitLab CI scaffolds

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free