When to use this
- New code from a contributor unfamiliar with this repo's conventions.
- Before merging, to catch drift from established patterns (error handling shape, naming, file layout) that a formatter won't catch.
- Not a substitute for an actual linter/formatter -- run those first; this catches convention drift they don't check (e.g. "we always wrap errors with context here").
The skill file
Copy this verbatim. It's written in the SKILL.md format (YAML frontmatter + markdown instructions) that Claude Code, and increasingly other agent tools, read directly.
--- name: style-enforcer description: Check new/changed code against conventions already established elsewhere in this codebase (naming, error handling shape, file organization) rather than an external style guide. Use after the linter/formatter has already run. --- # Style Consistency Checker This is about *this repo's* unwritten conventions, not a generic style guide. Infer the convention from existing code before flagging a deviation. ## How to find the convention 1. Find 3-5 existing files that do something structurally similar to what's in the diff (same kind of module, same layer). 2. Note the shared pattern: how errors are wrapped/returned, how a new dependency is injected/imported, where a new route/handler/test file goes, naming convention for the kind of thing being added. 3. Only flag the diff where it deviates from a pattern that's consistent across those examples -- one existing counter-example means it's not a strong enough convention to enforce. ## What to flag - A new error path that doesn't follow the repo's established error-wrapping shape. - A new file placed outside the directory convention its siblings use. - A name that breaks an otherwise-consistent naming scheme (e.g. every other handler is `handleX`, this one is `xHandler`). ## What NOT to flag - Anything the formatter/linter already auto-fixes. - A pattern you only found once elsewhere -- that's not a convention, that's one file's choice. - Personal preference not backed by an existing pattern in this repo. ## Output List each deviation with the file(s) that show the established pattern, so the fix is "match this," not "trust me."
Installing it elsewhere
The frontmatter/body split above is Claude Code's convention. Here's how to carry the same instructions into other tools:
Save the file below verbatim (frontmatter included) at that path, project-local or in ~/.claude/skills/ for a user-level skill. Claude Code loads the name/description pair to decide when to pull it in, or you invoke it directly as /style-enforcer.
Convert the YAML frontmatter to Cursor's rule format (description, globs, alwaysApply: false) and keep the markdown body as the rule content. Cursor surfaces it by description match, same idea as Claude Code's auto-load.
Codex CLI (and increasingly other agentic CLIs) read AGENTS.md at the repo root as always-on instructions. Paste the markdown body under a heading like ## {title}; for GitHub Copilot's coding agent, the equivalent file is .github/copilot-instructions.md.
Append the markdown body to .windsurfrules at the repo root. Windsurf treats the whole file as always-on context, so keep only the instructions you want applied on every request.
- Flagging a genuinely new pattern as wrong just because it's the first of its kind -- sometimes the new code is right and the old pattern should change.
- Citing a single existing file as "the convention" when the codebase is actually inconsistent about it.
- Re-litigating formatting the linter already enforces.