just-vibeGeneral · apply by default
/cleanup
Remove verified dead code and unnecessary complexity
Use for evidence-backed removal of unnecessary code or assets; refactor preserves behavior through restructuring; removing a public endpoint or export first needs api-breaking's consumer impact and deprecation plan.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select cleanup from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv cleanup, /just-vibe cleanup and /jv:cleanup in Claude. See shortcut setup and context examples.
/just-vibe:cleanup Remove demonstrably unused checkout helpers; preserve public exports./just-vibe:cleanup Clean dead files while preserving route files discovered by filename./just-vibe:cleanup Identify cleanup candidates without build access; leave uncertain dynamic modules intact.What the agent does
- Find candidates and check static callers, dynamic and configuration references, public exports, framework conventions and runtime registration.
- Remove only a coherent set of supported candidates with a restorable diff, then verify the affected builds and behavior.
Inputs
- directory/change scope and cleanup objective. Requires references, build configuration, and relevant checks.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Demonstrably unused code, stale artifacts, or needless complexity; no behavior redesign.
- Writes
- Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.
- Mode
- Apply; directory/change scope and cleanup objective. Requires references, build configuration, and relevant checks.
- Prerequisites
- Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
Expected output
- Removed or simplified items, each with non-use evidence, and checks for affected consumers.
How the work is checked
- Verified dead code is removed; a dynamically loaded module survives despite lacking static imports.
When to stop or clarify
- Uncertain candidates remain with an explanation. Never delete user data or untracked files merely because they look temporary.
Handling missing context
- Infer
- Resolve the named files, existing scripts, current task and earlier corrections from the conversation and repository.
- Assume
- Use the narrowest interpretation that completes a reversible local task; state a consequential assumption once.
- Ask
- Ask when competing targets or incompatible success conditions would change the result; continue independent inspection first.
Technical guidance
- Evidence
- Locate apparently unused code/assets and inspect static, dynamic, generated and externally documented consumers.
- Method
- Remove only verified dead paths in coherent groups and update references/generated outputs from their source.
- Pitfall
- Static search can miss reflection, routing conventions, plugins or public consumers.
- Check
- Run relevant build/behavior checks and preserve uncertain external API uses rather than deleting them on absence of local references.
Situational decisions
When use cannot be excluded because loading is dynamic: Retain the candidate and name the missing runtime or configuration evidence.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.