Code Cleanup

Use this skill to make existing code easier to read, safer to maintain, and more consistent with the surrounding project without changing what it does.

Core Rules

• Preserve behavior. Treat bug fixes, feature changes, and public API changes as separate work unless the user explicitly includes them.
• Follow the repository's local conventions before generic style preferences. Read relevant project instructions, nearby code, package scripts, and config files before editing.
• Keep scope tight. Prefer recently changed files, staged hunks, or the specific files the user named.
• Protect user work. Inspect git status before edits and do not revert or overwrite unrelated changes.
• Validate proportionally. Run the most relevant existing tests, type checks, linters, or formatters for touched code. If a validation command is unavailable or too broad for the change, say so.
• Avoid cleanup that is only personal taste. A change should improve intent, reduce real complexity, remove duplication, or align with established project patterns.

Scope Modes

• Staged cleanup: default when staged changes exist and the user asks for pre-commit cleanup. Review git diff --cached and edit only files represented in the staged work unless the user allows propagation.
• Changed-file cleanup: use when there are no staged changes or the user asks for uncommitted work. Review git diff plus named files or recent edits.
• Targeted cleanup: use for explicit files, directories, symbols, or a commit SHA. Keep edits inside that target unless a dependency update is required.
• Full-file cleanup: use only when the user asks for a deeper pass. Keep behavior stable and validate more broadly.