Secret Guard

Name: Secret Guard
Author: jassics

BSecurity

Detect hardcoded secrets, cloud keys (AWS/GCP/Azure), tokens, .env files, and sensitive config before they're committed or pushed, and verify .gitignore covers the patterns that must never be tracked. Use when the user is about to commit/push, asks "did I leak a secret", "check for hardcoded keys", "is my .gitignore missing anything", or when reviewing any diff that touches config/env files. This is the manual/interactive counterpart to the enforced git hooks this plugin installs — see README...

8 stars

0 votes

0 copies

0 views

Added 9/19/2026

securitygoawsgcpazuregit

Works with

claude code

Security Analysis

B75/100

criticalReads or references SSH private keys

Pro scans all 2 files and shows the line behind each finding

Scanned 9/19/2026

$npx -y skills add jassics/awesome-claude-security --skill secret-guard --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Secret Guard?

Add the live security badge to your README — it updates automatically with every re-scan.

[![Security: B — Skills Directory](https://www.skillsdirectory.com/api/skills/jassics-secret-guard/badge)](https://www.skillsdirectory.com/skills/jassics-secret-guard)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro

Files

SKILL.md

---
name: secret-guard
description: Detect hardcoded secrets, cloud keys (AWS/GCP/Azure), tokens, .env files, and sensitive config before they're committed or pushed, and verify .gitignore covers the patterns that must never be tracked. Use when the user is about to commit/push, asks "did I leak a secret", "check for hardcoded keys", "is my .gitignore missing anything", or when reviewing any diff that touches config/env files. This is the manual/interactive counterpart to the enforced git hooks this plugin installs — see README "Enforcement" section.
---

# Goal

Catch secrets and sensitive files before they reach git history — hardcoded or in
`.env`/config files — and make sure `.gitignore` actually excludes the categories of
file that should never be tracked. Enforcement (blocking) happens via the installed
git hooks (`scripts/install-git-hooks.sh`) and the Claude Code `PreToolUse` hook in
`hooks/hooks.json`; this skill is for the interactive/manual pass, e.g. reviewing a
diff before the user commits, or auditing an existing repo.

# Steps

1. Scope: staged changes (`git diff --cached`) by default, or the path the user names,
   or a full-repo audit (including history) if the user asks for that explicitly.
2. Secret detection, in order of preference:
   - `gitleaks detect --source <path> -v` (or `gitleaks protect --staged -v` for staged-only) if installed.
   - `detect-secrets scan <path>` if installed and gitleaks isn't.
   - Fall back to the pattern list in `reference.md` (cloud key formats, generic
     `key=`/`token=`/`secret=` assignments, PEM private key headers) — never skip
     the check for lack of a tool.
3. File-pattern check: flag any staged/tracked file matching the sensitive-file list
   in `reference.md` (`.env*`, `*.pem`, `*.key`, `id_rsa*`, `credentials.json`,
   `.aws/credentials`, `*.pfx`, `secrets.yml`, etc.) regardless of content — these
   files should not be tracked at all, secret-looking content or not.
4. `.gitignore` check: read the repo's `.gitignore` (root and any per-package ones)
   and diff it against the required-patterns list in `rules/gitignore-required.txt`
   (relative to `$CLAUDE_PLUGIN_ROOT`). Report any missing pattern.
5. If a real secret or a sensitive file is already committed (not just staged), say
   so explicitly and note it needs history rewrite + rotation, not just a new commit
   (removing it in a new commit does not remove it from git history).

# Output

```
SECRETS FOUND: <count>
[<severity>] <file>:<line> — <what matched> (<detector: gitleaks|detect-secrets|pattern>)
  → Remediation: remove from source, load from env/secret manager, ROTATE the credential.

SENSITIVE FILES TRACKED: <count>
<file> — matches sensitive-file pattern, must not be tracked.
  → Remediation: `git rm --cached <file>`, add pattern to .gitignore.

.GITIGNORE GAPS: <count>
Missing: <pattern> (<why it matters>)
```

If nothing found, say so plainly — don't pad a clean result with caveats.

Attribution

jassics

View source See grades on GitHub More from jassics →

SSkills DirectorySkills Directory

Your tool, in front of Claude Code builders.

3 founder slots · $299/mo · GSC-verified traffic · sponsors can never buy grades.

See placements

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

--- name: secret-guard description: Detect hardcoded secrets, cloud keys (AWS/GCP/Azure), tokens, .env files, and sensitive config before they're committed or pushed, and verify .gitignore covers the patterns that must never be tracked. Use when the user is about to commit/push, asks "did I leak a secret", "check for hardcoded keys", "is my .gitignore missing anything", or when reviewing any diff that touches config/env files. This is the manual/interactive counterpart to the enforced git hooks this plugin installs — see README "Enforcement" section. --- # Goal Catch secrets and sensitive files before they reach git history — hardcoded or in `.env`/config files — and make sure `.gitignore` actually excludes the categories of file that should never be tracked. Enforcement (blocking) happens via the installed git hooks (`scripts/install-git-hooks.sh`) and the Claude Code `PreToolUse` hook in `hooks/hooks.json`; this skill is for the interactive/manual pass, e.g. reviewing a diff before the user commits, or auditing an existing repo. # Steps 1. Scope: staged changes (`git diff --cached`) by default, or the path the user names, or a full-repo audit (including history) if the user asks for that explicitly. 2. Secret detection, in order of preference: - `gitleaks detect --source <path> -v` (or `gitleaks protect --staged -v` for staged-only) if installed. - `detect-secrets scan <path>` if installed and gitleaks isn't. - Fall back to the pattern list in `reference.md` (cloud key formats, generic `key=`/`token=`/`secret=` assignments, PEM private key headers) — never skip the check for lack of a tool. 3. File-pattern check: flag any staged/tracked file matching the sensitive-file list in `reference.md` (`.env*`, `*.pem`, `*.key`, `id_rsa*`, `credentials.json`, `.aws/credentials`, `*.pfx`, `secrets.yml`, etc.) regardless of content — these files should not be tracked at all, secret-looking content or not. 4. `.gitignore` check: read the repo's `.gitignore` (root and any per-package ones) and diff it against the required-patterns list in `rules/gitignore-required.txt` (relative to `$CLAUDE_PLUGIN_ROOT`). Report any missing pattern. 5. If a real secret or a sensitive file is already committed (not just staged), say so explicitly and note it needs history rewrite + rotation, not just a new commit (removing it in a new commit does not remove it from git history). # Output ``` SECRETS FOUND: <count> [<severity>] <file>:<line> — <what matched> (<detector: gitleaks|detect-secrets|pattern>) → Remediation: remove from source, load from env/secret manager, ROTATE the credential. SENSITIVE FILES TRACKED: <count> <file> — matches sensitive-file pattern, must not be tracked. → Remediation: `git rm --cached <file>`, add pattern to .gitignore. .GITIGNORE GAPS: <count> Missing: <pattern> (<why it matters>) ``` If nothing found, say so plainly — don't pad a clean result with caveats.