| 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.
