home / skills / tlabs-xyz / tbtc-v2-performance / global-coding-style

global-coding-style skill

/.claude/skills/global-coding-style

This skill enforces universal coding standards across languages, improving readability, maintainability, and reuse through consistent naming, formatting, and

npx playbooks add skill tlabs-xyz/tbtc-v2-performance --skill global-coding-style

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.8 KB
---
name: Global Coding Style
description: Write clean, consistent code following naming conventions, DRY principles, and automated formatting standards. Use this skill when writing any code in any language, naming variables/functions/classes/files, formatting code, refactoring for readability, extracting reusable functions, removing dead code or unused imports, implementing consistent indentation, creating small focused functions, applying the DRY principle, or ensuring backward compatibility only when required. Use across all file types including .js, .ts, .py, .java, .go, .rs, .rb, .php, .jsx, .tsx, .vue, or any programming language files. This is a universal skill that applies to all coding work regardless of language or framework.
---

## When to use this skill

- When writing code in any programming language
- When naming variables, functions, classes, or files
- When formatting code or applying code style
- When refactoring code for better readability
- When extracting common logic into reusable functions or modules
- When removing dead code, commented-out blocks, or unused imports
- When ensuring consistent indentation and spacing
- When creating small, focused functions
- When applying the DRY (Don't Repeat Yourself) principle
- When deciding whether backward compatibility logic is needed
- When working with automated formatters (Prettier, Black, Rustfmt, gofmt)
- When following language-specific style guides (PEP 8, JavaScript Standard Style, etc.)
- When writing any code file regardless of language or framework

# Global Coding Style

This Skill provides Claude Code with specific guidance on how to adhere to coding standards as they relate to how it should handle global coding style.

## Instructions

For details, refer to the information provided in this file:
[global coding style](../../../agent-os/standards/global/coding-style.md)

Overview

This skill enforces a consistent, readable coding style across languages and file types. It focuses on clear naming, small focused functions, DRY principles, and automated formatting to reduce cognitive load and maintenance cost. Use it anytime you write, refactor, or clean up code to improve long-term quality and team consistency.

How this skill works

The skill inspects code for naming conventions, unused imports or dead code, long functions, inconsistent indentation, and repeated logic. It applies or recommends automated formatter rules (Prettier, Black, gofmt, rustfmt) and suggests refactors to extract reusable functions and simplify control flow. Where needed, it preserves backward compatibility only when explicitly required and flags places to document compatibility decisions.

When to use it

  • Writing new code in any language or file type (.js, .ts, .py, .java, .go, .rs, .rb, .php, .jsx, .tsx, .vue, etc.)
  • Naming or renaming variables, functions, classes, and files
  • Refactoring for readability, extracting common logic, or removing dead code
  • Applying or validating automated formatters and language style guides
  • Reducing duplication to follow the DRY principle

Best practices

  • Prefer descriptive, consistent names (camelCase for variables, PascalCase for types/classes where applicable)
  • Keep functions short and focused; extract repeated logic into well-named helpers
  • Run automated formatters and linters as part of edits and CI to enforce style
  • Remove commented-out code and unused imports; leave migration notes when removing public API behavior
  • Document any intentional deviations and preserve backward compatibility only when necessary

Example use cases

  • Refactor a 300-line function into small, testable helper functions and remove duplication
  • Apply Prettier/ESLint or Black/flake8 rules to a mixed-format codebase to standardize layout
  • Rename inconsistent variables and update references to match team naming conventions
  • Strip unused imports and commented legacy blocks before a release
  • Introduce a shared utility module to centralize repeated parsing or validation logic

FAQ

Should I always change public APIs to match style?

No. Prioritize backward compatibility for public APIs; prefer adapters or deprecation paths and document changes before removal.

Which formatter should I choose?

Pick the community standard for the language (Prettier for JS/TS, Black for Python, gofmt for Go, rustfmt for Rust) and enforce it in CI.