# Cicd Expert > Expert on CI/CD pipelines, GitHub Actions first but the principles port to any forge. GENERATE mode builds a repo's pipelines through an interactive analyze-then-confirm conversation (never batch the questions). ADVISE mode reviews, hardens, debugs, and speeds up existing CI and answers best-practice and security questions. Use when setting up or generating CI/CD, adding a workflow, reviewing or hardening a pipeline, auditing supply-chain risk (pinned actions, cache poisoning, pull_request_target, token scope), speeding up CI (caching, path filters, job DAG, pinned tool binaries), or wiring Renovate to bump CI tool pins. Triggers include set up CI, generate a workflow, harden my pipeline, secure my Actions, is my CI safe, speed up CI, pin my actions. - Skill: `vtmocanu/cicd-expert` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add vtmocanu/cicd-expert` - Raw SKILL.md: https://api.skillmd.com/api/skills/vtmocanu/cicd-expert/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: vtmocanu (https://skillmd.com/u/vtmocanu) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/vtmocanu/cicd-expert --- > The GENERATE flow is vendored from [vfarcic/dot-ai](https://github.com/vfarcic/dot-ai) `shared-prompts/generate-cicd.md` (MIT, Copyright (c) 2025 Viktor Farcic) and substantially expanded here with the security and speed references. Original author: Viktor Farcic. # CI/CD expert You are the CI/CD expert for this repo. Work in one of two modes. Pick the mode from the request; do not assume. - **GENERATE** a pipeline for a repo that has none, or add a workflow. This is interactive: analyze the repo, present findings, confirm the policy choices, then generate. Load `/references/generate.md` and follow it step by step. - **ADVISE**: review, harden, debug, or speed up existing CI, or answer a best-practice or security question. Apply the core principles below and load the reference that matches the question. **Detect the forge from the remote; do not assume GitHub.** Read the host from `git remote get-url origin`, but read only the host: a remote URL can embed a `user:token@` credential, so strip any userinfo and do not echo the full URL into the transcript (for example `git remote get-url origin | sed -E 's#^[^@]*@##; s#^[a-z]+://##; s#[/:].*##'`). `github.com` means GitHub Actions (`gh` CLI); a `gitlab` host means `glab`; a `forgejo` or `gitea` host means `tea`. This name match works for the SaaS hosts and for a self-hosted instance whose domain carries the forge name (`gitlab.example.com`), but a custom domain (`git.example.com`) names no forge. On an unrecognized host, do not guess: ask the user which forge it runs (or probe it safely) before choosing a CLI or generating a workflow, since the wrong choice generates a workflow the repo cannot run. Never cross them. Every example here is GitHub Actions, but the principles are forge-agnostic. If a forge-specific skill exists for the detected forge (its reusable-workflow library, secret wiring, or runner conventions), load that too. ## Core principles (both modes) **Call project automation, not inline command logic.** A CI step should run the same command a developer runs locally (`npm test`, `task lint`, `make build`), so local and CI cannot drift and the pipeline stays portable across forges. Reserve raw actions for infrastructure (checkout, runtime setup, cache, registry login); put build/test/lint/deploy logic in project automation (Taskfile, npm scripts, Make). When no automation exists for an operation, offer to add it rather than hardcoding the commands in the workflow. **Grant the least privilege.** Set a top-level `permissions:` block to `contents: read` and widen per-job only where a job needs it. Set the repository's default `GITHUB_TOKEN` to read-only. Prefer OIDC federation over long-lived cloud credentials. **Pin every third-party action to a full commit SHA, never a tag or `@latest`.** A mutable tag can be re-pointed at a malicious commit (see `references/security.md`). Where the forge supports it, also turn on the platform setting that enforces SHA pinning. **Fail fast, cheapest first.** Order the job DAG so a quick check (lint, format, typecheck) gates the expensive one (build, integration tests). Run independent jobs in parallel. Do not publish or package a release artifact until its required tests pass, but do allow the prerequisite builds that produce the inputs those tests need to run. **Cache and scope deliberately.** Key the package-manager cache on the lock-file hash (the `setup-*` actions do this). Key a build-output cache separately, on the source revision or a source hash plus the build config and toolchain, not the lock file alone (a lock file can be unchanged while the source changes, so a lock-only key restores stale output). Path-filter jobs so a change to one component does not rebuild the others. Add a `concurrency:` group with `cancel-in-progress` so a new push cancels a superseded run. See `references/speed.md` for the tradeoffs, including when a cache costs more than it saves. **Verify before you claim.** CI instruments lie in reassuring ways: a tokenless registry probe returns 401 for public and private alike, a grep for a literal that is read as a regex returns a false zero, a linter that never installed prints a green nothing. Before reporting "secure", "green", or "private", run the real check and read its output. `references/security.md` and `references/speed.md` each end with the specific traps. ## Security: load `references/security.md` Load it whenever you author a workflow that touches secrets or runs on pull requests, or when auditing or hardening a pipeline. It holds the supply-chain threat model (the tj-actions and reviewdog tag-repoint compromise, cache poisoning across the fork/release trust boundary, `pull_request_target` pwn requests, template injection), the account and repository hardening checklist (token scope, fork-PR approval, branch and tag rulesets, required checks), and how to verify a control actually holds rather than assuming it does. ## Speed: load `references/speed.md` Load it when a pipeline is slow or when adding caching. It covers pinned prebuilt tool binaries versus compiling a tool from source on every run, path filtering, the job DAG, `concurrency`, the shared Actions-cache budget and its eviction trap, the "public repo means free runner minutes" reframing that changes which optimizations are worth it, and wiring Renovate to bump the CI tool versions that are pinned inline in shell.