agentleFS
gonun13gonun13/agent-skills/skills/janitor/SKILL.md

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

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
  1. Distinctive:

    Leave the codebase smaller and cleaner than you found it, with every behaviour still intact.

    line 10
  2. Distinctive:

    Run the project's checks once before touching anything, so you know which failures you inherited.

    line 26
  3. Distinctive:

    Test residue: delete artifacts, fixtures, snapshots, logs, coverage output, and sample files that were produced by a run rather than …

    line 39
  4. Distinctive:

    Never trade behaviour for tidiness.

    line 66
  5. Very specific:

    Never read, edit, move, or delete .env files or any other environment files, and never change an environment variable's value.

    line 68
  6. Distinctive:

    Delete only what you can justify.

    line 72
  7. Distinctive:

    Don't rewrite git history or force-push.

    line 74

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 status and .gitignore, to tell committed files from local litter.

Steps

  1. Run the project's checks once before touching anything, so you know which failures you inherited.
  2. 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 exports map expose is the product, used or not inside the repo; leave it.
  3. 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.
  4. Test residue: delete artifacts, fixtures, snapshots, logs, coverage output, and sample files that were produced by a run rather than authored.
  5. Comments: compact the ones that restate the code. Keep anything explaining a constraint, a workaround, or a non-obvious reason.
  6. 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.
  7. .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.
  8. 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.
  9. 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 .env files 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.example is 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:line or path.
  • 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.