New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Clean Code

by techygarg in techygarg/lattice

Apply clean code principles when generating or modifying implementation code.

MITAuto-check passedDevelopment

Install Clean Code

skills CLI
$ npx skills add techygarg/lattice --skill clean-code -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install techygarg/lattice clean-code --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/techygarg/lattice.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/clean-code .claude/skills/clean-code && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
clean-code
GitHub stars
198
Token cost
~1.6k tokens
SKILL.md length
799 words
Files
2 (incl. references)
Skills in repo
33
Repo updated
First seen
Licence
MIT

At a glance

Apply clean code principles when generating or modifying implementation code.

  • Works in 6 steps: Read .lattice/config.yaml in the repo… → If found, check paths.clean_code for a… → If a custom document exists at that… → …
  • The user mentions clean code
  • SKILL.md covers Config Resolution, Self-Validation Checklist, Active Anti-Pattern Scan and Ambiguity Signals
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Clean Code is an agent skill from techygarg/lattice. Apply clean code principles when generating or modifying implementation code. Enforces function focus, naming clarity, complexity management, error handling, and self-documenting style. Use when the user mentions 'clean code', 'code quality', 'coding guidelines', or 'implementation quality'. Loaded automatically by the code-generating molecules (code-forge, refactor-safely, bug-fix). This skill governs the craft of writing individual code units -- not architecture (see architecture), not security posture (see…

Its SKILL.md is about 1.6k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/defaults.md`).

It sits in Development, covering Code quality and Refactoring. The repository describes itself as: Install engineering discipline into any AI coding assistant. Composable skills for design, implementation, review, and team standards. Better process, not just better prompts. The licence is MIT.

When your agent uses it

  • The user mentions clean code
  • Coding guidelines
  • Implementation quality

Example prompts

  • “clean code”
  • “code quality”
  • “coding guidelines”
  • “/clean-code”

Workflow steps

6 steps, taken from the first numbered list in SKILL.md.

  1. Read .lattice/config.yaml in the repo root.
  2. If found, check paths.clean_code for a custom document path.
  3. If a custom document exists at that path, read it and check its YAML frontmatter for mode
  4. If a custom path is configured but no document exists at it → tell the user which configured path is missing, then fall back to…
  5. If there is no config file or no paths.clean_code key, read ./references/defaults.md.
  6. Language adaptation: if paths.language_idioms is set in the config and the document exists, read it and adapt the defaults using these…

What it can do on your machine

Read from SKILL.md and the folder at commit 4d6c35f. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Clean Code loads about 1.6k tokens when it runs, and up to ~5k if it reads all its reference files. Until then it costs about 158 tokens; SKILL.md has 799 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~158
When it runs · the whole SKILL.md, loaded when a task matches
~1.6k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from techygarg/lattice at commit 4d6c35f, republished under its MIT licence (© techygarg). 799 words, ~1,634 tokens.

Download SKILL.mdSave it as .claude/skills/clean-code/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
clean-code
description
Apply clean code principles when generating or modifying implementation code. Enforces function focus, naming clarity, complexity management, error handling, and self-documenting style. Use when the user mentions 'clean code', 'code quality', 'coding guidelines', or 'implementation quality'. Loaded automatically by the code-generating molecules (code-forge, refactor-safely, bug-fix). This skill governs the craft of writing individual code units -- not architecture (see architecture), not security posture (see secure-coding), not test structure (see test-quality), and not refactoring workflows (see refactor-safely).

Clean Code

Config Resolution

Projects can customize this skill's standards. Resolution order:

  1. Read .lattice/config.yaml in the repo root.
  2. If found, check paths.clean_code for a custom document path.
  3. If a custom document exists at that path, read it and check its YAML frontmatter for mode:
    • mode: override: the custom document has full precedence. Use it instead of the embedded defaults. It must be comprehensive -- treat it as the sole reference.
    • mode: overlay (or no mode field): read the embedded ./references/defaults.md first, then apply the custom document's sections on top. A custom section replaces the matching default section (matched by exact heading); new sections append after the defaults.
  4. If a custom path is configured but no document exists at it → tell the user which configured path is missing, then fall back to ./references/defaults.md.
  5. If there is no config file or no paths.clean_code key, read ./references/defaults.md.
  6. Language adaptation: if paths.language_idioms is set in the config and the document exists, read it and adapt the defaults using these sections:
    • "Error Handling" → adapt §8 (Error Handling) patterns to the language's idioms. Language idioms take precedence over the pseudocode defaults.
    • "Type System & Object Model" → adapt §1 (Single Responsibility) cohesion guidance to the language's constructs (e.g., struct vs class).
    • "Naming Conventions" → adapt §4 (Meaningful Naming) patterns to the language's conventions.
    • "Parameter & Function Design" → adapt §2 (Small, Focused Functions) and §5 (Parameter Design) to the language's capabilities.
    • "Dependency Management" → adapt §9 (Test-Friendly Code) dependency-injection patterns to the language's idioms.

Self-Validation Checklist

STOP after generating each component. Verify ALL checks. Fix every failed check before presenting. Judgment calls → present options (see Ambiguity Signals).

  1. SINGLE RESPONSIBILITY: Can you describe each function without "and"? If not → extract a separate function.
  2. SIZE: Is each function under the size threshold from the loaded doc (~20 lines default)? If not → extract a sub-operation into its own named function.
  3. COMPLEXITY: Is cyclomatic complexity under the threshold from the loaded doc (~10 default)? If not → flatten with a guard clause or extract a branch.
  4. ABSTRACTION LEVEL: Does each function operate at one level of abstraction? If high-level logic mixes with low-level detail → extract the detail.
  5. NAMING: Does each function/variable name reveal intent without needing surrounding context? If not → rename to be self-documenting.
  6. PARAMETERS: Is the parameter count under the threshold from the loaded doc (4 default)? If not → group parameters into an object.
  7. PRIMITIVE OBSESSION: Would a string/number/boolean be clearer as a named type? If so → introduce a parameter object or typed wrapper.
  8. ERROR HANDLING: Does every fail-able operation have explicit handling with an actionable message? Is it handled at the right level?

Project-specific checks: if the loaded doc (from Config Resolution) contains a Validation Checklist section (§10 from the clean-code-refiner template), apply those checks as additional project-specific validation after the checklist above.

All checks pass → state "Passes clean-code. [next step]."

Show full SKILL.md (320 more words)Show less

Active Anti-Pattern Scan

After the checklist, scan for each of these. Any box you can check → fix before presenting.

  • God Function: a function exceeds ~30 lines doing multiple things; describing it requires "and" → extract focused functions.
  • Deep Nesting: three or more levels of indentation → flatten with early returns / guard clauses.
  • Cryptic Naming: variables like d, tmp2, processData → rename to reveal intent.
  • Long Parameter Lists: five or more parameters → group into an object or split the function.
  • Premature Abstraction: a utility extracted from only two similar blocks → inline it until the Rule of Three (third instance with the same reason to change).
  • Swallowed Errors: empty catch blocks, generic "something went wrong" messages, silent null returns → handle explicitly.
  • Comments as Deodorant: a comment explains convoluted code instead of the code being fixed → rename to self-document; keep only "why" comments, remove "what" comments.
  • Hidden Side Effects: a function named getX also writes a cache or sends notifications → rename or separate the concern.
  • Dead Code: commented-out blocks, unused imports, unreachable branches → delete them (version control preserves history).
  • Untestable Logic: side effects tangled with business logic; unit testing requires mocking I/O → push side effects to the boundary, extract pure functions, inject dependencies.

Ambiguity Signals

Multiple valid outcomes exist. Present the options rather than silently choosing. If framework:collaborative-judgment is loaded, use its presentation format. See ./references/defaults.md for resolution guidance on each signal below.

  • Single Responsibility: two tightly-coupled sequential operations may be one responsibility (a pipeline), not two. The "and" test catches true violations AND false positives.
  • Function Size: near-threshold size (20–30 lines) with one clear purpose -- extraction may create five unclear smaller functions. Present the tradeoff.
  • DRY vs Premature Abstraction: two identical blocks may serve different purposes and diverge independently. Until a third instance with the same reason to change appears, this is genuinely ambiguous.
  • Error Handling Strategy: exception vs Result type vs error codes depends on language idiom and team convention, not on universal rules.

© techygarg, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (references) in skills/clean-code of techygarg/lattice.

  • SKILL.md
  • references/defaults.md

Open the folder on GitHubat commit 4d6c35f

Compare with similar skills

Clean Code next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Clean Code compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Clean Code this skilltechygarg/lattice198—~1.6kAutomated safety check: PassMIT
Systematic Code Refactoringluongnv89/claude-howto42k—~3kAutomated safety check: PassMIT
Dignified Python Standardsdocling-project/docling68k—~1.5kAutomated safety check: PassApache-2.0
Clean Code GuardamElnagdy/guard-skills1.3k2 repos~4.3kAutomated safety check: PassMIT
Code Refactoring Workflowluongnv89/claude-howto42k—~3.1kAutomated safety check: PassMIT
Maintainable Code for iPolloWorkDevin-AXIS/iPolloWork6.7k—~2.7kAutomated safety check: PassCustom licence

Similar skills

  • Systematic Code Refactoring

    luongnv89/claude-howto

    Guides refactoring in phases based on Martin Fowler's method: research, test coverage check, planning and small tested steps, with your approval at each phase.

    42k GitHub stars~3k tokensUpdated 7 days ago
    DevelopmentAuto-check passed

  • Dignified Python Standards

    docling-project/docling

    Applies opinionated production Python conventions chosen by the project's Python version: modern type syntax, pathlib, explicit checks and interface guidance.

    68k GitHub stars~1.5k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Clean Code Guard

    amElnagdy/guard-skills

    Reviews generated or changed production code against Clean Code, SOLID, DRY, KISS, YAGNI and LLM-specific failure modes before it ships, in any language.

    1.3k GitHub starsUsed in 2 repos~4.3k tokens
    DevelopmentAuto-check passed

  • Code Refactoring Workflow

    luongnv89/claude-howto

    Guides systematic, test-backed refactoring in the style of Martin Fowler, moving through research, planning and small incremental changes with your approval at each phase.

    42k GitHub stars~3.1k tokensUpdated 7 days ago
    DevelopmentAuto-check passed

  • Maintainable Code for iPolloWork

    Devin-AXIS/iPolloWork

    A code-change gate for the iPolloWork repository: search and reuse first, keep one source of truth, justify every new file or dependency, and audit the change.

    6.7k GitHub stars~2.7k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Tech Debt Analyzer

    ailabs-393/ai-labs-claude-skills

    This skill should be used when analyzing technical debt in a codebase, documenting code quality issues, creating technical debt registers, or assessing code maintainability.

    454 GitHub starsUsed in 2 repos~3.9k tokens
    DevelopmentAuto-check passed

More from techygarg/lattice

All 33 skills in this repo

  • Architecture Compass

    techygarg/lattice

    Architectural thinking partner for an existing repository — scans the codebase, conducts a structured interview, agrees on current architectural state and recommended direction, and produces a…

    198 GitHub stars~4.4k tokensUpdated yesterday
    Auto-check passed

  • Lattice Init

    techygarg/lattice

    Guided setup and upgrade-check experience for Lattice projects -- scans the repository, detects existing configuration and outdated conventions, suggests refiners and available upgrades in priority…

    198 GitHub stars~3.3k tokensUpdated yesterday
    Auto-check passed

  • Skill Align

    techygarg/lattice

    Audit and fix all Lattice documentation, README, docs/, PROJECT.md, GitHub issue templates, and CLAUDE.md to ensure they are fully aligned with the current skill inventory.

    198 GitHub stars~2k tokensUpdated yesterday
    Auto-check passed

  • Skill Validate

    techygarg/lattice

    Validate any Lattice SKILL.md against all tier conventions — atoms, molecules, and refiners.

    198 GitHub stars~1.5k tokensUpdated yesterday
    Auto-check passed

  • Architecture Refiner

    techygarg/lattice

    Facilitate a structured conversation to define architecture principles for a repository.

    198 GitHub stars~3.7k tokensUpdated yesterday
    Auto-check passed

  • Clean Code Refiner

    techygarg/lattice

    Facilitate a structured conversation to define clean code principles for a repository.

    198 GitHub stars~3k tokensUpdated yesterday
    Auto-check passed

Categories

Questions about Clean Code

What does Clean Code do?

Apply clean code principles when generating or modifying implementation code. Clean Code is an agent skill from techygarg/lattice. Apply clean code principles when generating or modifying implementation code.

When should I use Clean Code?

Clean Code fits situations like: the user mentions clean code; coding guidelines; implementation quality.

How do I install Clean Code in Claude Code?

Run `npx skills add techygarg/lattice --skill clean-code -a claude-code`. Or copy the skill folder (skills/clean-code in techygarg/lattice) into .claude/skills/clean-code in your project. Claude Code loads it when a task matches its description.

How do I install Clean Code in Codex?

Run `npx skills add techygarg/lattice --skill clean-code -a codex`. Or copy the skill folder (skills/clean-code in techygarg/lattice) into .agents/skills/clean-code in your project. Codex loads it when a task matches its description.

Can I use Clean Code in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add techygarg/lattice --skill clean-code -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/clean-code, .gemini/skills/clean-code, .github/skills/clean-code and .opencode/skills/clean-code in your project.

What does Clean Code need to run?

SKILL.md names no scripts, command-line tools or credentials: Clean Code is instructions for the agent only.

Does Clean Code access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Clean Code safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Clean Code use?

Clean Code is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Clean Code use?

About 1.6k tokens (SKILL.md is roughly 6.5k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 3.3k tokens, read only when the agent opens those files.

What are the alternatives to Clean Code?

Skills that share tags, products or a category with Clean Code: Systematic Code Refactoring (luongnv89/claude-howto, 42k stars), Dignified Python Standards (docling-project/docling, 68k stars), Clean Code Guard (amElnagdy/guard-skills, 1.3k stars) and Code Refactoring Workflow (luongnv89/claude-howto, 42k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Clean Code?

techygarg (a GitHub user) maintains it in techygarg/lattice, which has 198 GitHub stars. The repository holds 33 skills in this directory. The repository was last updated on October 6, 2026.

Source: techygarg/lattice on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.