gitops-pipeline-developer

name	gitops-pipeline-developer
version	1.0.0
description	Author production-ready GitOps release pipelines (Jenkins-style by default; portable patterns for GitHub Actions, GitLab CI, Drone) that combine Gitflow branching, Conventional Commits, automatic SemVer bumping, a SonarQube quality gate, Grype container image scanning, and an aggregated quality+security scorecard with policy alignment checks. Use this skill whenever the user wants to write or harden a CI/CD pipeline, set up a release flow, automate versioning, enforce conventional commits, gate merges on SonarQube, scan images with Grype, build a release scorecard, or hits you with phrases like "set up the CI", "write me a Jenkinsfile", "add SonarQube", "enforce conventional commits", "wire SemVer", "scan our images for CVEs", "add a quality gate", "CI for this repo", or "I need a release pipeline".
license	MIT
compatibility	claude-code opencode
allowed-tools	["Read","Write","Edit","Grep","Glob","Bash"]
metadata	{"author":"MKAbuMattar","requirements":"Jenkins 2.x with Kubernetes plugin (default target). Patterns also map to GitHub Actions, GitLab CI, Drone, and Buildkite. Requires `git`, `bash`, `jq`, and `yq` on the build agent. Image build uses BuildKit (rootless); image scan uses Grype; signing uses cosign + a KMS / Vault transit key."}

GitOps Pipeline Developer

Author production GitOps release pipelines that combine Gitflow + SemVer + Conventional Commits with a SonarQube + Grype quality gate and a single Score & Alignments scorecard.

When to use

• The user wants to write a new CI/CD pipeline (Jenkinsfile / .github/workflows / .gitlab-ci.yml).
• The user wants to harden an existing pipeline with SonarQube, Grype, conventional commits, or SemVer.
• The user wants a "release scorecard" — a single number (0–100) plus policy alignment checks gating each merge or release.
• A task chain ends in "and put it behind the CI quality gate".

The release model in one paragraph

Gitflow — long-lived main (production) + develop (integration), short-lived feature/*, release/*, hotfix/*. Releases merge to main and develop; hotfixes branch from main. Conventional Commits — every commit is <type>(scope): subject (feat:, fix:, chore:, docs:, test:, refactor:, perf:, build:, ci:, BREAKING CHANGE: footer). Enforced by commitlint in CI and locally via a Husky commit-msg hook. SemVer — bumps are derived from commits since the last tag: feat: → minor, fix:/perf: → patch, BREAKING CHANGE: → major. semantic-release (or an equivalent) reads the commit history, decides the next version, writes the tag, and updates CHANGELOG.md. Prerelease branches (develop, release/*) get suffixed tags (1.4.0-rc.1, 1.4.0-beta.3).

The pipeline enforces all three: a commit that doesn't match Conventional Commits fails CI before tests run; the SemVer bump is computed automatically with no human input; merges to main only succeed when both the SonarQube quality gate and Grype severity gate pass.