Skip to content
Skill Authoring
Skill

/devops-pipeline

Configure pre-commit hooks and lean GitHub Actions for shift-left quality assurance. Use when adding or auditing CI/CD to maximize local test coverage and minimize CI cost. Skip for Terraform/K8s, deployment pipelines, or non-GitHub CI providers.

BOOST
From plugin
luongnv89-skills
13645 skills4 agents
Install
$ npx -y skills add luongnv89/skills --skill devops-pipeline --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/devops-pipeline

Context preview

The summary Claude sees to decide when to auto-load this skill.

Configure pre-commit hooks and lean GitHub Actions for shift-left quality assurance. Use when adding or auditing CI/CD to maximize local test coverage and minimize CI cost. Skip for Terraform/K8s, deployment pipelines, or non-GitHub CI providers.

SKILL.md

devops-pipeline.SKILL.md
name: devops-pipeline
description: "Configure pre-commit hooks and lean GitHub Actions for shift-left quality assurance. Use when adding or auditing CI/CD to maximize local test coverage and minimize CI cost. Skip for Terraform/K8s, deployment pipelines, or non-GitHub CI providers."
license: MIT
effort: medium
metadata:
  version: 2.3.0
  author: "Luong NGUYEN <luongnv89@gmail.com>"

DevOps Pipeline

Implement comprehensive DevOps quality gates adapted to project type, with a **shift-left philosophy**: run as many checks as possible locally via pre-commit so developers get fast feedback and CI is a safety net rather than the primary gate.

**Core principle**: if a check can run on a developer's machine, it runs there. GitHub Actions runs only what a laptop genuinely cannot — matrix version testing, secrets-dependent scans, deployment, coverage publishing — plus one cheap job proving the hooks were not bypassed.

Check Routing Table

Every check lands in exactly one lane. This table is the single source of truth: workflow steps 2 and 3, the reference files, and any config this skill generates must agree with it.

| Lane | Time budget | What runs there | |------|-------------|-----------------| | `pre-commit` stage (every commit) | < 10s, changed files only | Format, lint, type-check, offline security scans, fast unit tests, compile/import check | | `pre-push` stage (every push) | < 60s, whole repo | Full test suite, CLI E2E, coverage threshold, slow lint rulesets | | GitHub Actions | billed per minute | Version matrix, secrets-dependent scans, coverage upload, deploy/release, bypass guard |

A check that fits an earlier lane must not be repeated in a later one. CI re-running the whole hook set on every push is the failure mode this skill exists to prevent.

To stay within the agent's context budget, this SKILL keeps templates short and links to `references/*.md` for language-specific configs, workflow templates, and the CLI E2E script.

Repo Sync Before Edits (mandatory)

Before creating/updating/deleting files in an existing repository, sync the current branch with remote:

branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

If the working tree is not clean, stash first, sync, then restore:

git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop

If `origin` is missing, pull is unavailable, or rebase/stash conflicts occur, stop and ask the user before continuing.

Safety Rails

This skill writes config into someone else's repository and installs git hooks. Observe all of these:

  • **Never overwrite an existing `.pre-commit-config.yaml` or `.github/workflows/*.yml`.** If the target file exists, follow this merge procedure:

1. Copy the file to `<file>.bak`. 2. Prepare the merged content. Keep user-defined hooks, jobs, and pinned `rev:` values. 3. Show the user the diff between `<file>.bak` and the merged content. 4. If the user confirms, write the merged file. If the user declines, leave the original file unchanged and record the merge as declined. 5. Keep `<file>.bak` until the user confirms the written result.

  • **Show every new file before writing it.** Present a new `.pre-commit-config.yaml` or workflow as a diff. Never write a file the user has not seen.
  • **Validate and dry-run before installing hooks.** Step 2 runs `pre-commit validate-config` and `pre-commit run --all-files` before `pre-commit install`, so findings surface without blocking any commit.
  • **Check for an existing git hook before installing.** `pre-commit install` preserves a foreign hook by moving it to `.git/hooks/<hook>.legacy` and running in migration mode. Never pass `-f`/`--overwrite`, which removes that hook silently. If the user wants the foreign hook deleted, get explicit confirmation first.
  • **Never run `git commit --no-verify` or `git push --no-verify` on the user's behalf.** A failing hook is a finding to report, not an obstacle to route around.
  • **Surface failures, never suppress them.** Do not add a hook id to `SKIP`, relax a lint rule, or lower a coverage threshold to turn a run green. Report the failure and let the user decide.
  • **Stop rather than guess** when the stack is undetected, `pre-commit` is absent, or `origin` is missing — see Edge Cases for each.

Workflow

1. Analyze Project

Detect project characteristics:

# Check for package files and configs
ls -la package.json pyproject.toml Cargo.toml go.mod pom.xml build.gradle *.csproj 2>/dev/null
ls -la .eslintrc* .prettierrc* tsconfig.json mypy.ini setup.cfg ruff.toml 2>/dev/null
ls -la .pre-commit-config.yaml .github/workflows/*.yml 2>/dev/null

Identify:

  • **Languages**: JS/TS, Python, Go, Rust, Java, C#, etc.
  • **Frameworks**: React, Next.js, Django, FastAPI, etc.
  • **Build system**: npm, yarn, pnpm, pip, poetry, cargo, go, maven, gradle
  • **Existing tooling**: Linters, formatters, type checkers already configured
  • **Is this a CLI tool?** — if yes, enumerate all commands/subcommands (check README, `--help`, `click`/`argparse`/`cobra` source) to build an E2E test suite

If no package manifest matches, ask the user for the language and build system before Step 2. Step 1 is done when the language, build system, existing tooling, existing config files, and CLI status (with its command list) are recorded.

2. Configure Pre-commit Hooks (maximize local coverage)

If `pre-commit` is absent, show the install command and stop — see [Edge Cases](#edge-cases). Do not install it automatically.

pip install pre-commit  # or brew install pre-commit

When `pre-commit` is available, write `.pre-commit-config.yaml` for the detected stack. If the file exists, use the Safety Rails merge procedure. See [references/precommit-configs.md](references/precommit-configs.md) for language-specific configurations.

**`pre-commit` stage — every commit,

Read more
Ships withluongnv89-skills

One command drops a tested, versioned skill into your agent. No more ad-hoc prompts. The same rigorous steps run every time. Skills are independent files.

Get the whole plugin

Other skills on luongnv89-skills.