no-secrets

Scan files for secret-like patterns; report findings with type, file, line, and suggested fix; support scope (file / staged / changed).

# No-secrets scan

## Trigger

The user runs the `/no-secrets` command or asks to scan for secrets, check for leaked keys, or run a pre-commit/pre-push secret check.

## Scope

- Prefer **staged files** (or **changed files** in the branch) when the user is preparing to commit or push.
- Support **current file** for a quick check, or **whole repo** with a warning if the repo is large (suggest scoping to changed/staged when possible).
- Skip or treat with lower priority: binary files, minified JS/CSS, and paths that are clearly test/fixture/docs (e.g. `**/test/**`, `**/*.example`, `**/fixtures/**`, `**/docs/**`) to reduce false positives.

## Patterns we flag (high confidence)

- API keys: generic hex/uuid-like strings in key/secret/token/password variable names or config keys; known prefixes (`sk_`, `pk_`, `ghp_`, `xoxb_`, etc.).
- Connection strings: `postgres://`, `mongodb+srv://`, `redis://`, and similar with embedded credentials.
- Bearer tokens, `Authorization` headers with literal tokens.
- Private key content (e.g. PEM-like blocks) in code or config.
- AWS/Google/Azure-style access keys or key IDs in assignments.

## Reduce false positives

- Ignore or treat as low confidence: values like `your_key_here`, `replace_me`, `xxx`, `<REDACTED>`, `***`, empty string, example URLs (`https://example.com`).
- Report confidence where useful: **high** (known format + context), **medium** (pattern match), **low** (e.g. long random string only).

## Workflow

1. Determine scope from user request or default to staged/changed files.
2. For each file in scope (respecting skip paths): look for secret-like patterns; apply allowlists/placeholders; assign confidence.
3. For each finding: output file, line (or region), pattern type, and a one-line **remediation**. **Never include the actual secret value** in the report—only location and type—so the chat transcript does not contain secrets. (e.g. "Use `process.env.API_KEY` and add `API_KEY` to `.env.example` with a placeholder", "Move to secret manager", "Ensure `.env` is in `.gitignore`").
4. If a secret appears in already-committed history: recommend **rotating** the secret and invalidating the old one; mention history rewrite only with caution.
5. Output: structured report (scope scanned, list of findings, remediation summary); one-line summary (e.g. "N possible secrets in M files (X high, Y medium, Z low). Rotate any exposed keys."). If no issues: "No secret-like patterns found in the scanned scope."

## Guardrails

- Do not modify or delete user files; only report and suggest.
- Never echo or quote the actual secret value in the report; use only file, line number, pattern type, and remediation.
- Do not block push or commit; the plugin warns and advises.
- Recommend using CI secret scanning for pushed code and keeping `.env` in `.gitignore` with a `.env.example` without real values.

Run the no-secrets scan (default: staged or changed files).

Run the **no-secrets-scan** skill. Default scope: staged files, or changed files in the current branch if nothing is staged. Output the structured report and remediation summary.

Prefer env vars or a secret manager for secrets; when the user asks to scan for secrets or run a pre-commit/pre-push check, run the no-secrets-scan skill.

# No-secrets policy

Do not add secrets (API keys, tokens, passwords, connection strings) to source code. Prefer environment variables or a secret manager (e.g. Doppler, Vault). When the user asks to "scan for secrets", "run no-secrets", "check for leaked keys", or to run a pre-commit or pre-push check, run the **no-secrets-scan** skill with the appropriate scope (e.g. staged or changed files).