File Structure

CodeCharter expects the rule set in a rules/ directory, by default next to the CLI in the workspace. Use the --rules <dir> option to point to any other directory.

Recommended Layout in the Repo

rules/
├── architecture/
│   ├── domain-must-not-reference-web.ccr
│   └── repository-naming.ccr
├── naming/
│   ├── no-manager-suffix.ccr
│   └── async-suffix.ccr
└── team-conventions/
    └── controller-action-limit.ccr
.codecharterignore

Subdirectories under rules/ are freely chosen. CodeCharter reads all .ccr files recursively.

Back-compat: .cgr is the previous rule file extension. CodeCharter still reads .cgr files, so existing rule sets keep working — but new rules should use .ccr. The same applies to the ignore file: .codecharterignore is primary, the legacy .codeguardignore is read when no .codecharterignore is present.

Initializing rules/

codecharter init

Creates a rules/ directory with two example rules that you can grow from.

.codecharterignore

Lives in the solution root and optionally in project directories under src/. Two sections:

# Per-rule ignores: <rule-slug>: <namespace-prefix>
namespace-distance: Acme.Generated
namespace-few-types: Acme.Tests

# Exclude complete paths from analysis
[exclude]
**/tests/**
**/Generated/**
**/bin/**
**/obj/**

The first section disables individual rules for specific namespaces. The [exclude] section removes entire paths from the analysis.

Inline Suppressions

Per location in code:

// codecharter-disable-next-line DateTime-Direct-Usage
var migrationTimestamp = DateTime.UtcNow;

See Suppressions for all variants.

Versioning

Everything under rules/ and .codecharterignore belongs in the repo and in code reviews. When a new rule is added or a severity is changed, it goes through the same PR review as any other code change.

Multi-Repo and Monorepo

In a monorepo you can have rules/ directories per sub-project and point to them with --rules. .codecharterignore is loaded at the solution level and in src/<project>/ directories.