/git-guard

name: memstack-security-git-guard
description: "Use when the user says 'git-guard', 'check git protection', 'is this repo protected', 'verify gitleaks', 'set up git hooks', 'install git-guard', or wants to confirm a repo blocks secrets and internal files before commit. This is an installer and verifier, NOT a scanner (gitleaks does the actual scanning). Do NOT use for deep secret audits or RLS work."
version: 1.0.0

🛡️ Git-Guard: Verifying Repo Protection...

*Install and verify the machine-wide secret-blocking setup on a repo. Confirms the global pre-commit hook, .gitignore coverage, a non-neutered gitleaks config, and a reachable gitleaks binary.*

Activation

When this skill activates, output:

`🛡️ Git-Guard: Verifying Repo Protection...`

Then execute the protocol below.

What This Skill Is (and Is Not)

Git-Guard is an **installer and verifier**, not a scanner. It does not grep for secret patterns itself. Its job is to confirm that the protection layers are present, wired up, and actually armed, so that when a secret IS introduced, gitleaks (run by the pre-commit hook) catches it.

The single most dangerous failure this skill exists to catch is a gitleaks config that LOOKS protective but detects nothing (see Check 3). A scanner that silently scans zero rules is worse than no scanner, because it produces a green checkmark while leaving the door open.

Context Guard

| Context | Status | |---------|--------| | **User asks "is this repo protected?"** | ACTIVE: run all 4 checks | | **User says "set up / install git-guard"** | ACTIVE: run checks, offer fixes | | **User says "verify gitleaks" / "check git hooks"** | ACTIVE: run all 4 checks | | **New repo, before first commit** | ACTIVE: install gitignore + verify config | | **User wants a deep secret/history audit** | DORMANT: defer to secrets-scanner | | **User is mid-commit and just wants it to pass** | DORMANT: do not loosen protection to unblock |

Protocol

Run all four checks (Steps 1 to 4), then produce the status report in Step 5. Step 5 is the report itself, not a fifth check. Never silently run a setup or fix command: show the exact command and let the user run it (or confirm first). The one exception is the additive .gitignore append in Check 2, which is safe and reversible and may be applied after showing the diff.

Locating the files shipped with this plugin

Two checks reference files that ship INSIDE this plugin: the `pre-commit` hook and `gitignore-template.txt`, both under the plugin's `scripts/` directory. After install, those files live in the Claude Code plugin cache, NOT in any fixed location, and NOT in the customer's own project. Resolve `<plugin-root>` as the plugin folder this `SKILL.md` was loaded from, walking up out of `skills/security/git-guard/` to the folder that contains `scripts/`.

On a typical install, `<plugin-root>` looks like this (ILLUSTRATIVE ONLY: the exact path differs per machine and per marketplace):

%USERPROFILE%\.claude\plugins\<marketplace>\cwinvestments-memstack\

To find the real path on the current machine, search the plugin cache:

dir /s /b "%USERPROFILE%\.claude\plugins\gitignore-template.txt"

Substitute the actual resolved `<plugin-root>` wherever it appears in the commands below. Everything that refers to `.gitignore`, `.gitleaks.toml`, or the current repo is relative to the customer's own repo (the current directory), not the plugin.

Step 1: Verify the global pre-commit hook is installed (Check 1)

The pre-commit hook is installed machine-wide via `core.hooksPath`, so one hook covers every repo on the machine. Confirm it is set AND points at a real directory that contains a `pre-commit` file.

git config --global core.hooksPath

Then confirm the directory and hook file exist (using the resolved `<plugin-root>` from the locating note above):

dir "<plugin-root>\scripts\hooks\pre-commit"

Evaluate:

• **OK** if `core.hooksPath` is set AND the directory exists AND it contains a

`pre-commit` file.

• **GAP** if `core.hooksPath` is empty, points at a missing directory, or the

directory has no `pre-commit` file.

If there is a GAP, show the one-time setup command, pointing at this plugin's hooks directory. Do NOT run it silently:

git config --global core.hooksPath "<plugin-root>\scripts\hooks"

> This is a global setting. Confirm the user wants machine-wide coverage before > they run it. If they already use a different hooks manager (Husky, lefthook, > pre-commit framework), note the conflict instead of overwriting it.

Step 2: Verify .gitignore covers the standard offenders (Check 2)

A repo without a proper .gitignore will happily stage `.env`, `node_modules/`, build output, and MemStack session/memory files. Compare the repo's .gitignore against the shipped template.

Check the file exists, then look for the high-value offender patterns:

type .gitignore | findstr /C:".env" /C:"node_modules" /C:"memory/" /C:".serena" /C:"dist/"

The canonical offender list lives in the template shipped with this plugin:

type "<plugin-root>\scripts\gitignore-template.txt"

Evaluate:

• **OK** if .gitignore exists and covers, at minimum: `.env` / `.env.*`,

`node_modules/`, build output (`dist/`, `build/`, `.next/`), and the MemStack internal dirs (`memory/`, `.claude/sessions/`, `.serena/`, `.agent-bridge/`).

• **GAP** if .gitignore is missing entirely, or any of those categories is not

covered.

If there is a GAP, offer to **append** the missing lines from the template. This MUST be additive and de-duplicated: never overwrite the existing .gitignore, and never add a pattern that is already present (exact-line match).

Procedure for the additive append: 1. Read both the repo `.gitignore` and `<plugin-root>\scripts\gitignore-template.txt`. 2. Compute the set of template lines (ignoring blank lines and comments) that are not already present as exact lines in the repo file. 3. S