Profiles

Start with a shared policy, then change only the settings your repository needs.

Choose a starting point

Three profiles, one configuration model

A profile supplies the initial check settings. It is not a separate scan command, a different analyzer version, or a guarantee that every enabled check runs in every project.

Default profile coverage
Profile	Enabled checks	Coverage
`fast`	7	Formatting, lint, cyclomatic and readability complexity, structural security, React correctness, and React DOM accessibility.
`recommended`	9	Everything in fast, plus TypeScript diagnostics and secret detection. This is the default when no profile is specified.
`thorough`	13	Everything in recommended, plus duplication, dependency architecture, dead code, and online vulnerability analysis.

These defaults are verified against the Zedbee 0.1.0 source snapshot. Enabled checks start at error severity and when: "relevant"; checks outside the profile start at off. Workspace applicability and the selected changes still determine what needs to run.

fast does not include secret detection or the dedicated TypeScript diagnostics check. thorough enables online OSV lookups for vulnerability analysis when applicable. Review the coverage and network behavior when choosing a baseline rather than treating the names as equivalent levels of protection.

Compare individual checks and managed engine versions

Initial setup

Select a profile without writing every default

For initial setup, npx zedbee init --profile recommended previews the proposed configuration and hook changes. Review and approve that plan before it writes anything.

For an existing configuration, edit its profile field instead of replacing the file. Preserve repository-specific settings, overrides, and reporting preferences you still need.

The profile fills in omitted settings. You do not need to copy all 13 check policies into the file, and doing so can make it harder to see what your team intentionally changed.

Local and CI scans can share the same profile. The scan command selects staged or committed changes; it does not require a different profile merely because it runs in CI.

Apply a settings change locally and in CI

{
  "$schema": "./node_modules/zedbee/schema/zedbee.schema.json",
  "schemaVersion": 1,
  "profile": "recommended"
}

Profile customization

Change a check without replacing the profile

Repository-level checks settings override the profile. This example keeps the recommended baseline, enables vulnerability analysis, and makes duplication findings warnings rather than blockers. Omitted timing stays relevant.

Changing profile later does not erase explicit settings. For example, switching this file to fast still leaves vulnerabilities enabled and duplication at warn. Remove an explicit setting only when you want it to inherit the profile again.

Use severity to choose off, warn, or error. Use timing to choose relevant or always. Timing controls scheduling within a check’s supported scope; it does not disable attribution or expand a check into a whole-history audit.

Review what vulnerability analysis sends to OSV

{
  "schemaVersion": 1,
  "profile": "recommended",
  "checks": {
    "vulnerabilities": {
      "severity": "error",
      "onUnavailable": "block"
    },
    "duplication": {
      "severity": "warn"
    }
  }
}

Verify the effective policy

Inspect what the repository will actually use

zedbee checks shows effective check settings, their profile or repository source, applicability, and configured overrides. Its JSON output provides the complete machine-readable settings view.

The command reads staged configuration. After an edit, stage the file before inspecting the new policy. Commit and push it for CI runs that check out that update.

The check matrix describes defaults, not your final repository policy. File overrides and exclusions can change the outcome for particular paths, so review those as well as the selected profile.

Understand configuration precedence

git add .zedbeerc.jsonc
npx zedbee checks
npx zedbee checks --format json