# Custom Context (https://tenki.cloud/docs/reviewer/custom-context)

> For the complete documentation index, see [llms.txt](https://tenki.cloud/llms.txt)

Custom Context allows you to define repository-specific rules, expectations, and team preferences for the agent.

![TenkiCodeReviewerCustomContext](https://tenki.cloud/images/reviewer/custom-context.png)

For each repository, Tenki Reviewer can use a configuration file to define custom rules and specific settings.

This file provides persistent guidance that Tenki Code Reviewer applies to every review in that repository.

Manually create the `.md` file and save it in your codebase. Then, add its path to the Custom Context Panel so it can be applied to the selected repository.

![TenkiCodeReviewerCustomContext](https://tenki.cloud/images/reviewer/tcr-custom-context.png)

The Custom Context file is intentionally flexible. You can include **any instructions you want the agent to consistently apply**, for example:

* **Team rules you always want reviewed:** Coding standards, security requirements, architectural constraints, or internal best practices.
* **Areas to focus on:** Critical paths, high-risk modules, legacy code, or performance-sensitive components.
* **Things to ignore:** Generated files, vendor code, migrations, or any changes you don’t want reviewed.
* **Project-specific guidance:** Domain assumptions, business rules, or constraints that are unique to your product.

## Example

A Custom Context file is plain Markdown. Keep it focused and concrete, since the agent applies it on every review, so clear, specific rules produce the most consistent results:

```md
# Review context for our API service

## Always flag

- Endpoints that touch user data but don't check authorization
- New environment variables that aren't documented in `README.md`
- SQL built with string interpolation instead of parameterized queries

## Focus areas

- `src/billing/**` is high-risk; review pricing and rounding logic carefully
- Public API handlers in `src/api/**` must keep backward compatibility

## Ignore

- `**/*.generated.ts` and other generated output
- Lockfiles (`pnpm-lock.yaml`, `package-lock.json`)
- Snapshot test fixtures

## Conventions

- We use Conventional Commits; call out PR titles that don't follow it
- Prefer early returns over nested conditionals
```

## Best practices

* **Be specific.** "Flag missing authorization checks on user-data endpoints" guides the reviewer far better than "be careful about security."
* **Point to paths.** Naming directories (`src/billing/**`) lets the agent weight high-risk areas appropriately.
* **State what to ignore.** Explicitly excluding generated files and lockfiles keeps reviews signal-dense and avoids wasting the context window.
* **Keep it current.** Treat the file like code, updating it as your standards evolve so reviews stay aligned with how your team actually works.

## Frequently asked questions

**Where does the file live?**
Anywhere in your repository. Create the Markdown file, commit it, then add its path in the Custom Context Panel for that repository.

**Can each repository have different context?**
Yes. Custom Context is configured per repository, so every project can carry its own rules, focus areas, and exclusions.

**Does Custom Context replace the default review?**
No. It layers your repository-specific guidance on top of Tenki's standard bug, security, and quality checks; it doesn't turn them off.