agentleFS
ghivelyghively/infra-ops/skills/pre-commit-and-secret-scanning/SKILL.md

pre-commit-and-secret-scanning

Skill0 starsChanged 5 months agoMITView on GitHub

The fast, developer-machine tier of quality and secret-leak prevention: a .pre-commit-config.yaml with yamllint, a fast ansible-lint subset, gitleaks and TruffleHog, plus end-of-file/whitespace fixers. Advisory (CI is authoritative) and budgeted under ~10s. Triggers on: pre-commit, pre-commit hook, git hook, local lint, fast feedback, secret scan local, developer machine.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use when setting up or reviewing the pre-commit tier — the checks that run on the developer's machine before code is committed, catching …

    line 16
  2. Very specific:

    Pre-commit is advisory; CI is authoritative: Keep the pre-commit set a subset of the CI gates (pre-commit ⊆ CI) so it never disagrees with …

    line 23
  3. Distinctive:

    Budget ~10 seconds: Run only fast checks locally: YAML lint, a fast ansible-lint profile (not the full production sweep), secret scanning …

    line 26
  4. Very specific:

    Never prints a matched secret/PAN value — redact and cite location.

    line 60

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Pre-Commit & Secret Scanning Skill

When to Use

Use when setting up or reviewing the pre-commit tier — the checks that run on the developer's machine before code is committed, catching the obvious before it ever reaches CI. This complements (does not replace) the runtime pan-egress-filter hook and the binding iac-sast-scanning CI gate.

How It Works

  • Pre-commit is advisory; CI is authoritative. Keep the pre-commit set a subset of the CI gates (pre-commit ⊆ CI) so it never disagrees with the gate that actually blocks merges. A developer can bypass a local hook; CI cannot be bypassed.
  • Budget ~10 seconds. Run only fast checks locally: YAML lint, a fast ansible-lint profile (not the full production sweep), secret scanning on the staged diff, and whitespace/EOF fixers. Heavy checks (Molecule, full SAST) stay in CI.
  • Two-layer secret detection — gitleaks (regex/entropy, fast) plus TruffleHog (verified live secrets) on the staged changes. Findings are redacted; the value is never printed.

Examples

# .pre-commit-config.yaml — fast, advisory, pre-commit ⊆ CI
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks: [{id: end-of-file-fixer}, {id: trailing-whitespace}, {id: check-yaml}]
  - repo: https://github.com/adrienverge/yamllint
    rev: v1.35.1
    hooks: [{id: yamllint}]
  - repo: https://github.com/ansible/ansible-lint
    rev: v24.9.2
    hooks: [{id: ansible-lint, args: ["--profile", "basic"]}]   # fast subset; CI runs production
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks: [{id: gitleaks}]
pre-commit install        # activate the git hook
pre-commit run --all-files

Trust boundary

  • Local, read-only over the working tree; no network egress beyond pinned hook installs.
  • Never prints a matched secret/PAN value — redact and cite location; a confirmed hit → the incident-response skill.
  • Advisory only — a green pre-commit does not imply a green CI gate.

Deep Reference

Pre-commit Hook Configuration (.pre-commit-config.yaml)

repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: check-yaml
      - id: check-merge-conflict
      - id: detect-private-key
      - id: end-of-file-fixer
      - id: trailing-whitespace

  - repo: https://github.com/adrienverge/yamllint
    rev: v1.35.1
    hooks:
      - id: yamllint
        args: [-d, '{extends: default, rules: {line-length: {max: 120}}}']

  - repo: https://github.com/ansible/ansible-lint
    rev: v24.5.0
    hooks:
      - id: ansible-lint

  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks:
      - id: gitleaks

Gitleaks Custom Rules (PAN patterns)

# .gitleaks.toml
[[rules]]
id = "pan-luhn"
description = "Possible Payment Card Number (PAN)"
regex = '''(?:\d[ -]?){13,19}'''
keywords = ["pan", "card", "credit", "debit"]
[rules.allowlist]
regexes = ["^[0-9]{4}$"]  # allow 4-digit years, codes

CI vs Pre-commit Relationship

Pre-commit is the fast developer-side check; CI is the authoritative gate. The CI must not rely on pre-commit running locally. Pre-commit failures do not block CI; they are advisory at the developer workstation level and binding at the CI gate.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.