{
  "schema": "https://ai-atoms.com/schemas/skill-v1.json",
  "type": "skill",
  "id": "skill/clean-code",
  "version": "1.0.0",
  "name": "Clean Code",
  "description": "Applies principles from Robert C. Martin's 'Clean Code'. Use this skill when writing, reviewing, or refactoring code to ensure high quality, readability, and maintainability. Covers naming, functio...",
  "system_prompt_fragment": "# Clean Code Skill\n\nThis skill embodies the principles of \"Clean Code\" by Robert C. Martin (Uncle Bob). Use it to transform \"code that works\" into \"code that is clean.\"\n\n## 🧠 Core Philosophy\n> \"Code is clean if it can be read, and enhanced by a developer other than its original author.\" — Grady Booch\n\n## When to Use\nUse this skill when:\n- **Writing new code**: To ensure high quality from the start.\n- **Reviewing Pull Requests**: To provide constructive, principle-based feedback.\n- **Refactoring legacy code**: To identify and remove code smells.\n- **Improving team standards**: To align on industry-standard best practices.\n\n## 1. Meaningful Names\n- **Use Intention-Revealing Names**: `elapsedTimeInDays` instead of `d`.\n- **Avoid Disinformation**: Don't use `accountList` if it's actually a `Map`.\n- **Make Meaningful Distinctions**: Avoid `ProductData` vs `ProductInfo`.\n- **Use Pronounceable/Searchable Names**: Avoid `genymdhms`.\n- **Class Names**: Use nouns (`Customer`, `WikiPage`). Avoid `Manager`, `Data`.\n- **Method Names**: Use verbs (`postPayment`, `deletePage`).\n\n## 2. Functions\n- **Small!**: Functions should be shorter than you think.\n- **Do One Thing**: A function should do only one thing, and do it well.\n- **One Level of Abstraction**: Don't mix high-level business logic with low-level details (like regex).\n- **Descriptive Names**: `isPasswordValid` is better than `check`.\n- **Arguments**: 0 is ideal, 1-2 is okay, 3+ requires a very strong justification.\n- **No Side Effects**: Functions shouldn't secretly change global state.\n\n## 3. Comments\n- **Don't Comment Bad Code—Rewrite It**: Most comments are a sign of failure to express ourselves in code.\n- **Explain Yourself in Code**: \n  ```python\n  # Check if employee is eligible for full benefits\n  if employee.flags & HOURLY and employee.age > 65:\n  ```\n  vs\n  ```python\n  if employee.isEligibleForFullBenefits():\n  ```\n- **Good Comments**: Legal, Informative (regex intent), Clarification (external libraries), TODOs.\n- **Bad Comments**: Mumbling, Redundant, Misleading, Mandated, Noise, Position Markers.\n\n## 4. Formatting\n- **The Newspaper Metaphor**: High-level concepts at the top, details at the bottom.\n- **Vertical Density**: Related lines should be close to each other.\n- **Distance**: Variables should be declared near their usage.\n- **Indentation**: Essential for structural readability.\n\n## 5. Objects and Data Structures\n- **Data Abstraction**: Hide the implementation behind interfaces.\n- **The Law of Demeter**: A module should not know about the innards of the objects it manipulates. Avoid `a.getB().getC().doSomething()`.\n- **Data Transfer Objects (DTO)**: Classes with public variables and no functions.\n\n## 6. Error Handling\n- **Use Exceptions instead of Return Codes**: Keeps logic clean.\n- **Write Try-Catch-Finally First**: Defines the scope of the operation.\n- **Don't Return Null**: It forces the caller to check for null every time.\n- **Don't Pass Null**: Leads to `NullPointerException`.\n\n## 7. Unit Tests\n- **The Three Laws of TDD**:\n  1. Don't write production code until you have a failing unit test.\n  2. Don't write more of a unit test than is sufficient to fail.\n  3. Don't write more production code than is sufficient to pass the failing test.\n- **F.I.R.S.T. Principles**: Fast, Independent, Repeatable, Self-Validating, Timely.\n\n## 8. Classes\n- **Small!**: Classes should have a single responsibility (SRP).\n- **The Stepdown Rule**: We want the code to read like a top-down narrative.\n\n## 9. Smells and Heuristics\n- **Rigidity**: Hard to change.\n- **Fragility**: Breaks in many places.\n- **Immobility**: Hard to reuse.\n- **Viscosity**: Hard to do the right thing.\n- **Needless Complexity/Repetition**.\n\n## 🛠️ Implementation Checklist\n- [ ] Is this function smaller than 20 lines?\n- [ ] Does this function do exactly one thing?\n- [ ] Are all names searchable and intention-revealing?\n- [ ] Have I avoided comments by making the code clearer?\n- [ ] Am I passing too many arguments?\n- [ ] Is there a failing test for this change?",
  "applicable_domains": [
    "other"
  ],
  "category": "other",
  "invocation": [
    "/clean-code"
  ],
  "authored_by": "claudeskills.in community",
  "source_url": "https://claudeskills.in/skill/clean-code",
  "provenance": {
    "source": "claudeskills.in",
    "source_url": "https://claudeskills.in/skill/clean-code",
    "license": "unknown",
    "imported_at": "2026-09-03",
    "notes": "Aggregated by claudeskills.in from community GitHub lists. Upstream as recorded by the aggregator: ClawForge (https://github.com/jackjin1997/ClawForge)."
  },
  "tags": [
    "claudeskills",
    "other",
    "risk-reviewed"
  ],
  "lifecycle": "draft"
}