Code Style Matching

Match what the project already does. Never impose personal defaults.

Step 1: Load the cached style index

Read the index with the Read tool (one known file — never cat):

Read(file_path: "$CLAUDE_PROJECT_DIR/.claude/code-style-index.json")

• Exists → apply its rules, skip to Step 3.
• Missing → Step 2, then write it.

In a workspace with per-crate/per-package configs, an index may also live beside the sub-project (<repo>/crates/foo/.claude/code-style-index.json). Nearest index to the file being edited wins.

Step 2: Build the index (first invocation only)

2a. Detect the toolchain from the build manifest

Read the manifest, don't scan the tree. Whichever manifests exist decide which configs matter:

Manifest	Formatter / lint config to read	Verify with
Cargo.toml	rustfmt.toml / .rustfmt.toml, clippy.toml, [workspace.lints] in the manifest	cargo fmt --check, cargo clippy
package.json	.prettierrc*, prettier.config.*, eslint.config.*, .eslintrc*, biome.json(c), dprint.json, oxlint.json, tsconfig.json, plus "prettier" / "eslintConfig" keys inside package.json itself	the scripts block (lint, format, check) via npm/yarn/pnpm/bun
pyproject.toml	[tool.ruff], [tool.black], [tool.isort] in it; ruff.toml, .ruff.toml, setup.cfg	ruff format --check, ruff check
Package.swift / *.xcodeproj	.swiftformat, .swiftlint.yml	swift build, swiftformat --lint
go.mod	none — gofmt has no options; only .editorconfig applies	gofmt -l, go vet
any	.editorconfig — language-agnostic, usually authoritative for indentation and EOL	—

Locate configs without scanning the repo root:

git ls-files -- '*rustfmt.toml' '*.editorconfig' '*.prettierrc*' '*prettier.config.*' \
  '*eslint.config.*' '*.eslintrc*' '*biome.json*' '*ruff.toml' '*pyproject.toml' \
  '*.swiftformat' '*.swiftlint.yml' '*dprint.json' '*oxlint.json'

Read each hit with the Read tool. For a grep inside a config (e.g. a key in package.json), use git grep -n "prettier" -- 'package.json'. Never grep -r/find over the repo root — it trips the .env deny rule.

2b. Read real source files

Config can be stale or partially applied; committed code is the truth. List candidates, then Read 5–10 of the same type you are about to edit:

git ls-files -- '*.rs' | head -20
git ls-files -- '*.ts' '*.tsx' ':!*.d.ts' | head -20

Observe directly:

• Indentation: tabs or spaces, how many
• Line length before wrapping; where multi-line breaks kick in for args/arrays/structs
• Quotes (single/double/template/raw) and string-building style
• Statement terminators, trailing commas, bracket/brace spacing
• Brace and where/generic placement; same-line vs next-line opening brace
• Import/use style: grouping, ordering, glob vs explicit, hoisted to file top vs inline paths
• Empty lines: between items, after imports, at block start/end
• Comment style (//, ///, /* */, doc comments, JSDoc) and spacing after the marker
• Error handling idiom (? vs match, exceptions vs result types), naming conventions
• Visibility/export style (named vs default, pub(crate) vs pub, barrel files)
• Test placement: #[cfg(test)] in-file, tests/, *.test.ts, test_*.py

2c. Resolve conflicts

• Config vs committed source disagree → source wins.
• Files of the same type disagree → follow the majority, note the inconsistency, never invent a third style.
• .editorconfig generally overrides a tool's own indentation defaults.

2d. Write the index

Write $CLAUDE_PROJECT_DIR/.claude/code-style-index.json. Include only what you actually observed; drop keys you could not determine; put anything unstructured into notes:

{
  "_meta": { "created": "<ISO date>", "updated": "<ISO date>", "note": "Generated by the code-style skill. Commit this file." },
  "indentation": { "style": "spaces", "size": 4 },
  "maxLineLength": 100,
  "endOfLine": "lf",
  "perLanguage": {
    "rust": { "imports": "hoisted use block at file top, grouped std/external/crate", "tests": "#[cfg(test)] mod tests in-file", "format": "cargo fmt (nightly), no rustfmt.toml overrides" },
    "typescript": { "quotes": "single", "semicolons": false, "trailingCommas": "es5", "bracketSpacing": true, "arrowParens": "always", "exports": "named" },
    "python": { "quotes": "double", "format": "ruff format, line-length 88" }
  },
  "emptyLines": { "betweenFunctions": 1, "afterImports": 1, "atTopOfBlock": 0 },
  "comments": { "inline": "// ", "doc": "///" },
  "subprojectOverrides": {},
  "notes": []
}

Step 3: Apply exactly

1. Match every observed convention — no exceptions, no personal defaults.
2. Never silently "improve" formatting: tabs stay tabs, 4 spaces stay 4 spaces.
3. Don't add or drop semicolons, trailing commas, parens, or type annotations to suit taste.
4. Match empty-line, comment and import-ordering patterns exactly.
5. New files: extrapolate from sibling files of the same type in the same directory.
6. Write what the formatter would produce, so a --check run is a no-op.

Step 4: Keep the index current

Observed a pattern the index does not record? Read it, add the field, bump _meta.updated, write it back. Never delete entries unless they are factually wrong — add a note instead.

What not to do

• Don't scan the whole repo when the index already answers the question.
• Don't run grep -r / rg / find | xargs grep from the repo root, and never name a .env* file in any command — use git grep -n "X" -- '*.ext' with a pathspec, or an absolute-path subtree grep (grep -rn "X" --include='*.rs' /abs/repo/crate/src) for untracked files. Use LSP (goToDefinition, findReferences, workspaceSymbol) for symbols, and the Grep/Glob tools if they are available in this session.
• Don't cd inside a command; use absolute paths.
• Don't reformat files you weren't asked to touch, and don't run a repo-wide formatter as a side effect — running the scoped formatter the project's hooks require before staging (cargo fmt -p <crate>, npm run format) is fine.
• Don't guess a style from one file; 3–5 samples make the pattern obvious.
• Don't leave the index uncommitted — it is a shared cache, it belongs in version control.