> For the complete documentation index, see [llms.txt](https://kerno.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kerno.gitbook.io/docs/guides/how-to-customize-kerno-with-custom-rules.md).

# How to Customize Kerno with Custom Rules

Learn how to add a custom rule, apply it to your entry points, and edit or remove   rules as your team's conventions change.

### Introduction

Custom rules are standing guidance you keep in your repository, so Kerno applies them on every run without you restating them. They shape how the planner writes tests, and they travel with your code.

In this guide, you will add a rule, apply it to an entry point, and then edit and remove rules. For how rules are weighed, merged, and matched to entry points, see [Custom Rules](/docs/core-concepts/custom-rules.md).

### Prerequisites

Before you begin, you will need:

* [Kerno installed](/docs/getting-started/quickstart.md) and connected to your coding agent over MCP.
* Your application running, with the [Kerno test environment configured and ready.](/docs/guides/start-the-environment.md)

### Step 1. Add a rule

The quickest way to add a rule is to ask your agent:

```
Add a Kerno rule for POST /api/users: a duplicate email should return 409.
```

Your agent writes the rule into `.kerno/config.yaml` under `test-generation`. That file is committed, so your team inherits your rules. A `context` block applies to every entry point, and an `endpoints` map scopes guidance to specific routes:

```
test-generation:
  context: |
    ...
  endpoints:
    "POST /api/users": |
      ...
```

You can also edit this file by hand. The entry point pattern grammar is covered in [Custom Rules.](/docs/core-concepts/custom-rules.md)

### Step 2. Apply and verify

A new rule shapes the next `generate` for an entry point that has no tests yet. Ask your agent to generate that entry point:

```
Use Kerno to generate tests for POST /api/users.
```

When the plan comes back for review, the guidance shows up in the scenarios it proposes, here a scenario covering the duplicate-email case. Approve the plan to implement them.

### Step 3. Apply a rule to an entry point that already has tests

To bring an entry point that already has tests in line with a new rule, ask your agent to update its tests:

```
Use Kerno to update the tests for POST /api/users to follow the new duplicate-email rule.
```

Kerno keeps the tests that still apply, revises the ones the rule changes, and adds the ones it is missing. Editing the config on its own leaves existing tests as they are, see [Custom Rules](/docs/core-concepts/custom-rules.md). Generating again keeps the tests you already have, and generating with new one-off guidance replaces the whole suite with a fresh plan once you approve it.

### Step 4. Edit or remove a rule

Ask your agent to change or remove a rule:

```
Update the Kerno rule for POST /api/users to also assert the response includes the created user id.

Remove the Kerno rule for POST /api/users.
```

You can also edit `.kerno/config.yaml` by hand, change a rule's text to edit it, or delete its `context` block or `endpoints` entry to remove it.

Edits and removals behave like additions. They change what Kerno plans on the next run, and they leave existing tests untouched. Update the affected entry points' tests when you want the change to apply.

Where several rules match the same entry point, Kerno applies all of them, and guidance you give for a single run takes precedence when they conflict. For the full merge and precedence order, see [Custom Rules](/docs/core-concepts/custom-rules.md).

### Conclusion

That is the rule lifecycle. Add a rule, generate to apply it, and edit or remove it as your conventions change, updating the affected entry points' tests each time. From here, see [Custom Rules](/docs/core-concepts/custom-rules.md) for how rules are weighed and matched, [Testing modes](/docs/references/testing-modes.md) for per-run guidance, and [How to Review your Code Changes](/docs/guides/validate-code-changes.md) for the everyday validation loop.