clean-code
clean code
What it does
- 9-10: Names reveal intent, functions are small and focused, error handling is consistent, tests are clean and comprehensive
- 7-8: Mostly clean with minor naming ambiguities or a few long functions; tests may lack edge cases
- 5-6: Mixed — good patterns alongside unclear names, duplicated logic, or inconsistent error handling
- 3-4: Long multi-purpose functions, misleading names, poor or missing tests
- 1-2: Nearly unreadable — magic numbers, cryptic abbreviations, no structure, no tests
- A name should answer why it exists, what it does, and how it is used
- No encodings, prefixes, or type information (no Hungarian notation); single letters only for tiny-scope loop counters
Requirements & configuration
- Core concept: Names should reveal intent, avoid disinformation, and make the code read like prose. If a name requires a comment to explain it, the name is wrong.
- Why it works: Names are the most pervasive form of documentation — a well-chosen name eliminates the need to read the implementation; a poor one forces every reader to reverse-engineer intent.
- Argument count: zero best, one fine, two acceptable, three+ requires justification
- | Explaining "why" | Keep as comment | // RFC 7231 requires this header for proxies |
- Define exception classes by the caller's needs, not the failure type
Configuration: MAX_LOGIN_ATTEMPTS
Derived from the skill's own SKILL.md documentation · extracted 2026-07-23
clean-code FAQ
What does the clean-code skill do?
Write readable, maintainable code through disciplined naming, small functions, and clean error handling. Use when the user mentions "clean up this code", "this function is too long", "code smells", "naming conventions", "boy scout rule", "single responsibility", or "unit test quality". Also trigger when reviewing a pull request for readability, untangling a messy function, debating comment styles, or improving error-handling patterns. Covers SRP, comment discipline, formatting, and unit testing. For refactoring techniques, see refactoring-patterns. For architecture and dependency rules, see clean-architecture. 9-10: Names reveal intent, functions are small and focused, error handling is consistent, tests are clean and comprehensive 7-8: Mostly clean with minor naming ambiguities or a few long functions; tests may lack edge cases
What does clean-code require?
Core concept: Names should reveal intent, avoid disinformation, and make the code read like prose. If a name requires a comment to explain it, the name is wrong. Why it works: Names are the most pervasive form of documentation — a well-chosen name eliminates the need to read the implementation; a poor one forces every reader to reverse-engineer intent. Argument count: zero best, one fine, two acceptable, three+ requires justification | Explaining "why" | Keep as comment | // RFC 7231 requires this header for proxies | Define exception classes by the caller's needs, not the failure type Configuration keys: MAX_LOGIN_ATTEMPTS.
How do I install clean-code?
Run: npx -y skills add https://github.com/wondelai/skills --skill clean-code --agent claude-code — the source lives at github.com/wondelai/skills.
Maintain clean-code?
Let people know it's listed here — add the badge (live metrics, light/dark aware) or a plain link to your README or docs.
[clean-code on getagentictools](https://getagentictools.com/skills/wondelai-skills-clean-code?ref=badge) npx agentictools info skills/wondelai-skills-clean-code The second line is the CLI lookup for this page — handy in READMEs and docs.
