Use this skill when reviewing, writing, or refactoring code for cleanliness and maintainability following Robert C. Martin's (Uncle Bob) Clean Code principles. Triggers on code review, refactoring, naming improvements, function decomposition, applying SOLID principles, writing clean tests with TDD, identifying code smells, or improving error handling. Covers Clean Code, SOLID, and test-driven development.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Use this skill when reviewing, writing, or refactoring code for cleanliness and maintainability following Robert C. Martin's (Uncle Bob) Clean Code principles. Triggers on code review, refactoring, naming improvements, function decomposition, applying SOLID principles, writing clean tests with TDD, identifying code smells, or improving error handling. Covers Clean Code, SOLID, and test-driven development.
When this skill is activated, always start your first response with the 🧢 emoji.
Clean Code
Clean Code is a set of principles and practices from Robert C. Martin (Uncle Bob)
for writing software that is readable, maintainable, and expressive. The core idea
is that code is read far more often than it is written, so optimizing for readability
is optimizing for productivity. This skill covers the Clean Code book's principles,
SOLID object-oriented design, and test-driven development - giving an agent the
judgment to write, review, and refactor code the way a disciplined craftsman would.
When to use this skill
Trigger this skill when the user:
Asks to review code for quality, readability, or maintainability
Wants to refactor a function, class, or module to be cleaner
Needs help naming variables, functions, or classes
Asks about SOLID principles or how to apply them
Wants to decompose a large function or class
Asks to identify code smells or technical debt
Wants to write tests using TDD (red-green-refactor)
Needs to improve error handling patterns
Do NOT trigger this skill for:
Performance optimization (clean code prioritizes readability, not speed)
Architecture decisions at the system level (use clean-architecture skills instead)
Key principles
The Boy Scout Rule - Leave the code cleaner than you found it. Every commit
is an opportunity to improve a name, extract a helper, or remove dead code.
Readability is king - Code should read like well-written prose. If a reader
needs to pause and re-read a line, that line needs work. Clever code is bad code.
Single Responsibility at every level - Every function does one thing. Every
class has one reason to change. Every module has one area of responsibility.
Express intent, don't document it - The code itself should explain what and
why. Comments that explain "what" the code does indicate the code failed to
communicate. Reserve comments for "why" something non-obvious was chosen.
Small is beautiful - Functions should be 5-20 lines. Classes should be
small enough to describe in one sentence. Files should fit a mental model.
Core concepts
Clean Code rests on a hierarchy of concerns, from the smallest unit to the largest:
Names are the most fundamental tool. A good name eliminates the need for
comments, makes intent obvious, and prevents misuse. Names should be
intention-revealing, pronounceable, and searchable. See .
references/naming-guide.md
Functions are the building blocks. Each function should do one thing, operate at
one level of abstraction, and have as few arguments as possible. The "stepdown rule"
means code reads top-to-bottom like a newspaper - high-level summary first, details
below.
SOLID principles govern class and module design. They prevent rigid, fragile code
that breaks in unexpected places when changed. See references/solid-principles.md.
Code smells are surface indicators of deeper structural problems. Recognizing
smells is the first step to refactoring. See references/code-smells.md.
Tests are the safety net that enables fearless refactoring. TDD (test-driven
development) ensures tests exist before code and that code is only as complex as
needed. See references/tdd.md.
Common tasks
Review code for Clean Code violations
Walk through the code looking for violations in this priority order:
Naming - Are names intention-revealing? Can you understand the code without reading comments?
Function size - Any function over 20 lines? Does it do more than one thing?
Abstraction levels - Does the function mix high-level logic with low-level detail?
Duplication - Any copy-paste code or structural duplication?
Error handling - Are errors handled with exceptions, not return codes? Any null returns?
Before (violations):
// Check if user can access the resourcefunctioncheck(u, r) {
if (u != null) {
if (u.role == 'admin') {
returntrue;
} elseif (u.perms != null) {
for (let i = 0; i < u.perms.length; i++) {
if (u.perms[i].rid == r.id && u.perms[i].level >= 2) {
returntrue;
}
}
}
}
returnfalse;
}
After (clean):
functioncanUserAccessResource(user, resource) {
if (!user) returnfalse;
if (user.isAdmin()) returntrue;
return user.hasPermissionFor(resource, Permission.READ);
}
Refactor a long function
Apply the Extract Method pattern. Identify clusters of lines that operate at the
same level of abstraction and give them a name.
defprocess_order(order):
validate_order(order)
total = calculate_total(order)
charge_customer(order.customer, total)
send_confirmation(order.customer, total)
Each extracted function is independently readable, testable, and reusable.
Improve naming
Apply these rules by entity type:
Entity
Rule
Bad
Good
Boolean
Should read as a true/false question
flag, status
isActive, hasPermission
Function
Verb + noun, describes action
data(), process()
fetchUserProfile(), validateEmail()
Class
Noun, describes what it is
Manager, Processor
EmailSender, InvoiceCalculator
Collection
Plural noun
list, data
activeUsers, pendingOrders
Constant
Screaming snake case, self-documenting
86400
SECONDS_PER_DAY = 86400
See references/naming-guide.md for the full guide.
Apply SOLID principles
When a class is hard to change, test, or reuse, check it against SOLID:
Single Responsibility - Does this class have more than one reason to change? Split it.
Open/Closed - Can you extend behavior without modifying existing code? Use polymorphism.
Liskov Substitution - Can subtypes replace their parent without breaking things?
Interface Segregation - Are clients forced to depend on methods they don't use? Split the interface.
Dependency Inversion - Do high-level modules depend on low-level details? Inject abstractions.
See references/solid-principles.md for detailed examples and when NOT to apply each.
Write clean tests with TDD
Follow the red-green-refactor cycle:
Red - Write a failing test that defines the desired behavior
Green - Write the minimum code to make it pass
Refactor - Clean up both production and test code
Tests should follow the FIRST principles (Fast, Independent, Repeatable, Self-validating, Timely) and use the Arrange-Act-Assert structure.
See references/tdd.md for the full guide.
Clean up error handling
Replace error codes with exceptions. Never return or pass null.
Before:
publicintwithdraw(Account account, int amount) {
if (account == null) return -1;
if (amount > account.getBalance()) return -2;
account.debit(amount);
return0;
}
// Caller: if (withdraw(acct, 100) == -2) { ... }
After:
publicvoidwithdraw(Account account, int amount) {
Objects.requireNonNull(account, "Account must not be null");
if (amount > account.getBalance()) {
thrownewInsufficientFundsException(account, amount);
}
account.debit(amount);
}
// Caller: try { withdraw(acct, 100); } catch (InsufficientFundsException e) { ... }
Prefer unchecked (runtime) exceptions. Checked exceptions violate the Open/Closed
Principle - a new exception in a low-level function forces signature changes up
the entire call chain.
Anti-patterns / common mistakes
Mistake
Why it's wrong
What to do instead
Over-abstracting
Creating interfaces, factories, and layers for simple problems adds complexity without value
Only abstract when you have a concrete second use case, not "just in case"
Comment-phobia
Deleting ALL comments including genuinely useful "why" explanations
Remove "what" comments, keep "why" comments. Regex explanations and business rule context are valuable
Tiny function obsession
Breaking code into dozens of 2-line functions destroys readability
Extract when a block has a clear name and purpose, not just because it's "long"
Dogmatic SOLID
Creating an interface for every class, even with one implementation
Apply SOLID when you feel the pain of rigidity, not preemptively everywhere
Magic refactoring
Refactoring without tests, hoping nothing breaks
Always have test coverage before refactoring. Write tests first if they don't exist
Naming paralysis
Names so long they hurt readability (AbstractSingletonProxyFactoryBean)
Names should be proportional to scope. Loop variable i is fine; module-level needs more
Test behavior and public contracts, not implementation. Tests should survive refactoring
Gotchas
Refactoring without a safety net - Extract Method and Rename refactors look safe but break things when the surrounding code has implicit coupling, side effects, or no test coverage. Always ensure tests cover the behavior being refactored before making any structural change - even a "trivial" rename.
Over-decomposing into micro-functions - Splitting a 40-line function into 15 two-line helpers makes individual pieces shorter but the flow incomprehensible. Extract only when the extracted block has a name that is more informative than reading the code itself. Length is not the trigger; clarity is.
Applying SOLID to one-off utilities - Adding an interface for a class that has exactly one implementation "to follow Dependency Inversion" introduces indirection without value. Apply SOLID principles when you feel friction from rigidity or testability problems, not preemptively as a ritual.
Comments explaining what, not why - After a refactor, leftover "what" comments that now contradict the code are worse than no comments. They mislead future readers. Delete any comment that describes the operation of code that has since been renamed or restructured to be self-explanatory.
TDD on implementation, not behavior - Writing tests that call private methods or assert on internal state means the tests break every refactor, defeating the purpose of having tests. Test only through public interfaces and observable outputs; the test should survive any internal restructuring.
References
For detailed content on specific topics, read the relevant file from references/:
references/solid-principles.md - Each SOLID principle with examples and when NOT to apply
references/code-smells.md - Catalog of smells with refactoring moves to fix each
references/tdd.md - Three laws of TDD, red-green-refactor, test design patterns
references/naming-guide.md - Detailed naming rules by entity type with examples
Only load a references file if the current task requires deep detail on that topic.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
