Code Style Enforcer

This skill ensures code follows project-specific style conventions and patterns that automated linters may miss.

When to Use This Skill

• User requests code style review or improvements
• Ensuring consistency across the codebase
• Onboarding new code or contributors
• Pre-commit code review
• User mentions "style", "consistency", "formatting", or "conventions"

Instructions

1. Detect Project Style Guides

Look for style configuration files:

JavaScript/TypeScript:

• .eslintrc.*

  - ESLint configuration

• .prettierrc.*

  - Prettier configuration

• tsconfig.json

  - TypeScript compiler options

• .editorconfig

  - Editor configuration

Python:

• .pylintrc

  ,

  pylint.cfg

  - Pylint

• pyproject.toml

  - Black, isort configuration

• .flake8

  - Flake8 configuration

• setup.cfg

  - Various tool configs

Ruby:

• .rubocop.yml

  - RuboCop configuration

Go:

• go.fmt

  enforced (standard)

• .golangci.yml

  - GolangCI-Lint

Java:

• checkstyle.xml

  - Checkstyle

• .editorconfig

General:

• CONTRIBUTING.md

  - Contribution guidelines

• STYLE_GUIDE.md

  - Project style guide

• .editorconfig

  - Cross-editor settings

Use Glob to find these files and Read to understand the project's style preferences.

2. Analyze Existing Code Patterns

Sample existing code to understand implicit conventions:

File organization:

• Directory structure patterns
• File naming conventions (camelCase, kebab-case, snake_case)
• Import/export organization

Code structure:

• Class/function ordering
• Public vs private method placement
• Constant/variable declaration location

Formatting:

• Indentation (spaces vs tabs, size)
• Line length limits
• Blank line usage
• Comment styles

Naming:

• Variable naming (camelCase, snake_case)
• Class naming (PascalCase, capitalization)
• Constant naming (UPPER_CASE, etc.)
• File naming patterns

Use Grep to find common patterns across similar files.

3. Beyond Linters: Check for Patterns

Focus on style issues that automated tools often miss:

Naming Consistency:

• Boolean variables:

  is

  ,

  has

  ,

  should

  prefixes
• Event handlers:

  handle*

  ,

  on*

  patterns
• Getters/setters:

  get*

  ,

  set*

  consistency
• Collection naming: plural vs singular
• Acronyms: consistent capitalization

Code Organization:

• Related functions grouped together
• Consistent file structure across modules
• Logical ordering (public before private, etc.)
• Separation of concerns

Comments and Documentation:

• JSDoc/docstring completeness
• Comment style consistency
• TODO/FIXME format
• Inline vs block comments

Import/Export Patterns:

• Import ordering (external, internal, relative)
• Named vs default exports
• Destructuring consistency
• Aliasing patterns

Error Handling:

• Consistent error message format
• Error class usage
• Try/catch patterns
• Logging format

Type Usage (TypeScript/typed languages):

• Explicit vs inferred types

• interface

  vs

  type

  preference
• Generic naming (T, K, V vs descriptive)
• Null/undefined handling

4. Identify Common Anti-Patterns

Flag code smells and anti-patterns:

Magic Numbers:

// Bad
if (status === 200) { }

// Good
const HTTP_OK = 200;
if (status === HTTP_OK) { }

Inconsistent null checks:

// Inconsistent
if (user === null) { }
if (!data) { }
if (typeof result === 'undefined') { }

// Consistent
if (user === null) { }
if (data === null) { }
if (result === undefined) { }

Nested ternaries:

// Hard to read
const value = a ? b ? c : d : e;

// Better
let value;
if (a) {
  value = b ? c : d;
} else {
  value = e;
}

Long parameter lists:

# Hard to maintain
def create_user(name, email, age, address, phone, ...):

# Better
def create_user(user_data: UserData):

5. Check Project-Specific Conventions

Look for patterns unique to this project:

• Custom naming for specific domains (e.g., "repo" vs "repository")
• Preferred libraries for common tasks
• Architectural patterns (MVC, service layer, etc.)
• Test file naming and structure
• Configuration patterns

Read

CONTRIBUTING.md

,

README.md

, or similar docs for explicit guidelines.

6. Generate Style Recommendations

For each issue, provide:

Current code:

function getData(id) {
  const d = fetch('/api/users/' + id);
  return d;
}

Issue:

• Inconsistent naming (

  getData

  vs other functions use

  fetch*

  )
• Single-letter variable name (

  d

  )
• String concatenation instead of template literals

Recommended:

function fetchUser(id) {
  const userData = fetch(`/api/users/${id}`);
  return userData;
}

7. Prioritize Issues

Order by impact:

High Priority (Consistency):

• Naming inconsistencies across similar functions
• Mixed indentation or formatting
• Inconsistent error handling

Medium Priority (Readability):

• Magic numbers/strings
• Unclear variable names
• Missing documentation

Low Priority (Nice-to-have):

• Comment formatting
• Import ordering
• Extra blank lines

8. Suggest Automated Tools

Recommend tools to enforce styles:

JavaScript/TypeScript:

npm install --save-dev prettier eslint
npx prettier --write .
npx eslint --fix .

Python:

pip install black isort flake8
black .
isort .

Go:

go fmt ./...
golangci-lint run

Ruby:

gem install rubocop
rubocop -a

9. Create or Update EditorConfig

Suggest

.editorconfig

if missing:

root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

[*.{js,ts,jsx,tsx}]
indent_style = space
indent_size = 2

[*.py]
indent_style = space
indent_size = 4

[*.go]
indent_style = tab

10. Style Review Checklist

When reviewing code for style:

• Naming follows project conventions
• Indentation and formatting consistent
• Imports organized properly
• Comments where needed, not excessive
• No magic numbers or strings
• Error handling consistent
• File organization matches project structure
• No obvious code smells
• Type annotations consistent (if applicable)
• Tests follow testing conventions

Best Practices

1. Consistency over perfection: Follow existing patterns even if not ideal
2. Document decisions: Add style guides for ambiguous cases
3. Automate where possible: Use Prettier, Black, gofmt, etc.
4. Be pragmatic: Don't refactor working code just for style
5. Team agreement: Align on styles that matter
6. Incremental improvement: Fix styles in touched files, not all at once
7. Readability first: Style serves readability, not vice versa

Common Style Conflicts

Tabs vs Spaces

• Check

  .editorconfig

  or existing files
• When in doubt, use project majority

Quote Style (Single vs Double)

• JavaScript: Single (

  '

  ) common
• Python: Either, be consistent
• Go: Always double (

  "

  )
• Follow linter config if present

Semicolons (JavaScript)

• Check existing code majority
• If mixed, suggest Prettier to enforce

Line Length

• Common limits: 80, 100, 120 characters
• Check linter config or

  .editorconfig

Import Ordering

• Usually: stdlib, external, internal, relative
• Use automated tools (isort, organize imports)

Supporting Files

• reference/style-guides.md

  : Links to popular style guides

• examples/before-after.md

  : Code examples showing improvements