Repotidy: A clean repo before you publish or hand over

Before a repo goes public or to a new maintainer, the risks are easy to miss: an old key still in history, a backup file holding a database password, dead code nobody dares remove. Delete the wrong file, such as a lockfile CI installs from, and the build breaks. Repotidy cleans a repository in a fixed order: audit, verify, clean, purge, prove, publish, rotate.

What it does

• Parallel audit of structure, dead code, assets, dependencies, secrets, personal data and history, with evidence per item.
• Repo health pass finds churn hotspots crossed with complexity, rework and bus factor, at file level, never per person.
• Deep verification of every removal candidate against config, registration files, CI, routes and runtime URL loads.
• History purge with git filter-repo or a squash import, only after your explicit approval and a backup bundle.
• Proof that behaviour did not change: full suite green and identical output for moved functions.
• Privacy test scans the tree and every outward text (commit messages, README, release notes) against your private-terms list.
• Dated rotate list for every key that ever reached history.

How it works

1. Check the ground: .git present, clean tree, latest main.
2. Audit and deep-verify, then you answer remove, keep or move by number.
3. Restructure in small git mv batches, a commit per module.
4. Purge and force-push only with approval; stale clones and hashes are noted.
5. Publish or back up, then rotate keys and add a pre-commit guard.

Frameworks & tools

git, git filter-repo, gh, a secret scanner such as gitleaks, ruff, radon or the ESLint complexity rule, and your existing test runners.

Why this beats prompting it yourself

Agents often flag used dependencies as unused. This skill deep-verifies first, takes no destructive step without your numbered answer, and treats a deleted secret as not yet safe: only rotation ends the leak.

Use cases

• Open-sourcing or turning a repo into a template.
• Handover to a new maintainer.
• Leak response after a secret or customer CSV was committed.
• Legacy trim of dead assets and code.

Known limitations

Not for mid-feature work or design refactors. A history rewrite kills old clones. A leak only in the last unpushed commit just needs an amend and a key rotation.