When to use this
- A new or changed CI workflow/pipeline definition needs review before merging.
- CI is green but a bug still reached production -- check whether the pipeline is actually testing what it claims to.
- Not for reviewing the application code the pipeline tests -- scope to the pipeline definition itself.
The skill file
Copy this verbatim. It's written in the SKILL.md format (YAML frontmatter + markdown instructions) that Claude Code, and increasingly other agent tools, read directly.
--- name: ci-pipeline-reviewer description: Review a CI/CD pipeline definition (GitHub Actions, GitLab CI, Jenkins, etc.) for issues that let it report success when it shouldn't -- swallowed exit codes, steps that silently skip, caching that masks a real failure. Use for new/changed pipeline definitions. --- # CI Pipeline Reviewer A pipeline that's green when it shouldn't be is worse than no pipeline -- it's false confidence. ## What to check - **Exit code handling**: does any step pipe a command's output through another command (`cmd | tee log.txt`, `cmd | grep ...`) in a way that masks the original command's exit code? Check the shell's pipefail setting. - **Continue-on-error / allow-failure flags**: are any test or build steps marked to not fail the pipeline? If so, is that intentional and narrowly scoped, or does it accidentally cover a step that should be a hard gate? - **Caching correctness**: does a dependency/build cache key include everything that should invalidate it (lockfile hash, not just a static key)? A stale cache can hide a real dependency/build issue. - **Conditional execution**: do `if:` conditions on steps/jobs correctly express when they should run -- check for a condition that accidentally always evaluates true/false, or a job that's supposed to block merge but isn't actually a required check. - **Secrets handling**: are secrets passed via the platform's secret mechanism, not echoed into logs or passed as plain command-line args that'd show up in process listings/logs. - **Timeout and retry settings**: does a flaky step retry in a way that could mask a real intermittent failure, or is there no timeout on a step that could hang indefinitely and block the whole pipeline? ## Output Findings ordered by how badly they undermine the pipeline's actual guarantee (a masked test failure is more severe than a slow cache), each with the specific line and the fix.
Installing it elsewhere
The frontmatter/body split above is Claude Code's convention. Here's how to carry the same instructions into other tools:
Save the file below verbatim (frontmatter included) at that path, project-local or in ~/.claude/skills/ for a user-level skill. Claude Code loads the name/description pair to decide when to pull it in, or you invoke it directly as /ci-pipeline-reviewer.
Convert the YAML frontmatter to Cursor's rule format (description, globs, alwaysApply: false) and keep the markdown body as the rule content. Cursor surfaces it by description match, same idea as Claude Code's auto-load.
Codex CLI (and increasingly other agentic CLIs) read AGENTS.md at the repo root as always-on instructions. Paste the markdown body under a heading like ## {title}; for GitHub Copilot's coding agent, the equivalent file is .github/copilot-instructions.md.
Append the markdown body to .windsurfrules at the repo root. Windsurf treats the whole file as always-on context, so keep only the instructions you want applied on every request.
- Missing a piped command that swallows the real exit code (classic: `command | tee file` without pipefail).
- Not checking whether a "required check" in branch protection actually maps to the job that matters.
- Overlooking secrets exposed via command-line arguments or debug/verbose logging.