Detect possible secrets in code, suggest remediation (env vars, secret managers), and optionally warn before push. Command-first; reduces false positives with allowlists and confidence levels.
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.