agentleFS
denniemokdenniemok/simple-skills/simple-full-refactor/SKILL.md

simple-full-refactor

Skill1 starsChanged 43 days agoMITView on GitHub

Refactor the entire repo with minimal changes to remove redundancy (DRY), dead code, leftovers, and unused files, without changing behavior. Use when the user asks for a full, whole-repo, or deep refactor or cleanup.

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 12 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈12

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the tree and detect the repo's conventions, entry points, and tooling.

    line 21
  2. Distinctive:

    Read nearby usage and existing tests to confirm current behavior.

    line 31
  3. Distinctive:

    Run the build, type check, or tests.

    line 34
  4. Distinctive:

    Keep behavior and public APIs unchanged unless the user asks otherwise.

    line 38
  5. Distinctive:

    Prefer small edits over sweeping changes.

    line 39
  6. Distinctive:

    Do not add layers that bring indirection without clear benefit.

    line 41
  7. Distinctive:

    Keep comments and move them with the code they describe.

    line 42
  8. Distinctive:

    Follow the repo's existing naming, style, and file layout.

    line 43
  9. Distinctive:

    Before deleting a file, confirm nothing references it.

    line 47
  10. Distinctive:

    Never delete entry points, config files, or files the tooling or framework loads by path or convention (routes, migrations, public assets, …

    line 48
  11. Distinctive:

    Keep files that may be valuable later, even if unused now: docs, notes, examples, templates, fixtures, seed data, migrations, scripts, …

    line 49
  12. Distinctive:

    Delete with git rm when in a git repo, so it can be restored.

    line 50

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Simple Full Refactor

Clean up the whole repo without breaking it. Same idea as simple-refactor, but across every file, and it also removes leftovers and unused files. The golden rule is to change only what is necessary. If the code is good enough, leave it.

Scope

The entire repo. Skip third-party, generated, and build output folders (node_modules, dist, lock files, and similar).

Workflow

  1. Read the tree and detect the repo's conventions, entry points, and tooling.
  2. Find:
    • Repeated logic, data, or patterns, including across modules
    • Dead code, unused imports, and unreachable branches
    • Leftovers: debug logs, commented-out code, and temp or backup files
    • Files and dependencies that nothing references
    • Long functions or files doing more than one job
    • Deep nesting that early returns would flatten
    • Magic numbers and strings that need a named constant
    • Unclear names
  3. Read nearby usage and existing tests to confirm current behavior.
  4. Propose a plan: the code changes in short, plus every file and dependency to delete with the reason. Wait for approval before deleting.
  5. Apply the fixes and update call sites. Add or adjust tests only when needed to guard against regressions.
  6. Run the build, type check, or tests. If you cannot, say what should be run.

Rules

  • Keep behavior and public APIs unchanged unless the user asks otherwise.
  • Prefer small edits over sweeping changes. Work module by module.
  • Extract only when the duplication is meaningful. Two similar lines are not a reason to add an abstraction.
  • Do not add layers that bring indirection without clear benefit.
  • Keep comments and move them with the code they describe.
  • Follow the repo's existing naming, style, and file layout.

Deleting files

  • Before deleting a file, confirm nothing references it. Search imports, dynamic imports, configs, scripts, HTML, and docs.
  • Never delete entry points, config files, or files the tooling or framework loads by path or convention (routes, migrations, public assets, workflows).
  • Keep files that may be valuable later, even if unused now: docs, notes, examples, templates, fixtures, seed data, migrations, scripts, design assets, and drafts of planned features. When unsure, keep it and list it as "unused, kept".
  • Delete with git rm when in a git repo, so it can be restored.

Output

A short summary of what changed, the deleted files and dependencies, the unused files kept and why, plus any risks or areas that need testing.

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.