janitor
Skill0 starsChanged 2 months agoMITView on GitHub
Removes dead code, unused dependencies, test leftovers, verbose comments, and hardcoded secrets, and keeps .gitignore current. Use when cleaning up or tidying a codebase.
- Reads credentials
4 other projects use a version of this.
Adopted by
Most recently taken up by
- CipherNovaa/agent-skillstheir own version, first seen Nov 1, 2026
- udaysharmadev/Skillstheir own version, first seen Sep 17, 2026
- Nathan5674312/fatetheir own version, first seen Sep 4, 2026
- adamjali/janitor-templatetheir own version, first seen Jun 28, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- udaysharmadev/Skills★ 12same name
- adamjali/janitor-template★ 1same name
- CipherNovaa/agent-skills★ 0same name
- Nathan5674312/fate★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- adversarial-reviewSkill
- changelogSkill
- cve-patchSkill
- diagnoseSkill
- docs-driftSkill
- good-readmeSkill
- improve-designSkill
- improve-seoSkill
- kickoffSkill
- nta-scanSkill
- refactor-oopSkill
- repo-reconSkill
- software-architectureSkill
- spec-driven-devSkill
- stack-adviseSkill
- your-skill-nameSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 6 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 10
Leave the codebase smaller and cleaner than you found it, with every behaviour still intact.
- Distinctive: line 26
Run the project's checks once before touching anything, so you know which failures you inherited.
- Distinctive: line 39
Test residue: delete artifacts, fixtures, snapshots, logs, coverage output, and sample files that were produced by a run rather than …
- Distinctive: line 66
Never trade behaviour for tidiness.
- Very specific: line 68
Never read, edit, move, or delete .env files or any other environment files, and never change an environment variable's value.
- Distinctive: line 72
Delete only what you can justify.
- Distinctive: line 74
Don't rewrite git history or force-push.
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Janitor
Goal
Leave the codebase smaller and cleaner than you found it, with every behaviour still intact.
Context
Check first:
- The build/test/lint commands the project actually uses, and its dependency manifest and lockfile.
- Whatever dead-code, unused-dependency, or secret-scanning tooling the project
already has (linter rules,
knip,ts-prune,vulture,depcheck,cargo-udeps,gitleaks, ...). Prefer its tools over your own judgement. git statusand.gitignore, to tell committed files from local litter.
Steps
- Run the project's checks once before touching anything, so you know which failures you inherited.
- Dead code: find unreferenced files, exports, functions, and flags. Confirm
each is unused across the whole repo — including dynamic imports, reflection,
config, and CI — before deleting it. In a published library, everything its
entry points or
exportsmap expose is the product, used or not inside the repo; leave it. - Dependencies: drop packages with no remaining references and update the
lockfile with the project's own package manager. Imports are not the only
reference: packages named in config files or loaded by a tool (ESLint
plugins and configs, Babel and PostCSS presets,
@types/*, test environments, CLI binaries in scripts) and declared peer dependencies are in use. - Test residue: delete artifacts, fixtures, snapshots, logs, coverage output, and sample files that were produced by a run rather than authored.
- Comments: compact the ones that restate the code. Keep anything explaining a constraint, a workaround, or a non-obvious reason.
- Secrets: search for hardcoded credentials, tokens, and keys in source,
config, and scripts. Flag each one as needing rotation — removing it from
the working tree does not remove it from history. Move it out of the code
only when the project already has a config mechanism (an env loader, a
settings module) to read it from: read it through that mechanism, and add
the variable name with a placeholder value to
.env.example. Otherwise leave it in place, flagged, rather than add a mechanism. .gitignore: add entries for local, generated, or private paths you saw, and flag anything already committed that should not be public. Agent provider directories (.claude/,.cursor/,.codex/,.opencode/, ...) belong in.gitignore.- Other AI-provider files — prompts, agent configs, transcripts, generated scratch files — get flagged for the operator, not deleted. First decide from the code whether the project uses an AI provider or integrates with one: in an AI project these files are the product, so leave them alone and say so.
- Validate: rerun the project's build, test, and lint commands and confirm the result matches step 1.
In plan mode, the plan is the report below with each change still to be made: what would go, per category, and how you verified it is unused.
Constraints
- Never trade behaviour for tidiness. If you cannot prove something is unused, leave it and list it as a suspicion instead.
- Never read, edit, move, or delete
.envfiles or any other environment files, and never change an environment variable's value. Only make sure they are ignored by git and not committed..env.exampleis the exception: add a moved secret's variable name there, never its value. - Delete only what you can justify; no drive-by refactors, renames, or reformatting.
- Don't rewrite git history or force-push.
Done when
The project's own build, test, and lint commands pass exactly as they did before, every change is accounted for in the report, and every known secret is either moved to existing configuration or flagged under Needs a human.
Output
A report with one section per category (dead code, dependencies, test residue,
comments, secrets, .gitignore, AI-provider files), each listing:
- What changed, as
path:lineorpath. - Why it was safe to change, and how you verified it.
End with:
- Left alone — what looked removable but was not provably unused, and what would settle it.
- Needs a human — secrets to rotate, variables that must now be set before the project runs, secrets left in place because there was no config mechanism, committed files to purge from history, or anything else outside this cleanup.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

