legacy-cleanup

Estrellas8

Forks3

Actualizado9 de junio de 2026 a las 19:23

Reachability-based classification of dead, duplicated, stale, or migration-leftover code before deletion, with quarantine/delete decisions and validation. Use when removing dead code, deleting unused files, deduplicating implementations, or deciding whether code is stale, unused, reachable, or safe to remove. Not for general refactoring of live code (use implementation-discipline).

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

1ikeadragon

1ikeadragon/slopflow

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	legacy-cleanup
description	Reachability-based classification of dead, duplicated, stale, or migration-leftover code before deletion, with quarantine/delete decisions and validation. Use when removing dead code, deleting unused files, deduplicating implementations, or deciding whether code is stale, unused, reachable, or safe to remove. Not for general refactoring of live code (use implementation-discipline).
version	2.0.0

Legacy Cleanup

Act as legacy-cleaner. Identify dead, duplicated, stale, misleading, or migration-leftover code without breaking active behavior. Do not clean based on aesthetics, and do not infer reachability from names: active production code may look ugly, legacy-looking code may be reachable, and polished code may be unused.

Classification

Classify each target as one of:

active-production / active-dev-tooling / test-only / generated-vendor /
legacy-but-reachable / dead-likely / dead-confirmed / uncertain

Use dead-confirmed only when entrypoint, reference, config, test, export, and deployment checks all support removal.

Cleanup Workflow

Find references and imports (direct and dynamic), then trace from known entrypoints.
Check runtime registration, config references, framework auto-discovery, and dependency injection bindings.
Check tests and fixtures, package exports and public API, and build/deploy scripts (including scripts that reference paths dynamically).
Document assumptions and gotchas.
Only then recommend deletion, quarantine, migration, or leaving it alone.

Use broad search first, then narrow. Prefer executable wiring over comments and names; check documentation only after executable wiring.

Removal Safety

Before deleting anything, check: public API exports and hidden consumers, generated-code regeneration, tests or fixtures that encode edge cases, docs or examples that carry useful signal, migration rollback paths, and config variants that still select the code. If uncertainty remains, prefer quarantine or a deprecation marker over deletion.

Cleanup can remove signal. When removing or quarantining examples, tests, fixtures, docs, edge-case coverage, or migration notes, state how to preserve the useful signal first.

Duplicate Implementations

When duplicate old/new logic exists: identify all implementations; determine which are reachable from production entrypoints; check config or feature flags that select between them; compare behavior and edge cases; recommend consolidation only after preserving active behavior. Do not assume the newest or cleanest implementation is active.

Output

Target:
Classification:
How I figured it out:
Evidence / references:
Assumptions / gotchas:
Risk if removed:
Recommendation: delete / quarantine / leave / migrate / add deprecation marker
Validation needed:

Anti-Patterns

deletion from vibes, or because a filename says legacy, or because tests do not mention it
deletion of exported public API without consumer checks
broad cleanup during narrow feature work
hiding uncertainty to make cleanup look cleaner

Más de este repositorio

mismo repositorio

agent-system-design

1ikeadragon/slopflow

Design, review, or improve agentic systems with LLM loops, tools, memory/state, handoffs, subagents, guardrails, tracing, evaluations, or agent prompts. Use for agent architecture, agent implementation plans, prompt/skill design for agents, tool-contract design, multi-agent vs single-agent decisions, production-readiness reviews, and avoiding no-op agent instructions.

2026-06-258

data-validation

1ikeadragon/slopflow

Programmatically validate datasets, parsed records, tables, CSV/JSON/YAML/XML/log outputs, benchmark outputs, metric reports, matrix results, counts, percentages, joins, migrations, exports, imports, and any claim that depends on data being read correctly. Use when the user asks to validate data, verify numbers, check parsing, compare expected vs actual data, audit metrics/results, or confirm that nothing was misread.

2026-06-258

implementation-discipline

1ikeadragon/slopflow

The coding workflow for any change that edits code or configuration scope calibration, implementation plan, plan audit, validation, and post-implementation audit. Use when implementing, fixing, adding, updating, or refactoring. Not for deciding whether code is safe to delete use legacy-cleanup or for review of someone else's change use code-review-discipline.

2026-06-248

secure-design

1ikeadragon/slopflow

Threat-model a code, configuration, infrastructure, auth, data, cryptography, networking, or dependency change by decomposing it into application sub-components and applying each one's threat lens and controls. Use when building or modifying a feature with security in scope, or when the global Security Gate is accepted. Not for incident investigation (use rca-investigation) or for writing security tests alone (use adversarial-test-design).

2026-06-108

workflow-rca

1ikeadragon/slopflow

Runtime evidence collection for workflow and CI incidents workflow run ids, CI job ids, GCP Cloud Logging queries, GCS artifact lookup, workflow DB artifacts, cache hit/miss proof, and worker behavior. Use when the input is a run identifier or a question about why a workflow failed, retried, slowed down, loaded cache, or built fresh. This skill gathers and proves runtime facts, hand its evidence packet to rca-investigation for the cumulative code-level root cause.

2026-06-108

reasoning-discipline

1ikeadragon/slopflow

The reasoning spine for non-trivial, ambiguous, open-ended, or high-stakes work frame the problem, generate structurally different options, verify load-bearing claims, diagnose with competing hypotheses, evaluate against weighted criteria, decide under uncertainty, and synthesize — executed via mode files read one at a time with a todo ledger. Also holds the metric/oracle audit and meta-reasoning checks behind Core Rules 9-10. Use for design decisions, tradeoffs, "which approach" questions, planning, and before reporting any count, cost, accuracy, or pass/fail number. Engage on your own when the work warrants it; skip for trivial or mechanical tasks.

2026-06-098

name	legacy-cleanup
description	Reachability-based classification of dead, duplicated, stale, or migration-leftover code before deletion, with quarantine/delete decisions and validation. Use when removing dead code, deleting unused files, deduplicating implementations, or deciding whether code is stale, unused, reachable, or safe to remove. Not for general refactoring of live code (use implementation-discipline).
version	2.0.0

Legacy Cleanup

Classification

Classify each target as one of:

active-production / active-dev-tooling / test-only / generated-vendor /
legacy-but-reachable / dead-likely / dead-confirmed / uncertain

Use dead-confirmed only when entrypoint, reference, config, test, export, and deployment checks all support removal.

Cleanup Workflow

Find references and imports (direct and dynamic), then trace from known entrypoints.
Check runtime registration, config references, framework auto-discovery, and dependency injection bindings.
Check tests and fixtures, package exports and public API, and build/deploy scripts (including scripts that reference paths dynamically).
Document assumptions and gotchas.
Only then recommend deletion, quarantine, migration, or leaving it alone.

Use broad search first, then narrow. Prefer executable wiring over comments and names; check documentation only after executable wiring.

Removal Safety

Cleanup can remove signal. When removing or quarantining examples, tests, fixtures, docs, edge-case coverage, or migration notes, state how to preserve the useful signal first.

Duplicate Implementations

Output

Target:
Classification:
How I figured it out:
Evidence / references:
Assumptions / gotchas:
Risk if removed:
Recommendation: delete / quarantine / leave / migrate / add deprecation marker
Validation needed:

Anti-Patterns

deletion from vibes, or because a filename says legacy, or because tests do not mention it
deletion of exported public API without consumer checks
broad cleanup during narrow feature work
hiding uncertainty to make cleanup look cleaner