Clean code
Agent Skills distilled from Clean Code & Refactoring. Install: npx skills add lifeodyssey/craftsmanship-skills
npx -y skills add lifeodyssey/craftsmanship-skills --skill clean-codeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Routes to Clean Code sub-skills for naming, functions, comments, and error handling based on Robert C. Martin's Clean Code
SKILL.md
1.8 KB, as published. Nobody here has run it
Clean Code
Based on Robert C. Martin's Clean Code: A Handbook of Agile Software Craftsmanship.
When to Use This Skill
Trigger on:
- Code review requests mentioning "clean code", "readability", "naming", "comments"
- Writing new functions, classes, or modules
- Refactoring existing code for clarity
- Debates about naming conventions, function length, or comment density
Do NOT trigger on:
- Architecture or system design (use architecture skills)
- Performance optimization (use optimization skills)
- Refactoring code smells (use refactoring skills)
- Debugging runtime errors (use systematic-debugging)
Sub-Skills
| Topic | Skill | Use When |
|---|---|---|
| Naming | clean-code:naming | Variables, functions, classes, modules need clear names |
| Functions | clean-code:functions | Designing or reviewing function size, arguments, structure |
| Comments | clean-code:comments | Deciding when/how to comment code |
| Error Handling | clean-code:error-handling | Designing exception strategy and error boundaries |
Core Principles
- Clean code reads like well-written prose -- every line expresses intent
- Functions should be small -- then smaller; rarely > 20 lines
- Names reveal intent -- if a name requires a comment, it is not descriptive enough
- Comments are apologies -- fix the code first, then comment only what cannot be made obvious
- Error handling is not optional -- wrap errors at boundaries, never swallow exceptions silently
- Boy Scout Rule -- leave the code cleaner than you found it
Source
Distilled from Clean Code by Robert C. Martin. Full extracted content: output/clean-code/SKILL.md.