agentsclimarketplace

Codebase prune review

Skill jimtin/production-ai/skills/codebase-prune-review

Skills and guardrails that make AI coding agents prove their work: planning gates, test preflights, fail-closed deployment, and a self-improving skill library.

Install
npx -y skills add jimtin/production-ai --skill codebase-prune-review

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

  • 1 stars1 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.

What its author says it does

Copied from the file, not written here

Review an existing codebase for redundant, legacy, dead, superseded, or attack-surface-increasing code paths and guide progressive removal with behavior mapping, test coverage, security review, and validation. Use when asked to remove old providers or integrations, clean redundant code paths, reduce tech debt, reduce attack surface, review dead code, retire obsolete routes, remove stale compatibility layers, or clean up after migrations such as Google Drive uploads to Vercel Blob.

SKILL.md

4.7 KB, as published. Nobody here has run it

Codebase Prune Review

Purpose

Use this skill to safely remove obsolete code from an existing repo without losing live functionality. It audits current behavior, classifies removal candidates, proves test coverage, removes in small layers, and validates after each layer.

This is not a generic refactor pass. The goal is to reduce tech debt and attack surface by retiring code paths that are proven superseded, dead, or no longer part of the live product.

Operating Rules

  • Start from current repo truth and live entrypoints. Prefer code, runtime config, package scripts, deployment config, tests, and workflows over historical docs.
  • Build a behavior and ownership map before deleting anything.
  • Classify each candidate as active, compatibility, superseded, dead, or unknown.
  • Do not remove unknown paths until usage is disproven by references, tests, runtime config, logs, or explicit user confirmation.
  • Add or update tests before removing a path when current behavior is not already covered.
  • Remove one coherent layer at a time and run targeted tests after each layer.
  • Keep rollback simple. Do not mix unrelated cleanup, formatting, dependency churn, or feature work into a prune layer.
  • Use $security-threat-model when removals touch auth, uploads, parsers, webhooks, admin paths, secrets, provider clients, storage, payments, or deployment surfaces.
  • Use $test-readiness-preflight before expensive validation and after each removal layer to clear predictable blockers.
  • Use $feature-design-preflight when the prune follows a provider/platform replacement or migration whose new path still needs requirement tracing.

Workflow

  1. Baseline the repo. Read instructions, package scripts, deployment config, routes, jobs, API handlers, provider integrations, env examples, and tests. Use references/discovery-checklist.md.
  2. Map live behavior. List the functionality that must remain unchanged, the entrypoints that serve it, the providers it depends on, and the tests that prove it.
  3. Classify candidates. Mark each old path as active, compatibility, superseded, dead, or unknown. Record evidence for every classification.
  4. Build the proof plan first. Map each behavior to unit, integration, browser/E2E, visual, migration, security, and local/container validation as applicable. Add missing tests before deletion.
  5. Remove progressively. Follow references/removal-layers.md; remove one coherent layer, then run targeted tests. Update docs, env examples, fixtures, workflows, and dependency manifests as obsolete paths disappear.
  6. Validate and report. Run the final local/container gate, dependency audit, containerized repo-scoped gitleaks, and security review when push/readiness is in scope. Use references/evidence-report.md for the completion report.

Classification Rules

  • active: Used by current production behavior, runtime config, route handling, jobs, tests, or documented release flow. Do not remove.
  • compatibility: Preserved intentionally for migrations, old clients, rollback, data backfills, redirects, or external integrations. Keep unless a retirement plan exists.
  • superseded: Replaced by a newer live path and no longer needed after compatibility obligations are satisfied. Remove in a planned layer.
  • dead: No reachable runtime use, tests, config, imports, scripts, or deployment references. Remove once the evidence is recorded.
  • unknown: Usage cannot be proven or disproven. Keep by default and ask for confirmation only after reasonable repo evidence is exhausted.

Example Requests

  • "Use $codebase-prune-review to remove old Google Drive upload paths now that this repo uses Vercel Blob."
  • "Review this repo for superseded provider code and reduce attack surface."
  • "Find legacy compatibility routes and produce a progressive removal plan with tests."
  • "Clean redundant upload, webhook, and storage code after the migration."

References

  • Read references/discovery-checklist.md before proposing removal candidates.
  • Read references/removal-layers.md before editing or deleting code.
  • Read references/evidence-report.md for the behavior map, removal plan, and completion report format.

Keep looking

Skills are one crate of 328,083. 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.