> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kodus.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Kodus for monorepos

> Configure directory-level rules, path-specific overrides, and rule inheritance to get precise code reviews in a monorepo.

## 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:

```yaml theme={null}
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](/en/how_to_use/code_review/configs/directory_level). For rule inheritance, see [Rules Inheritance](/en/how_to_use/code_review/configs/rules_inheritance).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.