What if a fix changes behavior?

If a fix changes behavior (not just style), flag it to the user before applying.

What if make clean-code fails?

Investigate and fix the remaining issues manually; do NOT leave any warnings unresolved, then re-run to verify zero warnings and zero errors.

clean-code

npx machina-cli add skill flurdy/agent-skills/clean-code --openclaw

Files (1)

SKILL.md

1.2 KB

Clean Code

Format, lint, and fix all warnings across the entire codebase — including test files and pre-existing issues.

Usage

/clean-code

Instructions

1. Run the project's clean-code target

Each project defines a make clean-code Makefile target with the appropriate tooling for its language/stack.

make clean-code

2. Fix remaining issues

If make clean-code fails or reports warnings/errors that couldn't be auto-fixed, investigate and fix them manually. Do NOT leave any warnings unresolved.

3. Verify clean state

Re-run the target to confirm it passes cleanly:

make clean-code

It must exit with zero warnings and zero errors.

Rules

Do not skip or suppress warnings (e.g. eslint-disable, #[allow(...)], @SuppressWarnings) unless there is a genuine false positive with a clear justification
Do not change the project's formatter or linter configuration
If a fix changes behavior (not just style), flag it to the user before applying
Test files are in scope — do not skip them
Pre-existing issues must be fixed, not just new code

Source

git clone https://github.com/flurdy/agent-skills/blob/main/skills/clean-code/SKILL.mdView on GitHub

Overview

Clean Code standardizes the repository by running the project’s clean-code target. It covers the entire codebase, including test files, and ensures pre-existing issues are fixed so there are zero warnings and zero errors before merging.

How This Skill Works

Each project defines a make clean-code target with tooling appropriate for its language. You run make clean-code to auto-format and lint, then fix any remaining issues manually (do NOT leave warnings unresolved), and re-run the target to verify a clean state, including test files as part of the scope.

When to Use It

Before opening a pull request to merge, to ensure the codebase is clean and consistent.
When onboarding a new language/tooling setup, to establish a reliable baseline.
After dependency updates that may introduce new warnings or lint issues.
During legacy repo cleanup to fix pre-existing issues, not just new code.
If CI flags warnings or errors, to reproduce locally and address them.

Quick Start

Step 1: Run make clean-code to format and lint the entire codebase.
Step 2: If warnings/errors appear, fix them manually and do not leave issues unresolved.
Step 3: Re-run make clean-code to confirm zero warnings and zero errors.

Best Practices

Always run make clean-code and review its effects before committing.
Prefer auto-fixes when safe, but verify any changes that alter behavior and flag them before applying.
Do not disable formatters or linters (no suppression unless there’s a justified false positive).
Include test files in the cleanup scope; tests must be clean too.
Document and justify any false positives or edge cases you encounter; fix pre-existing issues, not just new code.

Example Use Cases

A JavaScript/TypeScript project using ESLint and Prettier with a dedicated make clean-code target.
A Python repo with Black, flake8, and mypy integrated into the clean-code workflow.
A Go project using gofmt and golangci-lint wired into make clean-code.
A Java project employing Checkstyle/Spotless as part of the clean-code target.
A C/C++ project using clang-format and clang-tidy invoked via make clean-code.

Frequently Asked Questions

Add this skill to your agents