fight-repo-rotlisted

# fight-repo-rot Repos don't break in a day. They rot over months as dead code accumulates, god files grow, hardcoded paths get committed, and six-month-old `TODO`s turn into forever-`TODO`s. This skill surfaces what's rotting — it never edits code. **What this skill is:** a diagnosis, sorted by confidence and leverage, with a pointer to the skill that should handle each finding. **What this skill is not:** an executor. It never deletes, refactors, rewrites, or runs tests. When the operator approves a finding, it hands off to another skill (`refactor-verify` for deletions and restructures, `project-conventions` for config fixes, `audit-security` for CVE dependency rot). This boundary is load-bearing — the moment this skill starts editing, the evidence chain breaks. ## When to trigger - "find dead code" / "what can I delete" - "is any of this unused" - "clean up this repo" / "what's rotting" - "what should I clean up" - "where should I refactor" - "my repo is a mess" - "is my repo okay" (ambiguous — run this as a health check) - before a major new feature (survey the rot first) - before open-sourcing (don't surprise strangers) ## State assumptions — before acting Before starting the procedure, write an explicit Assumptions block. Don't pick silently between interpretations; surface the choice. If any assumption is wrong or ambiguous, pause and ask — do not proceed on a guess. Required block: ``` Assumptions: - Dispatch profile: <static-strict (TypeScript strict, Rust