| name | declassify |
| description | Prepare a private repository for safe open-sourcing. Use when the user wants to make a repo public and needs the secrets sweep (code AND git history), personal-info scrub, license and community files, and a go/no-go checklist. |
Declassify
The repo is going public. Everything ever committed — every branch, every old revision — becomes readable by everyone, forever, the moment the switch flips. Your job is to find what shouldn't ship, fix what can be fixed, and deliver an honest go/no-go.
The prime law
A secret that ever touched git history is compromised, full stop. Rewriting history does not un-leak it (clones, forks, and caches exist). Every found credential gets rotated; history rewriting is optional hygiene on top, never the remedy. Say this clearly in the report every time.
Phase 1 — Secrets sweep
Sweep the working tree and the full history (git log -p --all, every branch and tag):
- Known token shapes: cloud provider keys, API tokens (
ghp_, sk-, AKIA…, etc.), private key blocks, connection strings with embedded passwords, webhook URLs.
- High-entropy strings in config-shaped places;
.env-style files ever committed, even if since deleted.
- Secrets hiding outside code: CI configs, docker-compose files, test fixtures, notebook outputs, lockfile registry URLs with tokens.
For each hit: what it is, which commits contain it, whether it's plausibly still live, and the rotation action. Use dedicated scanners if available (gitleaks, trufflehog); do a manual pattern pass regardless — tools miss context-dependent secrets like internal URLs.
Phase 2 — People and places
Things that aren't credentials but shouldn't ship: personal emails and real names beyond what the user intends to publish (including in commit metadata — surface the author list and let the user rule); internal hostnames, IPs, and infrastructure details; client or employer names; hardcoded local paths (/Users/name/…, C:\Users\name\…); embarrassing or legally risky comments and TODOs. Present findings neutrally — the user decides what counts.
Phase 3 — Rights check
Can this actually be licensed as intended? Vendored code and its licenses; copy-pasted snippets of unknown origin (flag anything that looks pasted, e.g. a sudden style change with no history); fonts, images, sounds, and other assets with unclear rights; dependency licenses incompatible with the chosen license.
Phase 4 — The front door
What a stranger sees in the first minute: LICENSE (ask the user's intent — permissive vs. copyleft — rather than assuming), a README whose setup instructions actually work, .env.example for every env var the code reads, CONTRIBUTING.md and SECURITY.md if contributions are welcome, CI status honest (a failing badge on day one is a bad look — fix or remove).
Phase 5 — Go/no-go
Write DECLASSIFY.md:
- Blockers — publishing before these are done is an incident: unrotated live secrets, unresolved rights problems.
- Should-fix — personal info, internal details, missing license/front-door files.
- Judgment calls — items only the user can rule on, stated neutrally with options.
- Rotation ledger — every secret found: location(s) in history, rotate-by action, done/not-done checkbox.
- Optional history rewrite plan —
git filter-repo steps if the user wants the hygiene, with the force-push and re-clone consequences spelled out, and the reminder that rotation already happened because rewriting is not the remedy.
Never flip the repo public yourself. The final act is the checklist, not the switch.
