secret-detection
Use when you suspect API keys, tokens, or passwords are hardcoded in source code or committed to git history — scans and guides safe removal without breaking existing integrations.
Best use case
secret-detection is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when you suspect API keys, tokens, or passwords are hardcoded in source code or committed to git history — scans and guides safe removal without breaking existing integrations.
Teams using secret-detection should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/secret-detection/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How secret-detection Compares
| Feature / Agent | secret-detection | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when you suspect API keys, tokens, or passwords are hardcoded in source code or committed to git history — scans and guides safe removal without breaking existing integrations.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Secret Detection
## When to Use
- Auditing a codebase for accidentally committed credentials
- Before open-sourcing a private repository
- After a developer reports a potential secret leak
- As part of a regular security review cadence
- Setting up pre-commit hooks for secret prevention
## Prerequisites
- Access to the repository source code and git history
- Ability to rotate compromised credentials
- Access to a secrets manager or environment variable configuration
## Workflow
### 1. Scan Source Code for Secret Patterns
```powershell
# AWS Access Keys
grep -rn "AKIA[0-9A-Z]{16}" . --include="*.ts" --include="*.js" --include="*.py" --include="*.json"
# GitHub tokens
grep -rn "ghp_[a-zA-Z0-9]{36}\|github_pat_[a-zA-Z0-9_]{82}" .
# Generic API keys and secrets
grep -rni "api[_-]?key\s*[:=]\s*['\"][a-zA-Z0-9]" src/ --include="*.ts" --include="*.js"
# Private keys
grep -rn "BEGIN.*PRIVATE KEY" .
# Connection strings with credentials
grep -rni "mongodb\+srv://\|postgres://\|mysql://" . | grep -v "localhost\|example\|template"
# JWT secrets and signing keys
grep -rni "jwt[_]?secret\|signing[_]?key" src/ --include="*.ts" | grep -v "process\.env\|config\."
```
### 2. Check for Secret Files
```powershell
# Find committed secret files
git --no-pager ls-files | Select-String "\.pem$|\.key$|\.p12$|\.pfx$|id_rsa|\.env$"
# Check .gitignore covers sensitive patterns
Get-Content .gitignore 2>$null | Select-String "\.env|\.pem|\.key|secret"
```
### 3. Scan Git History
Secrets removed from code may still exist in git history:
```powershell
# Search recent commits for secret patterns
git --no-pager log --all -p --since="6 months ago" -S "AKIA" --oneline | Select-Object -First 20
# Search for common secret keywords in diffs
git --no-pager log --all -p -S "api_key" --oneline | Select-Object -First 20
```
### 4. Remediate Found Secrets
**Step 1: Rotate the credential immediately**
Any secret found in source code should be considered compromised.
**Step 2: Replace with environment variables**
```typescript
// BEFORE — hardcoded secret
const apiKey = 'sk-abc123def456';
// AFTER — environment variable
const apiKey = process.env.API_KEY;
if (!apiKey) throw new Error('API_KEY environment variable is required');
```
**Step 3: Add to .env.example (without values)**
```bash
# .env.example
API_KEY=
DATABASE_URL=
JWT_SECRET=
```
**Step 4: Update .gitignore**
```powershell
# Ensure .env is ignored
echo ".env" >> .gitignore
echo ".env.local" >> .gitignore
echo "*.pem" >> .gitignore
echo "*.key" >> .gitignore
```
### 5. Prevent Future Leaks
```powershell
# Add a pre-commit check (example with grep)
# Create a simple pre-commit hook
```
```bash
#!/bin/sh
# .git/hooks/pre-commit
if git diff --cached | grep -qiE "AKIA[0-9A-Z]{16}|ghp_[a-zA-Z0-9]{36}|BEGIN.*PRIVATE KEY"; then
echo "ERROR: Potential secret detected in staged changes. Aborting commit."
exit 1
fi
```
## Examples
### Comprehensive Scan Script
```powershell
# Run all pattern checks and summarize
$patterns = @(
"AKIA[0-9A-Z]{16}",
"ghp_[a-zA-Z0-9]{36}",
"BEGIN.*PRIVATE KEY",
"password\s*=\s*['\"][^'\"]+['\"]"
)
foreach ($p in $patterns) {
$matches = grep -rn $p src/ --include="*.ts" --include="*.js" 2>$null
if ($matches) { Write-Host "FOUND: $p"; $matches }
}
```
### Migrating Secrets to Environment Variables
```powershell
# 1. Find all hardcoded values
grep -rn "const.*secret\|const.*key\|const.*password" src/ --include="*.ts" | grep -v "process.env"
# 2. For each finding, edit the file to use process.env
# 3. Add the variable to .env.example
# 4. Add the actual value to your deployment's environment config
```
## Tips
- **Rotate first, clean up second** — assume any committed secret is already compromised
- Use `explore` agent to trace how a secret is used before replacing it with env vars
- Common false positives: test fixtures, example configs, documentation — but always verify
- For removing secrets from git history, consider `git filter-repo` (destructive, requires coordination)
- Add secret scanning to your CI pipeline so this check runs automatically
- Store secrets in a dedicated manager (Vault, AWS SSM, GitHub Secrets) — not in `.env` files on serversRelated Skills
verification-before-completion
Use before claiming any task is done — run the exact command that proves the fix works, read the output, and only then report success.
using-git-worktrees
Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly
triage
Use when a single issue needs structured triage — classify it, reproduce if needed, request missing information, and leave a durable brief or close-out note in the tracker.
to-issues
Use when a plan, spec, or PRD must become an actionable backlog — break it into thin dependency-aware issues that each deliver a verifiable vertical slice
sprint-workflow
Use when starting a new feature, refactor, or multi-step dev task — runs the full sprint cycle (Think → Plan → Build → Review → Test → Ship → Monitor) using Copilot CLI's plan/autopilot modes.
sprint-retro
Use at the end of a sprint to run a data-driven retrospective — analyzes session history and git metrics to surface what shipped, what slowed you down, and concrete improvements.
security-audit
Use when a codebase needs a formal security audit beyond a quick scan — applies OWASP Top 10 and STRIDE threat modeling from a CSO perspective to surface systemic vulnerabilities.
release
Use when a sprint or feature is complete and ready to ship — tags the version, generates GitHub Release notes, runs rollout or smoke verification, and publishes to npm/PyPI/Docker registries.
prompt-optimizer
Use when a rough prompt, vague idea, or task description needs to become a finished copy-pasteable prompt for a chat-based LLM - rewrite it into one ready-to-send prompt with no blanks, no placeholders, and a clear output shape.
outside-voice
Use when you need an independent second opinion before, during, or after implementation — run challenge, consult, or review mode in a direct builder-to-builder voice
llm-wiki
Use when research or domain knowledge keeps getting rediscovered across sessions — build a supplementary markdown wiki that compounds synthesized knowledge without replacing GitHub or committed project guidance
interview-me
Use when a request is underspecified and you need to discover what the user actually wants before writing a plan, spec, or code - ask one question at a time, attach your current hypothesis, and stop only after the intent is explicitly confirmed.