skills/devops-pipeline/SKILL.md
Configure pre-commit hooks and lean GitHub Actions for shift-left quality assurance. Use when adding or auditing CI/CD on a Git repo to maximize local test coverage and minimize CI cost. Skip for Terraform/K8s, deployment pipelines, or non-GitHub CI providers.
npx skillsauth add luongnv89/skills devops-pipelineInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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 locally in under ~60 seconds, it belongs in pre-commit. GitHub Actions should handle things that can't run locally: matrix version testing, secrets-based security scans, deployment, and reporting.
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.
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.
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:
--help, click/argparse/cobra source) to build an E2E test suiteInstall pre-commit framework:
pip install pre-commit # or brew install pre-commit
Create .pre-commit-config.yaml based on detected stack. See references/precommit-configs.md for language-specific configurations.
What to put in pre-commit (run on every commit):
detect-secrets)commit stageWhat to put in pre-commit on push stage (run on git push):
What stays in GitHub Actions only:
If the project is a CLI tool, create scripts/e2e_test.sh that exercises every command/subcommand to verify the CLI works end-to-end (not just compiles). Wire it into pre-commit on the push stage.
See references/cli-e2e.md for command discovery patterns, the script template, and the pre-commit hook snippet.
Install hooks:
pre-commit install
pre-commit install --hook-type pre-push # also install push-stage hooks
pre-commit run --all-files # Test on existing code
Create .github/workflows/ci.yml — but keep it lean since pre-commit already catches most issues. See references/github-actions.md for workflow templates.
GitHub Actions responsibilities (things pre-commit can't do):
Since pre-commit already runs lint, format, type-check, unit tests, and E2E tests — the CI workflow can be simpler: install deps → run pre-commit → run tests with coverage upload → build artifact.
# Minimal CI when pre-commit covers everything locally:
- name: Run pre-commit
run: pre-commit run --all-files
- name: Run tests with coverage
run: <test-command> --cov --cov-report=xml
- name: Upload coverage
uses: codecov/codecov-action@v4
# Test all pre-commit hooks (commit stage)
pre-commit run --all-files
# Test push-stage hooks (includes E2E)
pre-commit run --all-files --hook-stage push
# Verify the CLI E2E script directly
bash scripts/e2e_test.sh
If all local checks pass, GitHub Actions becomes a thin verification layer, not the primary quality gate.
| Language | Formatter | Linter | Type Check | Security | Tests | |----------|-----------|--------|------------|----------|-------| | JS/TS | Prettier | ESLint | tsc | npm audit | Jest/Vitest | | Python | Ruff/Black | Ruff | mypy | Bandit + detect-secrets | pytest | | Go | gofmt | golangci-lint | built-in | gosec | go test | | Rust | rustfmt | Clippy | built-in | cargo-audit | cargo test | | Java | google-java-format | Checkstyle | - | SpotBugs | mvn test |
| Check | Pre-commit (commit) | Pre-commit (push) | GitHub Actions | |-------|---------------------|-------------------|----------------| | Formatting | ✓ | — | — | | Linting | ✓ | — | — | | Type checking | ✓ | — | — | | Security scan (offline) | ✓ | — | — | | Unit tests (fast) | ✓ | — | — | | Full test suite | — | ✓ | ✓ (coverage upload) | | CLI E2E tests | — | ✓ | — | | Multi-version matrix | — | — | ✓ | | Deploy | — | — | ✓ |
After running the skill, the repository contains:
.pre-commit-config.yaml — hooks for formatting, linting, type-checking, and unit tests on commit stage; full test suite and E2E tests on push stage..github/workflows/ci.yml — lean CI that re-runs pre-commit and uploads coverage; no duplicate lint/format steps.scripts/e2e_test.sh (CLI projects only) — executable script exercising every CLI command/subcommand.Example .pre-commit-config.yaml snippet for a Python project:
repos:
- repo: https://github.com/astral-sh/ruff-pre-commit
rev: v0.4.4
hooks:
- id: ruff
stages: [commit]
- id: ruff-format
stages: [commit]
- repo: local
hooks:
- id: mypy
name: mypy type check
entry: mypy src/
language: system
stages: [commit]
- id: pytest-fast
name: fast unit tests
entry: pytest tests/unit -x -q
language: system
stages: [commit]
- id: pytest-full
name: full test suite
entry: pytest --cov=src --cov-report=xml
language: system
stages: [push]
A run passes when all of the following are true:
.pre-commit-config.yaml exists at the repo root and lists at least one hook for the detected primary language (formatter, linter, or type checker)..github/workflows/*.yml exists and runs only the things pre-commit cannot (matrix builds, secret-scanning, deployment, or release).pre-commit run --all-files succeeds (or its failures are surfaced explicitly to the user, not auto-suppressed).eslint, ruff) does not run in both pre-commit and CI on the same trigger.pip install pre-commit or brew install pre-commit) and stop; don't generate config files for a tool that isn't present..pre-commit-config.yaml: Merge new hooks into the existing file rather than overwriting; preserve user-defined hooks and pinned revs.files: path filters so hooks only run on relevant subdirectories.origin remote: Skip the repo-sync step and inform the user; proceed with local-only setup.push stage or GitHub Actions only; note the decision explicitly in the generated config with a comment.After completing each major step, output a status report in this format:
◆ [Step Name] ([step N of M] — [context])
··································································
[Check 1]: √ pass
[Check 2]: √ pass (note if relevant)
[Check 3]: × fail — [reason]
[Check 4]: √ pass
[Criteria]: √ N/M met
____________________________
Result: PASS | FAIL | PARTIAL
Adapt the check names to match what the step actually validates. Use √ for pass, × for fail, and — to add brief context. The "Criteria" line summarizes how many acceptance criteria were met. The "Result" line gives the overall verdict.
Phase: Project Analysis — checks: Project detection, Existing tooling scan, CLI detection, Command enumeration
Phase: Pre-commit Configuration — checks: Pre-commit setup, Hook installation, Push-stage hooks installed, E2E script created (if CLI)
Phase: GitHub Actions Setup — checks: GitHub Actions config, CI lean (pre-commit deduplication), Matrix testing configured
Phase: Pipeline Verification — checks: Commit-stage hooks pass, Push-stage hooks pass, E2E tests pass (if CLI)
documentation
Manage software releases end-to-end: bump version, generate changelog, tag, push, GitHub release, publish to PyPI/npm. Use when user asks to ship, cut a release, tag a version, or list changes since last tag. Skip routine commits and marketplace publishing.
development
Review UI for usability issues using Steve Krug's principles and produce a scannable report. Use when asked for a usability audit, UX review, or UI feedback on screenshots, URLs, or code. Don't use for visual/brand design critique, accessibility (WCAG) audits, or backend/API review.
development
Validate app/startup ideas with market, feasibility, commercial, and open-source competitor analysis. Use when asked to evaluate, validate, or score a product idea. Don't use for PRDs, go-to-market plans, or investor decks.
testing
Install local-first security hardening: pre-commit secret detection, offline dependency scans, static analysis, reports, and gated free CI. Use when hardening repos or adding security hooks. Don't use for incident response or cloud security reviews.