Clean Code
Keep agent-generated code readable and maintainable with SRP, DRY, KISS, YAGNI, naming, and small-function rules without over-commenting.
Overview
Clean-code is a journey-wide agent skill that enforces pragmatic SRP, DRY, KISS, and YAGNI standards—usable whenever a solo builder needs concise, well-named code before committing or merging.
Install
npx skills add https://github.com/davila7/claude-code-templates --skill clean-codeWhat is this skill?
- Five core principles table: SRP, DRY, KISS, YAGNI, and Boy Scout rule
- Naming conventions for variables, functions, booleans, and SCREAMING_SNAKE constants
- Function rules: max 20 lines, one level of abstraction, max 3 arguments, no surprise side effects
- Guard-clause and structure patterns to reduce nesting and clarify intent
- Marked CRITICAL priority: concise, direct, solution-focused agent output with minimal unnecessary comments
- 5 core principles in the standards table (SRP, DRY, KISS, YAGNI, Boy Scout)
- Functions capped at 20 lines with ideally 5–10 lines
- Maximum 3 function arguments (prefer 0–2)
Adoption & trust: 750 installs on skills.sh; 27.8k GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
Agent-assisted coding often produces verbose, over-engineered, or poorly named code that is hard to review and expensive to fix later.
Who is it for?
Solo and indie builders who want a lightweight standards brief loaded into every coding session without running a separate linter skill first.
Skip if: Teams that need formal security/compliance audits, language-specific style guides enforced by CI, or architecture decision records—the skill is general craft, not policy sign-off.
When should I use this skill?
Whenever the agent writes, edits, or refactors code and you want concise, direct output aligned with pragmatic clean-code rules.
What do I get? / Deliverables
Your agent follows shared naming, function-size, and structure rules so new code reads clearly and review cycles stay short.
- Refactored source with improved naming and structure
- Reduced comment noise in favor of self-documenting code
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Shape a new API handler into small, single-purpose functions with clear verb-noun names before wiring routes.
Refactor a React component tree so booleans use is/has/can prefixes and guard clauses replace deep nesting.
Walk a noisy agent diff and apply Boy Scout cleanup without expanding scope.
Patch a production hotfix with minimal arguments and no hidden input mutation.
Keep spike code simple (KISS/YAGNI) so you can throw away or promote without rewrite debt.
How it compares
Use as standing procedural standards in the agent, not as a substitute for automated formatters or dedicated code-review checker skills.
Common Questions / FAQ
Who is clean-code for?
Solo and indie builders and small teams who rely on AI agents for day-to-day implementation and want consistent readability without encyclopedic comment blocks.
When should I use clean-code?
During Build when scaffolding features, during Ship when tightening a PR before merge, and during Operate when patching production—any time the agent writes or refactors application code.
Is clean-code safe to install?
It only guides text edits via Read, Write, and Edit; review the Security Audits panel on this Prism page before enabling in repos with sensitive data.
SKILL.md
READMESKILL.md - Clean Code
# Clean Code - Pragmatic AI Coding Standards > **CRITICAL SKILL** - Be **concise, direct, and solution-focused**. --- ## Core Principles | Principle | Rule | |-----------|------| | **SRP** | Single Responsibility - each function/class does ONE thing | | **DRY** | Don't Repeat Yourself - extract duplicates, reuse | | **KISS** | Keep It Simple - simplest solution that works | | **YAGNI** | You Aren't Gonna Need It - don't build unused features | | **Boy Scout** | Leave code cleaner than you found it | --- ## Naming Rules | Element | Convention | |---------|------------| | **Variables** | Reveal intent: `userCount` not `n` | | **Functions** | Verb + noun: `getUserById()` not `user()` | | **Booleans** | Question form: `isActive`, `hasPermission`, `canEdit` | | **Constants** | SCREAMING_SNAKE: `MAX_RETRY_COUNT` | > **Rule:** If you need a comment to explain a name, rename it. --- ## Function Rules | Rule | Description | |------|-------------| | **Small** | Max 20 lines, ideally 5-10 | | **One Thing** | Does one thing, does it well | | **One Level** | One level of abstraction per function | | **Few Args** | Max 3 arguments, prefer 0-2 | | **No Side Effects** | Don't mutate inputs unexpectedly | --- ## Code Structure | Pattern | Apply | |---------|-------| | **Guard Clauses** | Early returns for edge cases | | **Flat > Nested** | Avoid deep nesting (max 2 levels) | | **Composition** | Small functions composed together | | **Colocation** | Keep related code close | --- ## AI Coding Style | Situation | Action | |-----------|--------| | User asks for feature | Write it directly | | User reports bug | Fix it, don't explain | | No clear requirement | Ask, don't assume | --- ## Anti-Patterns (DON'T) | ❌ Pattern | ✅ Fix | |-----------|-------| | Comment every line | Delete obvious comments | | Helper for one-liner | Inline the code | | Factory for 2 objects | Direct instantiation | | utils.ts with 1 function | Put code where used | | "First we import..." | Just write code | | Deep nesting | Guard clauses | | Magic numbers | Named constants | | God functions | Split by responsibility | --- ## 🔴 Before Editing ANY File (THINK FIRST!) **Before changing a file, ask yourself:** | Question | Why | |----------|-----| | **What imports this file?** | They might break | | **What does this file import?** | Interface changes | | **What tests cover this?** | Tests might fail | | **Is this a shared component?** | Multiple places affected | **Quick Check:** ``` File to edit: UserService.ts └── Who imports this? → UserController.ts, AuthController.ts └── Do they need changes too? → Check function signatures ``` > 🔴 **Rule:** Edit the file + all dependent files in the SAME task. > 🔴 **Never leave broken imports or missing updates.** --- ## Summary | Do | Don't | |----|-------| | Write code directly | Write tutorials | | Let code self-document | Add obvious comments | | Fix bugs immediately | Explain the fix first | | Inline small things | Create unnecessary files | | Name things clearly | Use abbreviations | | Keep functions small | Write 100+ line functions | > **Remember: The user wants working code, not a programming lesson.** --- ## 🔴 Self-Check Before Completing (MANDATORY) **Before saying "task complete", verify:** | Check | Question | |-------|----------| | ✅ **Goal met?** | Did I do exactly what user asked? | | ✅ **Files edited?** | Did I modify all necessary files? | | ✅ **Code works?** | Did I test/verify the change? | | ✅ **No errors?** | Lint and TypeScript pass? | | ✅ **Nothing forgotten?** | Any edge cases missed? | > 🔴 **Rule:** If ANY check fails, fix it before completing. --- ## Verification Scripts (MANDATORY) > 🔴 **CRITICAL:** Each agent runs ONLY their own skill's scripts after completing work. ### Age