Loading

Integrations

Natural-language style rules in AGENTS.md get followed inconsistently, especially in a long session where the style section is thousands of tokens back in context. Every formatting correction is a round trip: the agent writes a file, the build reports IDE0055 diagnostics, the agent edits, the build reruns. Each lap costs tokens and latency, and every edit has exactly one right answer already written in your .editorconfig.

The fix is to make the build apply style rather than telling the agent about it:

<PackageReference Include="curb" Version="*" PrivateAssets="all" />
		

Curb runs before CoreCompile. By the time the compiler reads your source, the mechanical offences are gone — not reported, not queued for a follow-up edit, gone.

Delete the style section. Replace it with a line that tells the agent the problem is handled:

## Style
Formatting and syntax-level code style are applied automatically by the build — see `.editorconfig`.
Do not hand-format code, and do not "fix" formatting you see in a diff; `dotnet build` will do it.
		

That last clause earns its place. Without it, a diligent agent that notices misformatted code will helpfully reformat it by hand, which is the behaviour you were trying to eliminate.

Then put the actual rules where they belong:

[*.cs]
indent_style = tab
max_line_length = 160
csharp_new_line_before_open_brace = all
csharp_prefer_braces = true
csharp_style_namespace_declarations = file_scoped
csharp_preferred_modifier_order = public,private,protected,internal,static,readonly,async
		
Scope What happens
All layout Indentation, spacing, brace placement, blank lines, reflow — 100% of them. Nothing in this class reaches the context window.
Syntax style (opt-in) Braces, expression bodies, file-scoped namespaces, modifier order, using placement — for every key you set.
Semantic remainder (after build) var, unused usings, readonly and more. curb cleanup reads the build's diagnostics and applies the rewrites. See Cleanup.
Not handled, deliberately Naming, unused members, unread assignments. Their fixes can compile and still change which overload binds. Curb reports them and says why.

See AI coding agents for more detail on why the pass split makes this possible.

The MSBuild package runs Curb as part of every dotnet build — formatting before CoreCompile in debug, checking in release. When nothing changed, MSBuild skips the target entirely via stamp file. When one file did change, a formatting cache skips every file that is still formatted. See MSBuild integration for full configuration options and how to scope formatting to specific projects.

In CI, use curb check rather than curb format. It exits non-zero if any file would change, and changes nothing.

curb check ./src
		

A typical GitHub Actions step:

- name: Check formatting
  run: curb check ./src
		

If you use the MSBuild package, the build integration already checks in Release configuration. You may not need a separate step at all. The MSBuild integration rewrites in Debug and checks in Release by default.

Formatting is applied deterministically, so a pull request contains its actual change and nothing else. Reviewers stop reading past whitespace.

curb check can be used as a git pre-commit hook to catch formatting issues before they are committed. Point --cache at .git/curb.cache and most runs cost a hash comparison per file rather than a full parse — .git/ is never committed, and entries expire after seven days, so nothing has to clean up behind it.

#!/bin/sh
curb check --cache .git/curb.cache ./src
		

Save to .git/hooks/pre-commit and make it executable (chmod +x .git/hooks/pre-commit).

With Husky.NET:

{
  "command": "curb",
  "args": ["check", "--cache", ".git/curb.cache", "./src"],
  "pathMode": "absolute"
}
		

Add this task to your .husky/task-runner.json. Husky handles the hook installation for the whole team.

Curb verifies every file before writing it and leaves anything that fails verification untouched. See Safety.