Zum Inhalt springen

Search and adopt rules from the CodeCharter catalog

Search the curated CodeCharter rule catalog before you write a new rule, and adopt a matching one into your own rule set.

Updated on 2026-09-01

Before you write a rule from scratch, check whether it already exists. The Examples tab on the Rules page is a searchable catalog of CodeCharter's curated example rules, maintained centrally and shared across all organizations. You can browse it, read any rule's full source, and adopt it into your own rule set under a slug you choose. The same catalog is reachable from the command line and from an AI assistant, so the "does this already exist?" check fits wherever you happen to be working.

What the catalog contains

The catalog holds CodeCharter's built-in example rules: working .ccr rules with a test specification, covering common patterns across categories such as naming, structure, documentation, and SOLID design. They are curated centrally, not authored by your organization, so they show up identically for every customer. Use them as-is by adding them to a profile, or adopt one as a starting point and adjust it to your own conventions.

Your organization's own rules live separately, in the Mine tab; see Managing rules for creating, editing, and publishing those.

Browsing and searching

Open the Examples tab on the Rules page. The search box matches by name, category, and rule content, and updates as you type. Category and Severity facets narrow the list further; toggle one or more values to filter. Each result card shows the rule's name, slug, category, and default severity.

Reading a catalog rule

Click a card to open its detail page. It shows the rule's slug, published version, and severity, and splits into two panes:

  • .ccr source — the actual rule logic, with a Copy button.
  • Spec — the test specification (hits and misses), toggleable between a rendered preview and the raw Markdown.

Adopting a rule

Click Adopt on a card or on the detail page to copy the rule into your own rule set. The dialog prefills a free target slug based on the catalog rule's slug (appending -copy, then -copy-2, and so on if that slug is already taken in your organization), and checks the slug you choose against your existing rules as you type.

Confirming creates a new rule in your Mine tab under the target slug, with the catalog rule's source, spec, category, and severity copied into its first draft. From here it behaves exactly like a rule you wrote yourself: open it in the rule editor, run the specs, adjust the DSL or the spec to your needs, and publish a version when you are ready.

The copy is a one-time snapshot. The new rule carries no ongoing link back to the catalog rule or its version: later updates to the catalog rule do not affect a rule you already adopted, and your adopted rule does not appear as a variant of the original anywhere in the catalog. If you want a newer version of a catalog rule you previously adopted, adopt it again under a different slug and compare, or reconcile the change by hand.

Searching from the command line

codecharter rules search runs the same search against the same catalog, so a does this exist? check works from a terminal or a script without opening the portal:

codecharter rules search "unused parameter" --category naming --severity warn

The query is a free-text argument; omit it to browse the catalog in a stable order. Flags:

Flag Purpose
--scope Which corpus to search: example (the curated catalog, default) or mine (your own rules).
--category Category filter, repeatable (OR across values).
--severity Severity filter, repeatable (OR across values): info, warn, error.
--tag Tag filter, repeatable; a hit must carry every tag passed.
--in-profile Restrict to rules used (true) or unused (false) in a profile.
--page / --page-size Pagination; page size defaults to 25 and is capped at 100.
--portal-url Portal base URL (defaults to the hosted portal).
--api-key Bearer API key; falls back to your installed license when omitted.

The command prints the matching rules with their slug, category, severity, latest version (or unpublished), how many profiles reference them, and a relevance score, followed by the facet counts for category, severity, and tag. It exits 0 once the search completes, regardless of hit count, and 2 on a usage error, an unreachable portal, or a missing credential.

Searching from an AI assistant

The MCP server exposes the same catalog as the search_rules tool. An assistant with the CodeCharter MCP server installed should call search_rules before scaffold_rule when you ask it to write a new rule: a hit means adapting an existing rule instead of writing the same detection twice. search_rules accepts a free-text query, the same scope, categories, severities, tags, and in_profile filters as the CLI, and returns matches with facet counts so the assistant can suggest a narrower search instead of guessing. See MCP rule authoring for the full tool reference and the authoring loop it fits into.

From adopted rule to CI

An adopted rule starts life exactly like a new one: as a draft in your Mine tab. To put it to work:

  1. Open it in the rule editor, adjust the source or spec as needed, and run the specs.
  2. Publish a version once the specs pass (see Publishing).
  3. Add the published rule to a profile and publish a profile version — that is what your CI pipelines reference.