Kodus for monorepos

The challenge

In a monorepo, different packages have different standards. Your React frontend cares about component patterns, your NestJS backend cares about dependency injection, and your shared libs care about API stability. A one-size-fits-all review doesn’t work.

Strategy overview

Kodus supports three config levels that map naturally to a monorepo:

Level	Applies to	Example
Global	All repos	”Never commit `.env` files”
Repository	The monorepo	”Use conventional commits”
Directory	A specific package	”React components must use PascalCase”

Step 1 — Map your packages

Identify the distinct areas in your monorepo and their review needs:

monorepo/
├── apps/
│   ├── web/          → React rules, component patterns
│   ├── api/          → NestJS rules, architecture boundaries
│   └── mobile/       → React Native rules
├── libs/
│   ├── shared/       → API stability, breaking change detection
│   └── ui/           → Design system compliance
└── infra/            → Terraform/IaC rules

Step 2 — Create directory-level configs

In the sidebar, open the scope picker at the top of the Code review group and choose Add repository configuration. In Create repository settings, Select the target repository (the monorepo), then Select the target directories (one or more package folders) and click Create settings. Each directory appears indented under the repository in the scope picker — pick it to configure it. Each directory can have its own:

Kody Rules (file-level and PR-level)
What to review (which categories to enable, and the minimum severity to post)
Ignored files (on General)

Step 3 — Write targeted rules

Frontend rules (scope: `apps/web/`)

Name: React components must use design system tokens
Execution mode: Per file
Path: apps/web/src/components/**/*.tsx
Severity: High
Instructions:
  Check fileDiff for hardcoded colors, spacing, or font sizes.
  Components must import tokens from @file:libs/ui/src/tokens.ts.
  Flag any hex color, pixel value, or font-size not from the token file.

Backend rules (scope: `apps/api/`)

Name: Domain layer must not import from infrastructure
Execution mode: Per file
Path: apps/api/src/domain/**/*.ts
Severity: Critical
Instructions:
  Check fileDiff for any import from "../infrastructure",
  "../../infrastructure", or any path containing "/infrastructure/".
  Domain modules must only depend on other domain modules
  and shared interfaces.

Shared library rules (scope: `libs/shared/`)

Name: Public API changes require changeset
Execution mode: Per PR
Severity: High
Instructions:
  If pr_files_diff modifies any file in libs/shared/src/index.ts
  or adds/removes exports, check that a changeset file exists
  in the .changeset/ directory. If missing, flag it as a
  potential breaking change without documentation.

Step 4 — Use Memories for cross-cutting conventions

Some conventions apply everywhere. Teach them as Memories:

@kody remember: in this monorepo, all packages use ESM imports.
CommonJS require() is not allowed anywhere.

@kody remember: shared libs must maintain backward compatibility.
Any breaking change requires a major version bump and a changeset.

Step 5 — Set the severity threshold per directory

High-traffic packages might need stricter filters. Pick the directory in the scope picker, open What to review, and set Minimum severity to post:

apps/web/ — Medium (frontend moves fast)
libs/shared/ — Low/All (stability matters)
infra/ — High (fewer but critical)

Step 6 — Ignore generated paths

Add monorepo-specific ignores to avoid noise:

ignorePaths:
  - "**/node_modules/**"
  - "**/dist/**"
  - "**/build/**"
  - "**/*.generated.ts"
  - "**/prisma/migrations/**"
  - "**/coverage/**"

Tips

Start with 2-3 rules per directory and expand based on what your team actually flags in reviews
Use rule inheritance — org-level rules cover security, repo-level covers conventions, directory-level covers architecture
If a rule fires too often in one package but is valid elsewhere, exclude that directory from the rule rather than weakening it

For more on directory configs, see Directory-Level Configuration. For rule inheritance, see Rules Inheritance.

Custom Plugins

Custom Context Playbooks

Recipes

LLM Provider Setup

Kodus for monorepos

The challenge

Strategy overview

Step 1 — Map your packages

Step 2 — Create directory-level configs

Step 3 — Write targeted rules

Frontend rules (scope: `apps/web/`)

Backend rules (scope: `apps/api/`)

Shared library rules (scope: `libs/shared/`)

Step 4 — Use Memories for cross-cutting conventions

Step 5 — Set the severity threshold per directory

Step 6 — Ignore generated paths

Tips

​The challenge

​Strategy overview

​Step 1 — Map your packages

​Step 2 — Create directory-level configs

​Step 3 — Write targeted rules

​Frontend rules (scope: apps/web/)

​Backend rules (scope: apps/api/)

​Shared library rules (scope: libs/shared/)

​Step 4 — Use Memories for cross-cutting conventions

​Step 5 — Set the severity threshold per directory

​Step 6 — Ignore generated paths

​Tips

The challenge

Strategy overview

Step 1 — Map your packages

Step 2 — Create directory-level configs

Step 3 — Write targeted rules

Frontend rules (scope: `apps/web/`)

Backend rules (scope: `apps/api/`)

Shared library rules (scope: `libs/shared/`)

Step 4 — Use Memories for cross-cutting conventions

Step 5 — Set the severity threshold per directory

Step 6 — Ignore generated paths

Tips