agentsclimarketplace
Sign in

Fec refactor clean

Skill bovinphang/frontend-craft/skills/fec-refactor-clean

Use when safely removing dead frontend code, unused exports, stale components, obsolete routes, unused dependencies, or cleanup targets found by tools such as knip, depcheck, ts-prune, TypeScript, ESLint, or manual review. Do not use for feature rewrites that change behavior; Chinese triggers include dead code, clean up unused, refactor clean, dependency cleanup, delete useless code.From its SKILL.md

Install
npx -y skills add bovinphang/frontend-craft --skill fec-refactor-clean

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 21 stars21 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.6 KB, 628 tokens by cl100k_base, as published. Nobody here has run it

Refactoring and cleaning

Purpose

Identify and clean up unused front-end code under validation protection, reducing technical debt while avoiding accidentally deleting dynamic references, routing entries, configuration files, and runtime conventions.

Procedure

  1. Establish a baseline first: run or confirm the current status of lint, type-check, test, and build.
  2. Collect candidates:
    • Prioritize the use of existing tools in the warehouse, such as knip, depcheck, ts-prune, eslint, and TypeScript.
    • When tools are not available, use rg to check references, exports, routes, registration points and document entries.
  3. Classification by risk:
    • SAFE: test fixtures, unreferenced tool functions, explicitly unexported private components.
    • CAUTION: Shared components, feature entries, style files, Storybook stories.
    • DANGER: routing, configuration, package scripts, runtime templates, dynamic import, plug-in metadata.
    • UPGRADE: Expired dependencies, duplicate dependencies, unused dependencies and security alarms will be evaluated first for dependency upgrade or dependency cleanup, and will not be mixed with dead code deletion.
  4. Only SAFE items are automatically processed; CAUTION and DANGER need to output suggestions and evidence and are not deleted directly.
  5. Run the affected verification command after each batch cleanup.
  6. If the verification fails, stop expanding the cleaning scope and locate the batch first.
  7. Conduct behavioral equivalence review after cleaning: public APIs, routes, commands, templates, metadata, documentation examples, and report outputs can still be referenced.
  8. Sort technical debt: Prioritize projects that have verification protection, affect development efficiency, or block upgrades; only output suggestions for large-scale rewrites with low evidence.

Frontend-Specific Checks

  • Check JSX/template strings, route configuration, barrel export, Storybook, tests, documentation examples and dynamic component registration.
  • Style files need to check className, CSS Modules, Tailwind safelist, global selectors and theme variables.
  • Dependency cleanup checks build plugins, runtime templates, CLI scripts, monorepo subpackages, and peer dependencies.

Constraints

  • Does not change user-visible behavior.
  • Do not remove public APIs, routes, templates, or configurations that cannot be proven referenceless.
  • No "one big delete" replacement for verifiable small batch cleanups.
  • Don't mix formatting, renaming or schema rewriting into dead code cleanup.
  • No evidence that "no one seems to be using it" is needed; there must be search, tool output, type error disappearance, or test protection.
  • Don’t disguise major dependency version upgrades as cleanup; upgrade risks, release notes, and lockfile changes should be offloaded to the dependency upgrade workflow.

Detailed reference

When writing a cleanup report, load references/report-template.md.

Expected Output

  • Clean reports are saved as reports/refactor-clean-YYYY-MM-DD-HHmmss.md.
  • After the code is cleaned, the relevant verification commands pass, or the cause of the blocking is clearly stated.

What ships with it: 1 file

1.3 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most refactoring skills give in 628 tokens

Counted across 545 of the 587 authors here whose files we hold, read 2026-09-06

  • Run tests after each changein 61 of 545, across 59 files
  • Run tests before refactoringin 42 of 545
  • Revert immediately if tests failin 31 of 545, across 28 files
  • Perform refactoring in small stepsin 30 of 545, across 29 files
  • Write characterization tests for untested codein 21 of 545, across 19 files
  • Remove dead code and unused importsin 20 of 545
  • Identify code smellsin 20 of 545
  • Perform one refactoring at a timein 19 of 545
  • Commit after each successful refactoringin 17 of 545, across 15 files
  • Verify all tests pass after refactoringin 17 of 545
  • Keep refactoring separate from behavior changesin 16 of 545, across 14 files
  • Run the full test suitein 16 of 545

Said here and by no other author read

  • Use tools to identify unused code candidates
  • Verify references using search tools if necessary
  • Process only safe items automatically
  • Provide suggestions for caution and danger items
  • Run verification commands after each batch
  • Stop cleaning if verification fails

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.