cruft-cleanup
Use when reviewing or writing refactors, renames, or migrations where old interfaces may linger as aliases, re-exports, wrappers, fallback branches, deprecated flags, or other compatibility cruft. Especially relevant when changed code keeps both old and new paths alive inside the same repo.
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- cruft-cleanup
- metadata
- { "owner": "tze", "status": "active", "authors": [ "tze", "OpenAI Codex" ], "last_reviewed": "2026-06-12" }
- description
- Use when reviewing or writing refactors, renames, or migrations where old interfaces may linger as aliases, re-exports, wrappers, fallback branches, deprecated flags, or other compatibility cruft. Especially relevant when changed code keeps both old and new paths alive inside the same repo.
02 资源文件 4
- 参考文档agents/openai.yaml294 B
- 参考文档references/audit-flow.md1.9 KB
- 参考文档references/compat-boundary.md762 B
- 参考文档references/patterns-to-delete.md1.6 KB
03 SKILL.md 正文
Cruft Cleanup
LLMs preserve old interfaces "just in case." In same-repo refactors, that leaves dead wrappers, aliases, and fallback paths instead of a finished migration.
When refactoring, migrating, or renaming, leave only the new code path unless backward compatibility is explicitly required.
When to Use
- A function, module, type, flag, config key, or CLI option was renamed, moved, or replaced
- A diff keeps both old and new interfaces alive in the same repo
- A refactor adds aliases, re-exports, wrappers, or fallback branches "for compatibility"
- LLM-generated code says some variant of "old path still works"
- Tests were updated incompletely and still exercise the retired interface
Do Not Use This Skill When
- Published APIs with real downstream consumers
- Cross-repo migrations that cannot be completed atomically
- Temporary compatibility layers with a verified owner and removal date
- Residue at architecture scale (layers, abstractions, whole surfaces the spec never needed) rather than one migration's leftovers — greenfield-parity
Core Rule
If you changed it, finish the job. Every callsite, import, reference, and test uses the new interface. Delete the old one — not deprecate, not re-export, not alias.
Catch yourself writing a compatibility alias, wrapper, or fallback? Stop and update the callers instead.
Read Order
| File | Read when | Content |
|---|---|---|
references/audit-flow.md |
Every real use of this skill | Proactive and reactive workflow, grep strategy, and review sequence |
references/patterns-to-delete.md |
You need concrete examples of cruft | Common shim/fallback/tombstone patterns to remove |
references/compat-boundary.md |
You suspect compatibility might be legitimate | Hard boundary for when old interfaces may stay temporarily |
Trigger Sanity Check
- Should trigger: "This rename left a wrapper and old re-export behind so callers still work."
- Should trigger: "Clean up this refactor — I think there are leftover aliases and fallback branches."
- Should not trigger: "We need a planned deprecation layer for an external API consumed by other repos."
04 同仓库更多 Skills
user-run
Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable /home/orca/.tmp/<slug>/run.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: "I'll run it for you", "permission denied on docker.sock", "needs sudo", "sudo: a password is required", "run as tze", "/user-run".
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies