Custom Context

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:

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