agentleFS
Sign inStart free
V-SongbirdV-Songbird/razor/skills/unused/SKILL.md

unused

Skill8 starsChanged 48 days agoMITView on GitHub

Audit a project's declared dependencies for packages no source file imports. Use when the user asks to find unused dependencies, audit dependencies, check for dead packages, or invokes /razor:unused, $razor:unused or /unused. Report-only; never edits files or uninstalls packages. Not for security audits or outdated-version checks.

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. ShiftinBits/constellation-claude★ 2same 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 repository2 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Default <projectDir> to the current working directory if the user didn't name one.

    line 23
  2. Distinctive:

    Never describe a likely-unused or unknown entry as high confidence — if no resolver ran, the report does not claim one did.

    line 46
  3. Very specific:

    If the script's output names knip as available, relay that escalation verbatim (including the npx knip command it prints) — do not run knip …

    line 48
  4. Distinctive:

    Always include the script's known-limits line verbatim, so the user knows what a clean report doesn't guarantee.

    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

unused

Runs a mechanical audit — declared dependencies (package.json, requirements.txt/pyproject.toml) with no matching import anywhere in the project's source — and presents the findings. Never removes a dependency itself; the user decides.

1. Run the script

In Claude Code the script is ${CLAUDE_PLUGIN_ROOT}/scripts/unused-deps.js. In Codex and Antigravity, resolve ../../scripts/unused-deps.js relative to the directory containing this SKILL.md. Run that absolute script path with the available shell tool, quoting the script path and project directory as separate arguments:

node "<absolute path to scripts/unused-deps.js>" "<projectDir>"

Default <projectDir> to the current working directory if the user didn't name one. The script:

  • reads declared deps for whichever ecosystems have a manifest present (node, python — the ecosystems razor's write-time import gate covers),
  • walks source files (skipping node_modules, dist, .git, and other generated/vendored dirs; test files ARE included — a test-only import still counts as used),
  • counts type-only imports and imports living in .vue/.svelte/.astro/.mdx source as real usage,
  • audits each workspace package of a monorepo against its own manifest and its own files, never the root's,
  • honours the ignore list the project already declares for its own resolver, so a dependency you already answered for is not asked about again,
  • normalizes declared names against import roots in the suppressing direction (e.g. python-dotenv counts as used when the code imports dotenv, pillow when it imports PIL) — normalization only ever hides a finding, never invents one; the blind spots that remain are named in the script's known-limits line,
  • splits misses into three buckets by how much could actually be proved.

The three buckets, and what separates them:

BucketWhat it means
Confirmed unusedThe installed tree was read: no import, no quoted mention in source, the package ships no command, and no installed package peer-requires it. Only possible when dependencies are installed.
Likely unusedNothing referenced it, but nothing could prove it — no installed tree to read, or a python project, where no package metadata was available. A lead, not a verdict.
UnknownSomething references it, or only a resolver can settle it: named in a script or config file, named as a quoted string in source outside an import (how a package loaded through import(variable) shows up), a @types/*/toolchain dep, a package that ships a command, or one that satisfies another package's peer dependency.

For a node project, the script also detects whether knip is installed or resolvable from the target project. It resolves what this audit still cannot: entry-point reachability, config-only plugin loading, and true @types pairing. When knip is present, the report names it as the authoritative escalation for those classes. When it isn't, the report says nothing about it — razor never suggests installing a new tool into the target project.

2. Present the findings

Lead with Confirmed unused — that is the bucket a resolver checked. Report Likely unused as leads, and say plainly why they are only leads: nothing referenced them and nothing proved it. Report Unknown separately with the reason the script printed for each.

Never describe a likely-unused or unknown entry as high confidence — if no resolver ran, the report does not claim one did. If the confirmed bucket is empty, say so plainly rather than promoting the other two buckets to fill the space.

If the script's output names knip as available, relay that escalation verbatim (including the npx knip command it prints) — do not run knip yourself, install it, or add it to any manifest; it stays the user's call.

Always include the script's known-limits line verbatim, so the user knows what a clean report doesn't guarantee.

3. Never remove anything

This skill is report-only. Do not edit package.json, requirements.txt, pyproject.toml, or run an uninstall command as part of this skill, even if the user's phrasing sounds like a request to clean up — surface the findings and let the user decide what to remove.

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.

Check your setup, free