Skip to content
Back to skills

Ci Pipeline

ASecurity

CI pipeline discipline: lint→build→test→quality→security, fail-fast, deterministic build, secret handling, PR gates.

  • 24 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 3, 2026
ai-agentstestingdebugginggitsecurity

Works with

  • cli

Security analysis

A100/100

Scanned October 3, 2026

npx -y skills add crewforth/crewforth --skill ci-pipeline --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Ci Pipeline?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Ci Pipeline
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/crewforth-ci-pipeline/badge)](https://www.skillsdirectory.com/skills/crewforth-ci-pipeline)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: ci-pipeline
description: |
  CI pipeline discipline: lint→build→test→quality→security, fail-fast, deterministic build, secret handling, PR gates.
---

# CI Pipeline

<!-- routing-eval reads the next line; why it sits in the body: AGENT_TEMPLATE.md -->
Trigger phrases: "ci", "pipeline", "github actions", "jenkins", "build pipeline", "pr gate", "pr check", "build fail", "build broke", "ci is failing", "workflow"

## Stages (fail-fast — stop if it breaks early)
1. **Lint / format** — style and static analysis
2. **Build** — 0 warnings / 0 errors
3. **Test** — unit + integration, coverage collected
4. **Quality** — `sonarqube-check` quality gate
5. **Security** — `dependency-audit` + `security-scan` (where applicable)
6. **Artifact / packaging** — (deployment is separate, `deploy`)

## Principles
- **Deterministic:** dependencies pinned, cache keyed correctly; no "it worked on my machine".
- **Secret management:** CI secret store; NO plaintext secrets in the repo/logs (overlaps with trace scan).
- **PR gate:** quality gate + tests must pass; a red build is not merged.
- **Branch protection:** direct push to main is disabled; PR + review required.

## When a stage fails
1. **Fetch the failing job's log first** — `gh run view --log-failed`, `glab ci trace`, `jenkins-cli console <job>`,
   whichever this project's host provides — and quote the failing lines: a status icon names which job broke, never why.
   Log unreachable (no access, retention expired, the job never started) → report exactly that; never infer the cause.
2. **Reproduce with the exact command the pipeline runs**, copied out of the CI config — same flags, same env, same
   versions. Green locally is not a pass: the environment difference is now the defect, so take it to `systematic-debugging`.
3. **A re-run is not a fix.** Re-running until it passes hides the cause; re-run only to establish that a failure is
   intermittent — and an intermittent failure in this repo's own suite is a bug (`testing`), not a retry.
4. **Say which failures aren't yours.** A required check owned by another change, or an external service that was
   down, is reported out of scope with the job named — silence about it reads as a clean run.

## DoD
- All stages green; PR gates enforced; no secret leakage; build reproducible.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…