dead-code-cleanup
The dead-code-cleanup skill uses Repowise's graph analysis to identify unused code, files, and exports in indexed repositories and present candidates for removal. Use this skill when users ask about eliminating unused code, reducing bundle size, refactoring deprecated areas, or addressing technical debt, prioritizing high-confidence findings and requiring user confirmation before any deletion.
git clone --depth 1 https://github.com/repowise-dev/repowise /tmp/dead-code-cleanup && cp -r /tmp/dead-code-cleanup/plugins/codex/skills/dead-code-cleanup ~/.claude/skills/dead-code-cleanupSKILL.md
# Dead Code Cleanup With Repowise Repowise detects dead code through graph analysis and git context. Treat findings as a cleanup plan, not automatic permission to delete. ## Finding Dead Or Unused Code Call `get_dead_code()` to get findings organized by confidence tier. Useful parameters: - `safe_only=true` for findings already marked safe to delete. - `min_confidence=0.7` for high-confidence cleanup work. - `kind="unreachable_file"` for files with no importers. - `kind="unused_export"` for public symbols with no known consumers. - `kind="zombie_package"` for monorepo packages with no consumers. - `directory="src/old/"` to limit scope. - `tier="high"` for the highest-confidence band. ## Presenting Findings - Only recommend deletion for findings with `safe_to_delete: true`. - Present lower-confidence findings as candidates to investigate. - Flag dynamic loading, plugin systems, route handlers, adapters, and public APIs as common false-positive zones. ## Before Deleting Anything 1. Confirm with the user. 2. Present the file or symbol, confidence score, and why Repowise thinks it is dead. 3. Call `get_risk(targets=["path/to/file"])` before deleting files or exports. 4. If the finding has recent git activity, note the higher false-positive risk. ## Safe Deletion Order 1. Unreachable files first. 2. Unused internal symbols next. 3. Unused exports last.
Use when a task asks why code is built a certain way, proposes architectural changes, compares implementation approaches, or mentions decision markers such as WHY, DECISION, TRADEOFF, or ADR in a Repowise-indexed repository.
>
>
Use when exploring, understanding, or answering questions about a Repowise-indexed codebase, including architecture, where code is implemented, how a module works, or which files are relevant before reading source.
Use before modifying, refactoring, moving, or deleting files in a Repowise-indexed repository, especially shared utilities, core modules, public APIs, or files the user did not explicitly identify.