Configure Critiq | Critiq Docs

#Config path

text

.critiq/config.yaml

Configuration is optional for a first run. When the file is missing, the CLI falls back to OSS defaults from @critiq/rules.

Add a config file when you want a repository-specific policy: a stricter preset, disabled categories that are not relevant to the codebase, ignored generated paths, or severity changes that match how your team triages findings.

#Full example

yaml

apiVersion: critiq.dev/v1alpha1
kind: CritiqConfig
catalog:
  package: "@critiq/rules"
preset: recommended
disableRules: []
disableCategories: []
disableLanguages: []
includeTests: false
ignorePaths: []
severityOverrides: {}

#Field reference

Field	Requirement
`apiVersion`	Must be `critiq.dev/v1alpha1`.
`kind`	Must be `CritiqConfig`.
`catalog.package`	Optional; defaults to `@critiq/rules`.
`preset`	`recommended`, `strict`, `security`, or `experimental`; defaults to `recommended`.
`disableRules`	Rule IDs to remove from the active set.
`disableCategories`	Top-level or dot-delimited categories such as `security` or `security.injection`.
`disableLanguages`	Languages to exclude from scan scope: `typescript`, `javascript`, `ts`, `js`, `python`, `go`, `java`, `php`, `ruby`, `rust`.
`includeTests`	Defaults to `false`; test files are excluded unless this is enabled.
`ignorePaths`	Glob patterns applied after built-in ignores.
`severityOverrides`	Map of rule ID to `low`, `medium`, `high`, or `critical`.

#Presets

Presets choose the default active rule set before your repository-level disables and overrides are applied.

Preset	Use when
`recommended`	You want the default high-signal checks for everyday local and CI use.
`strict`	You want broader quality, maintainability, and performance coverage and are prepared to tune the results.
`security`	You want security-focused checks for auth, injection, secrets, filesystem, network, and transport risks.
`experimental`	You want to inspect newer rules separately before making them part of the default review gate.

#Scoping rules

Use the smallest disable that describes the policy decision. Disable a rule when one check is not relevant, disable a category when a whole class of findings does not apply, and disable a language when that adapter should not inspect the repository.

yaml

disableRules:
  - ts.logging.no-console-log
disableCategories:
  - security.transport
disableLanguages:
  - ruby
ignorePaths:
  - "dist/**"
  - "generated/**"

#Severity overrides

Severity overrides keep a rule active while changing how urgently the finding should be handled in your project. This is usually better than disabling a rule when the finding is still useful but not release blocking.

yaml

severityOverrides:
  ts.quality.magic-numbers-or-strings: low
  security.no-hardcoded-credentials: critical

#Behavior notes

Invalid config fails the scan.
The legacy critiq check "<rules-glob>" . form is rejected. Put rule selection in .critiq/config.yaml instead.
Disable rules and categories only when the finding is not relevant to the repository. Prefer severity overrides when the rule should still run.

#Validate changes

After changing local rules or rule specs, validate them before relying on the scan in automation.

bash

npx critiq rules validate ".critiq/rules/*.rule.yaml"
npx critiq rules test ".critiq/rules/*.spec.yaml"

#Next links

Browse active rules Open check reference