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

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

Tenki Code Reviewer reads your repository's AGENTS.md or CLAUDE.md to apply your team's rules, expectations, and preferences to every review.

Tenki Code Reviewer reads your repository's `AGENTS.md` or `CLAUDE.md` and applies it to every review in that
repository. There is nothing to configure in the dashboard: commit the file and the next review picks it up.

If your repository already has one of these files for coding agents, the reviewer follows it as-is. The same
instructions you give an agent writing the code work for the agent reviewing it.

The 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.
* **Codebase-specific guidance:** Domain assumptions, business rules, or constraints that are unique to your product.

## Example

The 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?**
Commit an `AGENTS.md` or `CLAUDE.md` at the root of your repository. The reviewer finds it on its own; there is no path to register.

**What if my repository has both files?**
`AGENTS.md` takes precedence: when both exist, the reviewer uses `AGENTS.md` and ignores `CLAUDE.md`. They are not merged, so keep your review guidance in `AGENTS.md` (or make `CLAUDE.md` a pointer to it).

**Do nested files in a monorepo work?**
Yes. When the reviewer examines a file in a subdirectory, it also picks up the `AGENTS.md` or `CLAUDE.md` files in the directories above that file, so per-package guidance applies on top of the repository-root file.

**Can each repository have different context?**
Yes. The context comes from the repository itself, so every codebase carries 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.