CommunityCoding & Developmentgithub.com

Jamie-BitFlight/clang-format

Configure clang-format code formatting. Use when: user mentions clang-format or .clang-format, analyzing code style/patterns, creating/modifying formatting config, troubleshooting formatting, brace styles/indentation/spacing/alignment/pointer alignment, or codifying conventions.

What is clang-format?

clang-format is a Claude Code agent skill that configure clang-format code formatting. Use when: user mentions clang-format or .clang-format, analyzing code style/patterns, creating/modifying formatting config, troubleshooting formatting, brace styles/indentation/spacing/alignment/pointer alignment, or codifying conventions.

Works with~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Jamie-BitFlight/claude_skills/tree/main/plugins/clang-format/skills/clang-format

Installed? Explore more Coding & Development skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Ask in your favorite AI

Open a new chat with this agent skill pre-loaded.

Documentation

clang-format Configuration

Configure the clang-format code formatting tool using ready-to-use templates, integration scripts, and comprehensive reference documentation.

Purpose

This skill provides procedural workflows for clang-format configuration tasks:

  • Create new .clang-format files from proven templates
  • Analyze existing code style and generate matching configurations
  • Set up editor and git integration with bundled scripts
  • Troubleshoot formatting behavior using reference documentation

Workflow Routing by Trigger Type

Once invoked, route to appropriate workflow based on which trigger fired:

Trigger 1: Explicit clang-format mention → If user asks about specific options: Consult references/01-09.md for relevant category → If user needs complete reference: Direct to references/complete/clang-format-style-options.md → If user asks about CLI usage: Reference references/cli-usage.md

Trigger 2: Code style analysis request → Follow "Analyzing Existing Code Style" workflow below → Examine code samples systematically (braces→indentation→spacing→breaking→alignment) → Map patterns to closest template in assets/configs/ → Generate initial configuration hypothesis as a temporary configuration file "/tmp/<reponame>/hypothesis.clang-format" → VERIFY IMPACT: Run clang-format --style="/tmp/<repo_name>/hypothesis_<number>.clang-format" file.cpp | diff - file.cpp on 3-5 representative samples → MEASURE IMPACT using weighted scoring: • Metric 1: Line count changes (lines added/removed) - weight 10 • Metric 2: In-line whitespace changes (spacing within existing lines) - weight 1 • Impact Score = (line_count_changes × 10) + (whitespace_changes × 1) • Lower score = lower impact to rebasing conflicts, future git-diff analysis, and merge request change reviews = better configuration → ITERATE: Adjust config options targeting highest-impact settings, re-test, compare scores → REPEAT until reaching minimal achievable score while maintaining consistent style enforcement → REPORT TO USER: Present winning configuration with: • Final impact score and breakdown (line changes vs whitespace changes) • Comparison table showing all tested hypotheses and their scores • Example diff snippets showing what will change, with commands for the user to test it themselves against files of their choice. • Rationale for selected configuration → AWAIT USER APPROVAL before finalizing configuration → Only after approval: provide final configuration file

Trigger 3: Configuration file operations → If creating new: Follow "Creating New Configuration from Template" workflow → If modifying existing: Read current config, identify changes needed, consult relevant category guide → If generating from code: Use Trigger 2 workflow (code style analysis)

Trigger 4: Formatting behavior investigation → Follow "Troubleshooting Formatting Issues" workflow below → Verify config detection with --dump-config → Identify affected category, consult relevant references/0X.md guide → Test isolated options with minimal config

Trigger 5: Style option inquiries → Map question to category: braces→03, indentation→04, spacing→05, alignment→01, breaking→02 → Reference specific category guide in references/ → Provide examples from quick-reference.md if applicable

Trigger 6: Minimal-disruption requests → Use "Analyzing Existing Code Style" workflow to match current patterns → Emphasize starting from closest template to minimize changes → Test on representative samples before project-wide application → Document which patterns were preserved vs normalized

Bundled Resources

Configuration Templates (assets/configs/)

Seven ready-to-use .clang-format templates optimized for common scenarios:

  • google-cpp-modified.clang-format - Google C++ style with 4-space indent, 120 column limit
  • linux-kernel.clang-format - Linux kernel coding standards (tabs, K&R braces)
  • microsoft-visual-studio.clang-format - Microsoft/Visual Studio conventions
  • modern-cpp17-20.clang-format - Modern C++17/20 style with contemporary idioms
  • compact-dense.clang-format - Compact style for space-constrained environments
  • readable-spacious.clang-format - Spacious style prioritizing readability
  • multi-language.clang-format - Multi-language configuration (C++, JavaScript, Java)

When to use templates: Start new projects, establish team standards, or quickly test formatting approaches.

Integration Scripts (assets/integrations/)

Three editor and git integration scripts:

  • pre-commit - Git hook script for automatic formatting of staged files (works with pre-commit or prek framework)
  • vimrc-clang-format.vim - Vim configuration for format-on-save
  • emacs-clang-format.el - Emacs configuration for clang-format integration

When to use integrations: Set up automatic formatting in development workflow.

Note: The pre-commit hook script works with both the pre-commit framework (Python) and prek (Rust alternative). Both frameworks use .pre-commit-config.yaml with identical syntax.

Reference Documentation (references/)

Detailed documentation organized by category:

Quick Navigation:

  • index.md - Overview and documentation hub
  • quick-reference.md - Complete working configurations with explanations
  • cli-usage.md - Command-line usage, editor setup, CI/CD integration

Option Categories (01-09.md):

  1. 01-alignment.md - Vertical alignment of declarations, assignments, operators
  2. 02-breaking.md - Line breaking and wrapping rules
  3. 03-braces.md - Brace placement styles (K&R, Allman, GNU, etc.)
  4. 04-indentation.md - Indentation rules and special cases
  5. 05-spacing.md - Whitespace control around operators, keywords
  6. 06-includes.md - Include/import organization and sorting
  7. 07-languages.md - Language-specific options for C++, Java, JavaScript
  8. 08-comments.md - Comment formatting and reflow
  9. 09-advanced.md - Penalty system, raw string formatting, experimental features

Complete Reference (complete/):

  • clang-format-cli.md - Full command-line interface documentation
  • clang-format-style-options.md - All 194 style options with examples

Common Workflows

Creating New Configuration from Template

To create a new .clang-format file:

  1. Identify requirements (style guide, team preferences, language)
  2. Select closest template from assets/configs/
  3. Copy template to project root as .clang-format
  4. Test formatting: clang-format --dry-run file.cpp
  5. Customize specific options using references/01-09.md as needed
  6. Verify changes: clang-format file.cpp | diff - file.cpp

Example:

# Copy Google C++ template
cp assets/configs/google-cpp-modified.clang-format /path/to/project/.clang-format

# Test on sample file
clang-format --dry-run /path/to/project/src/main.cpp

# Apply if satisfied
clang-format -i /path/to/project/src/*.cpp

Analyzing Existing Code Style

To generate configuration matching existing code:

  1. Examine code samples for formatting patterns
  2. Identify key characteristics:
    • Brace placement → consult references/03-braces.md
    • Indentation (spaces/tabs, width) → consult references/04-indentation.md
    • Spacing (operators, keywords) → consult references/05-spacing.md
    • Line breaking (column limit, wrapping) → consult references/02-breaking.md
    • Alignment patterns → consult references/01-alignment.md
  3. Map patterns to closest base style in references/quick-reference.md
  4. Start with that template from assets/configs/
  5. Override specific options to match observed patterns
  6. Test on representative code samples
  7. Iterate until formatting matches existing style

This workflow minimizes whitespace-only changes when introducing clang-format to existing projects.

Setting Up Editor Integration

To enable format-on-save in editors:

Vim:

  1. Copy assets/integrations/vimrc-clang-format.vim content to .vimrc
  2. Restart Vim or source configuration
  3. Save any C/C++/Java file to trigger formatting

Emacs:

  1. Copy assets/integrations/emacs-clang-format.el to Emacs config
  2. Restart Emacs or evaluate configuration
  3. Save any supported file to trigger formatting

Other editors: Consult references/cli-usage.md for VS Code, CLion, and other editor setup instructions.

Setting Up Git Hook for Formatting

Option 1: Using pre-commit/prek framework (Recommended):

Configure in .pre-commit-config.yaml:

repos:
  - repo: https://github.com/pre-commit/mirrors-clang-format
    rev: v19.1.7
    hooks:
      - id: clang-format

Then install: pre-commit install or prek install

Option 2: Manual git hook:

  1. Copy assets/integrations/pre-commit to .git/hooks/pre-commit
  2. Make executable: chmod +x .git/hooks/pre-commit
  3. Test by staging and committing changes

The hook formats only staged files, preserving unstaged changes.

Troubleshooting Formatting Issues

When formatting produces unexpected results:

  1. Verify configuration detection: clang-format --dump-config file.cpp
  2. Check command options in references/cli-usage.md
  3. Identify affected formatting category (braces, spacing, breaking, etc.)
  4. Consult relevant category guide in references/01-09.md
  5. Test isolated options: create minimal config with suspect option
  6. For comprehensive option details, check references/complete/clang-format-style-options.md

Setting Up CI/CD Formatting Checks

To enforce formatting in continuous integration:

  1. Review CI examples in references/cli-usage.md
  2. Add clang-format check to pipeline:
    # Check formatting without modifying files
    clang-format --dry-run --Werror src/**/*.{cpp,h}
    
  3. Configure to fail build on formatting violations
  4. Document formatting requirements for contributors

Key Concepts

Base Styles: Predefined configurations (LLVM, Google, Chromium, Mozilla, WebKit, Microsoft, GNU) provide starting points. Set with BasedOnStyle: Google then override specific options.

Multi-Language Support: Configure different languages separately in single file using Language: key. See assets/configs/multi-language.clang-format for example.

Penalty System: clang-format uses penalties to choose between formatting alternatives. Higher penalty values discourage specific choices. See references/09-advanced.md for details.

Progressive Refinement: Start with template closest to requirements, then customize incrementally. Test frequently on representative code samples.

Testing Configurations

# Preview changes without modifying file
clang-format --dry-run file.cpp

# Show diff of proposed changes
clang-format file.cpp | diff - file.cpp

# Apply formatting to file
clang-format -i file.cpp

# Format entire project
find src include -name '*.cpp' -o -name '*.h' | xargs clang-format -i

# Check formatting in CI (fail on violations)
clang-format --dry-run --Werror src/**/*.{cpp,h}

Navigation Strategy

For most tasks, follow this progression:

  1. Start with templates: Browse assets/configs/ for ready-to-use configurations
  2. Quick reference: Check references/quick-reference.md for complete configurations with explanations
  3. Category guides: Consult references/01-09.md for specific option categories
  4. CLI usage: Reference references/cli-usage.md for command-line and integration details
  5. Complete reference: Use references/complete/ for exhaustive option documentation

When analyzing code or troubleshooting, identify the formatting aspect (braces, spacing, alignment, etc.) and jump directly to the relevant category guide in references/.

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

Jamie-BitFlight/agentskill-kaizen-meta-docs

Agentskill kaizen plugin documentation index. Load when needing to read about cross-platform notes, improvement plans, or DuckDB integration.

Jamie-BitFlight/bash-51-features

Bash 5.1 release features and improvements with practical examples. Use when working with Bash 5.1 features, epoch time variables, redirection enhancements, or when user asks about Bash 5.1 changes, new features, or version-specific capabilities.

Jamie-BitFlight/bash-52-features

Bash 5.2 release features and improvements with practical examples. Use when working with Bash 5.2 features, variable handling enhancements, readline improvements, or when user asks about Bash 5.2 changes, new features, or version-specific capabilities.

Jamie-BitFlight/bash-53-features

Bash 5.3 release features and improvements with practical examples. Use when working with Bash 5.3 features, new command substitution, GLOBSORT, loadable builtins, or when user asks about Bash 5.3 changes, new features, or version-specific capabilities.

Jamie-BitFlight/bash-development

This skill should be used when the user asks to "write a bash script", "create a shell script", "implement bash function", "parse arguments in bash", "handle errors in bash", or mentions bash development, shell scripting, script templates, or modern bash patterns.

Jamie-BitFlight/bash-lint

This skill should be used when the user asks to "lint bash script", "run shellcheck", "format shell script", "use shfmt", "fix shellcheck errors", or mentions shell script linting, formatting, code quality, or pre-commit hooks for bash.

Jamie-BitFlight/bash-logging

This skill should be used when the user asks to "add logging to bash script", "colorize output", "implement log levels", "CI/CD sections", "terminal colors in bash", or mentions logging functions, emoji output, collapsible CI sections, or shlocksmith.

Jamie-BitFlight/bash-portability

This skill should be used when the user asks about "POSIX compatibility", "portable shell scripts", "cross-shell compatibility", "bashisms", "shebang selection", or mentions writing scripts that work on different shells (bash, sh, dash, zsh) or different systems.

Jamie-BitFlight/bash-testing

This skill should be used when the user asks to "test bash script", "write shell tests", "use shunit2", "use shellspec", "create test suite for bash", or mentions unit testing, test frameworks, mocking, or test-driven development for shell scripts.

Jamie-BitFlight/brainstorming-skill

You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or when users request help with ideation, marketing, and strategic planning. Explores user intent, requirements, and design before implementation using research-validated prompt patterns.

Jamie-BitFlight/commitlint

When setting up commit message validation for a project. When project has commitlint.config.js or .commitlintrc files. When configuring CI/CD to enforce commit format. When extracting commit rules for LLM prompt generation. When debugging commit message rejection errors.

Jamie-BitFlight/conventional-commits

When writing a git commit message. When task completes and changes need committing. When project uses semantic-release, commitizen, git-cliff. When choosing between feat/fix/chore/docs types. When indicating breaking changes. When generating changelogs from commit history.

Jamie-BitFlight/dasel-reference

Use when querying, modifying, or converting JSON, YAML, TOML, XML, CSV, HCL, or INI with dasel v3. Complete reference for selectors, functions, conditionals, variables, spread operator, type casting, and format-specific patterns.

Jamie-BitFlight/data-exploration

Use when exploring unknown structured data files with dasel v3 — discover schema, list keys, find nested values, sample arrays, identify data types across JSON, YAML, TOML, XML, CSV, HCL, INI formats

Jamie-BitFlight/data-transformation

Use when modifying, converting, or transforming structured data with dasel v3 — in-place mutations, format conversion, batch operations, array manipulation, object construction, and merge patterns across JSON, YAML, TOML, XML, CSV, HCL, INI

Jamie-BitFlight/delegate

Decompose substantive work into phases, dispatch each phase to a sub-agent, and adjudicate what comes back. Use whenever a request asks for implementation, investigation, a fix, a review, or any change to files — including small ones — and whenever you are about to read source or run a diagnostic yourself instead of handing it off. Also use when a report from a sub-agent needs judging, when a phase needs re-dispatching, or when a user names one instance of a pattern. Does not apply when your own prompt begins "Your ROLE_TYPE is sub-agent." — then follow references/sub-agent-contract.md instead.

Jamie-BitFlight/enterprise-hibernate-hbm

Dasel v3 query patterns for Hibernate .hbm.xml mapping files — entity-table binding, Java property-to-column extraction, one-to-many set/list/bag relationship tracing, many-to-one foreign key discovery, batch scanning across 60+ HBM files. Use when querying Hibernate ORM class mappings, extracting schema metadata from Java persistence layer, or auditing entity-column relationships in enterprise legacy codebases.

Jamie-BitFlight/enterprise-installanywhere

Dasel v3 query patterns for InstallAnywhere .iap_xml installer definitions — use when querying action sequences, discovering variables, resolving platform conditions, navigating panels, or comparing installer variants. Files are 2.5+ MB, 65,000+ lines — too large for context reads, requires structural dasel queries.

Jamie-BitFlight/enterprise-maven-pom

Dasel v3 selector patterns for Maven POM XML files — use when querying dependency versions, filtering by groupId or scope, extracting module hierarchy from parent POMs, or detecting version conflicts across enterprise multi-module Java projects. Load this skill when working with pom.xml files using dasel.

Jamie-BitFlight/enterprise-spring-xml

Dasel v3 selectors for Spring bean factory XML — use when querying any Spring ApplicationContext XML for bean discovery, dependency wiring, JMS destination mapping, property injection extraction, or cross-bean reference tracing. Load this skill before writing dasel selectors against Spring bean XML files (applicationContext.xml, *_beans.xml, spring-*.xml).

Related Skills