vibe-code-cleaner

Report-only — analyze code (stack/conventions), then list what would be cleaned (format, noise, dead code, naming, structure). No edits applied.

# Vibe check

## Trigger

The user runs `/vibe-check` or asks for a "vibe check" or "what would you clean" without applying changes.

## Principle

Same **analyze-first, stack-agnostic** approach as vibe-clean, but **no edits** — only report what would be done.

## Workflow

1. **Analyze first:** Detect language, file type, and project conventions from the file/repo (same as vibe-clean).
2. **Scope:** Current file, selection, or user-specified scope.
3. **Run the same checks** as vibe-clean: format, noise, dead code, naming, structure. For each finding: **location** (file, line/region), **issue**, and **suggested change**.
4. **Output:** A **vibe report** listing all findings by category (Format, Noise, Dead code, Naming, Structure) with file/line and suggestion. End with a one-line summary (e.g. "Would clean 8 items: 3 format, 2 noise, 2 dead code, 1 naming."). Do **not** apply any edits.
5. **Tone:** Friendly and concise. Optionally add "Run `/vibe-clean` to apply these changes."

## Guardrails

- Do not modify any files. Report only.
- Infer stack and conventions from the code; do not assume a tech stack.

Full cleanup — analyze code (stack/conventions) first, then refactor format, noise, dead code, naming, structure; apply changes and output a vibe report. Stack-agnostic.

# Vibe clean

## Trigger

The user runs `/vibe-clean` or asks to clean, tidy, or refactor dirty code (current file, selection, or specified scope).

## Principle

**Stack-agnostic:** Always analyze the code first (language, file type, repo conventions), then apply cleanups appropriate to that context. Do not assume a specific tech stack.

## Workflow

### 1. Analyze first

- Detect **language** and **file type** from extension and syntax (e.g. JS/TS, Python, Go, Ruby, Java, C#, etc.).
- Infer **project conventions** from the file and repo: indentation (spaces/tabs, 2 vs 4), quotes, semicolons, line length, naming style (camelCase, snake_case, etc.), import/export style.
- Determine **scope**: current file, selection, or user-specified files. Default to current file or selection.

### 2. Format

- Normalize **indentation** to match project (spaces or tabs, width).
- Normalize **quotes** and **semicolons** to project style.
- Remove **trailing spaces** and **extra blank lines**; respect reasonable **line length** if the project shows a pattern.
- Apply formatting consistently across the scope.

### 3. Noise

- Identify **stray debug code**: `console.*`, `debugger`, temporary `print`/logging not meant for production. Remove or gate behind env/flag; prefer removal when clearly debug-only.
- Flag **commented-out code blocks**; suggest removal (or move to version control/docs).
- Surface **TODOs/FIXMEs** that look like pre-ship cleanup; suggest resolving or tracking in issues.

### 4. Dead code

- **Unused imports** — remove.
- **Unused variables** and **unreachable code** in scope — remove or suggest removal.
- **Unused functions** (e.g. local helpers never called) — suggest removal or document why kept.

Adapt detection to the language (e.g. import syntax in Python vs JS/TS vs Go).

### 5. Naming

- Flag **unclear or generic names** (e.g. `x`, `temp`, `data2`, `foo`) and suggest **clearer, descriptive names**.
- Apply renames when safe (same file or clearly scoped); ensure references are updated.

### 6. Structure

- Identify **very long functions** or **large files**; suggest splitting or extracting (e.g. extract helper, split into smaller functions).
- Identify **obvious duplication** (same logic in multiple places); suggest extracting to a shared function or constant and apply when straightforward.
- Keep changes **small and safe**; avoid large architectural refactors.

### 7. Consistency

- Ensure all applied cleanups **match inferred project conventions** (same quotes, same indent, same naming style).
- When in doubt, preserve existing style rather than introducing a new one.

### 8. Vibe report and apply

- Produce a short **vibe report**: what was analyzed (language, scope), what was changed (format, noise, dead code, naming, structure), and a one-line summary (e.g. "Cleaned 5 format issues, removed 2 unused imports, renamed 3 variables, extracted 1 helper.").
- **Apply** the refactors (edit the file(s)); do not only suggest unless the user asked for report-only (then use vibe-check instead).
- Keep the report **friendly and concise** (vibe coder tone).

## Guardrails

- Do not introduce logic changes or bug "fixes"; only clean and refactor structure/format/naming/dead code.
- Do not assume a single tech stack; infer from the code every time.
- If the scope is large (many files), process in a sensible order or ask the user to narrow scope.
- Preserve behavior; refactors must be semantics-preserving.

## Output

- Edited file(s) with cleanups applied.
- Short vibe report (scope, language, list of changes, one-line summary).

Run vibe-check — report what would be cleaned (format, noise, dead code, naming, structure) with no edits applied.

Run the **vibe-check** skill. Default scope: current file or selection. Analyze the code (stack-agnostic), then output a vibe report listing all suggested cleanups by category. Do not apply any edits.

When the user asks to clean, tidy, or vibe-check code, run the vibe-clean skill (or vibe-check for report-only). Prefer project style; keep suggestions friendly and concise.

# Vibe clean conventions

When the user asks to "clean this code," "tidy up," "vibe check," "refactor this dirty code," or "run vibe clean," run the **vibe-clean** skill (or **vibe-check** if they want a report only with no edits). Infer language and project conventions from the codebase first; apply cleanups that match the project's style. Keep the tone friendly and concise (vibe coder style).

Run the full vibe-clean workflow — analyze code (stack-agnostic), refactor format/noise/dead code/naming/structure, apply changes, and output a vibe report.

Run the **vibe-clean** skill. Default scope: current file or selection. Analyze the code first (language and conventions), then apply all cleanups (format, noise, dead code, naming, structure) and output a short vibe report.