Specs Code Cleanup
Install this after review approval to strip debug noise, dead code, and messy imports without changing behavior.
Overview
specs-code-cleanup is an agent skill for the Ship phase that performs post-approval hygiene cleanup—debug removal, import order, and formatter runs—without changing program logic.
Install
npx skills add https://github.com/giuseppe-trisciuoglio/developer-kit --skill specs-code-cleanupWhat is this skill?
- Removes debug logs, temporary comments, and dead code after approval
- Language-specific formatters: Spotless/Checkstyle, Prettier/ESLint, Black/Ruff
- Grep recipes for console.log, System.out.println, and Python print traces
- Import ordering rules for Java and TypeScript module paths
- Explicitly not for refactoring logic or bug fixes—hygiene only
- Formatter table covers Java, TypeScript, and Python toolchains
- Documented Grep patterns for console.log, DEBUG comments, System.out.println, and print(
Adoption & trust: 731 installs on skills.sh; 271 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Review passed but the branch still has debug prints, TODO noise, and messy imports that will embarrass you at merge time.
Who is it for?
After explicit review approval when you want an agent to run grep-driven hygiene and project formatters across Java, TypeScript, or Python repos.
Skip if: Fixing failing tests, refactoring algorithms, or debugging incorrect behavior—the skill excludes logic changes by design.
When should I use this skill?
After task review approval when asked to clean up, polish, finalize, tidy up, or remove technical debt—not for refactoring logic or bug fixes.
What do I get? / Deliverables
Approved tasks leave behind formatter-clean files with optimized imports and no casual debug or dead code, ready to merge or tag.
- Formatter- and linter-clean source files
- Imports ordered per language conventions
- Debug and dead-code removals without behavior changes
Recommended Skills
Journey fit
How it compares
Post-review polish workflow—not a substitute for code review, static analysis, or feature implementation skills.
Common Questions / FAQ
Who is specs-code-cleanup for?
Solo and indie developers using spec-driven workflows who want a final agent pass after review without risking semantic refactors.
When should I use specs-code-cleanup?
In Ship review after approval, when preparing a PR or release branch for merge and you need debug logs removed and formatters run—not while bugs are still open.
Is specs-code-cleanup safe to install?
It can run shell formatters and edit files; verify scope in your agent config and check the Security Audits panel on this Prism page before use on production codebases.
SKILL.md
READMESKILL.md - Specs Code Cleanup
# Language-Specific Cleanup Patterns Reference for language-specific formatter commands, import ordering, and search patterns. ## Formatters & Linters | Language | Format | Lint | |----------|--------|------| | Java | `./mvnw spotless:apply` | `./mvnw checkstyle:check spotless:check` | | TypeScript | `npm run format` / `npx prettier --write` | `npm run lint` / `npx eslint --fix` | | Python | `black .` / `ruff format` | `ruff check . && black --check .` | ## Import Ordering **Java**: `java.*` → `jakarta.*`/`javax.*` → third-party → project imports **TypeScript**: external libraries → internal absolute (`@/...`) → internal relative (`./...`) ## Common Search Patterns Use Grep to find technical debt: ```bash # JavaScript/TypeScript grep -rn "console.log" --include="*.ts" --include="*.tsx" [files] grep -rn "// DEBUG:" --include="*.ts" [files] # Java grep -rn "System.out.println" --include="*.java" [files] # Python grep -rn "print(" --include="*.py" [files] ``` --- name: specs-code-cleanup description: "Provides final code cleanup after task review approval. Removes debug logs, temporary comments, dead code, optimizes imports, and improves readability. Use when asked to clean up code, polish, finalize, tidy up, remove technical debt, or prepare code for completion after review. Not for refactoring logic or fixing bugs—focused solely on cosmetic and hygiene cleanup." allowed-tools: Task, Read, Write, Edit, Bash, Grep, Glob, TodoWrite, AskUserQuestion --- # Code Cleanup ## Overview Performs post-review cosmetic cleanup to make code production-ready. This workflow is now integrated as Phase T-7 of `/developer-kit-specs:specs.task-implementation`. It can also be invoked manually using `--action=cleanup`. **Input**: `docs/specs/[id]/tasks/TASK-XXX.md` (reviewed status) **Output**: Cleaned code, task marked `completed` ## When to Use - Use when asked to clean up code, polish, finalize, tidy up, or remove technical debt after review approval. - Use to prepare code for completion: remove debug logs, dead code, optimize imports, and improve readability. - Use as the final quality gate in the specification-driven development workflow. - Not for refactoring logic or fixing bugs — focused solely on cosmetic and hygiene cleanup. ## Arguments | Argument | Required | Description | |----------|----------|-------------| | `--lang` | No | `java`, `spring`, `typescript`, `nestjs`, `react`, `python`, `general` | | `--task` | Yes | Path to task file | | `--action`| No | Set to `cleanup` for manual invocation | ## Best Practices - **Clean, not change**: Only remove or reorganize — never change functionality - **Preserve behavior**: Code must work exactly the same after cleanup - **Use project tools**: Prefer `./mvnw spotless:apply`, `npm run lint:fix`, `black`, etc. - **Use TodoWrite**: Track progress through all 8 phases - **Stop on failure**: If tests fail, stop and report — do not proceed See `references/language-patterns.md` for language-specific formatter commands, import ordering, and grep patterns. ## Instructions ### Phase 1: Task Verification 1. Parse `$ARGUMENTS` for parameters: - `--lang` (optional): Target language/framework - `--task` (required): Task ID or file path - `--spec` (optional): Spec folder path (used with task ID) **Support two formats**: - Format 1 (direct path): `--task=docs/specs/001-feature/tasks/TASK-001.md` - Format 2 (spec+task): `--spec=docs/specs/001-feature --task=TASK-001` If Format 2 is used, construct the task file path as: `{spec}/tasks/{task}.md` 2. Read the task file. Verify: - Status is `reviewed` or `implemented` (not `completed`) - Review report `TASK-XXX--review.md` exists and is approved 3. If not reviewed → stop and tell user to run `/developer-kit-specs:specs.task-review` first 4. Extract task ID, title, and `provides` files ### Phase 2: Identify Files to Clean 1. Read `TASK-XXX--review.md` for files created/modified 2. Read task `provides