Custom Context
Custom Context allows you to define repository-specific rules, expectations, and team preferences for the agent.
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.
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:
# 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 conditionalsBest 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.