Configure a two-layer gitleaks credential and identifier leak gate for repositories.
npx skills add https://github.com/peachest/skills --skill setup-gitleaks-peachest
Please help me install this Agent Skill. Skill: setup-gitleaks Source: https://github.com/peachest/skills/tree/main/in-progress/setup-gitleaks Command: npx skills add https://github.com/peachest/skills --skill setup-gitleaks-peachest
[[rules]] for credentials plus a grep -E pattern layer for internal identifiers, combined in one sanitize-check.sh script. - Ready-to-adapt templates: Ships gitleaks.toml with placeholder rules and commented allowlist entries, and a gate script with three file-selection modes (tracked, untracked/modified, explicit paths). - Enforcement ladder: Guides wiring from manual runs to an AGENTS.md pointer to a pre-push hook that scans only the commits being pushed. - Use Case: Before open-sourcing an internal repo, run the gate to catch a database connection string in an old commit and internal hostnames in docs, then add a pre-push hook so future pushes are blocked on any finding. ## Quick Start Set up a gitleaks credential and sanitize gate for this repository before it is pushed public.High-intent search queries and answers about installing and using this skill.
Create a custom gitleaks.toml with one [[rules]] entry per secret family harvested from git log -p and credential files, then add a sanitize-check.sh script that also greps for internal identifiers. Wire a pre-push hook that scans the exact commits being pushed and blocks on findings.
Add a second grep -E pattern layer in the same gate script for identifiers gitleaks cannot judge, such as internal domains, node names, and person names. Use word-boundary tokens like \bllmops\b when the term is also a common substring.
No. gitleaks only covers credentials like passwords, tokens, and private keys; it cannot judge repo-specific identifiers such as internal hostnames or project names. The gate must state this boundary explicitly so reviewers do not assume a green check means clean.
The rule file and checker script contain the patterns themselves, so the gate self-matches forever without allowlist entries. Add gitleaks.toml and scripts/sanitize-check.sh to the [allowlist] paths, with a comment explaining each entry.
Install a pre-push hook via core.hooksPath that runs gitleaks against git rev-list <remote>..<local>, scanning only the commits being pushed, and blocks the push on any finding. Manual runs and AGENTS.md pointers alone are not reliable enforcement.
No. For internal repos, internal hostnames and IPs are expected content, so the identifier pattern layer should be dropped to avoid false positives that teach reviewers to ignore the gate. Keep only the credentials layer for that repo shape.
mattbobambroseDetect committed secrets and sensitive files in git history and working tree.
ArthTech-AIRun local pre-push tests on changed hooks, skills, and manifests.
amanning3390Scan codebases for vulnerabilities, secret leaks, and misconfigurations.
balsm-healthAutomate hardcoded secret detection in CI/CD pipelines with gitleaks and trufflehog.