Policy as code review.

It means your team's review rules live in files the AI reviewer reads on every pull request. Each rule is a markdown file with a YAML frontmatter for scope (path globs, severity, language) and a ## Instructions section in plain English. Architecture boundaries, security patterns, naming conventions, compliance checks all become version-controlled rules. The rules stop being tribal knowledge in senior engineers' heads. They become a real artifact, in the repo, alongside the code.

Generic AI feedback applies the same checks to every codebase. Kody Rules are specific to your team. Generic AI will suggest extracting a function. A Kody Rule will flag a PR with a critical severity finding because the domain layer imported from infrastructure, which violates your architecture rule. Both run, both add value, but only one knows your team's actual standards.

Two locations work out of the box: .kody/rules/**/*.md or rules/**/*.md. Each file is one rule. Kodus also auto-detects rule files your team already keeps for IDEs and agentic tools (.cursorrules, CLAUDE.md, .windsurfrules, .github/copilot-instructions.md, .sourcegraph/**/*.rule.md, .aider.conf.yml). If you do not want files in the repo at all, author rules in the dashboard at app.kodus.io. All three sources merge into one rule set per pull request.

YAML frontmatter plus a markdown instructions section. Required frontmatter fields: title, scope ("file" or "pull_request"), path (array of globs), severity_min (low, medium, high, critical). Optional: languages, buckets, enabled. The body after the frontmatter is a ## Instructions heading followed by free-form English describing the rule. No DSL to learn.

Yes, through the path field. A rule with path: ["services/payments/**"] only fires on diffs that touch that folder. Rules inherit Global → Repository → Directory, with directory scoping done via path globs in single rule files. Monorepos with five teams run five overlapping rule sets without conflict. Branch-level scoping is not supported today.

Yes, through Automatic Rules Generation. Kodus reads three plus months of historic review comments, clusters the patterns your team enforces by hand, and surfaces them as draft rules in the dashboard. Generated rules are not active by default. You review the drafts, edit if needed, and import the ones you want enabled. Updates run weekly after the initial generation.

Yes, twice over. Rule files live in git, so every change is a commit with author, reviewer, diff, and timestamp. Every finding generated by a rule is logged in the dashboard with the rule id, file, severity, PR author, and timestamp. The audit log is exportable as CSV or JSON for compliance reviews.

A rule emits a finding with a severity level (low, medium, high, critical). What happens with the finding depends on the Policy layer: by default Kody posts non-blocking suggestion comments. Optionally, you can turn on Request Changes so high or critical findings mark the review as changes-requested. Or Auto-approve when no findings hit the configured severity floor. Severity comes from the rule, action comes from the policy.

SonarQube custom rules require a Java plugin or XPath expressions, apply at the project level, and stop at syntactic patterns. Kody Rules are markdown files with plain-English instructions, scope by path glob, and run semantic checks (an AI reviewer reading the rule, not a regex). You can run both: SonarQube for static analysis, Kodus for the rules your team actually argues about in code review.

Yes. Discovery Rules is a curated library inside the Kodus dashboard. Filter presets by severity, language, or tag (Security, Maintainability, Style conventions, Testing, Performance). Import the ones you want with one click and edit them like any other rule. Examples shipped today include “disallow MD5 hashing” and “React components under 150 lines.” Docs at docs.kodus.io have the full reference for Kody Rules.