Add Tenki AI Code Review to GitHub in Under 30 Minutes

Most teams spend more time configuring code review tooling than they do reading the first review it produces. The setup sprawls across workflow YAML, token permissions, runner labels, and threshold configs that each require a separate doc page to understand.

Tenki Code Reviewer takes a different approach. It's a GitHub App, not a GitHub Action. You install it, connect your repos, and reviews start appearing on your next pull request. No workflow files to write, no runner labels to configure, no token scopes to debug. The whole process takes about five minutes if you already have a Tenki account, and maybe ten if you're starting from scratch.

This guide walks through the full path: installing the app, reading your first review, tuning the severity threshold so it matches your team's risk tolerance, and promoting Tenki to a required status check so nothing merges without it.

Step 1: Install the Tenki Reviewer GitHub App

Tenki doesn't require a YAML workflow definition. It runs as a GitHub App that listens to pull request events directly through GitHub's webhook system. That means zero changes to your existing CI pipeline.

Here's the setup sequence:

1. Create a Tenki account. Go to app.tenki.cloud/auth/registration and sign up with email or your GitHub account. No credit card required.
2. Open the Code Reviewer panel. Select your project in the Tenki dashboard and navigate to the Code Reviewer tab.
3. Install the GitHub App. Click the connect button to install the Tenki Reviewer GitHub App on your organization. GitHub will ask you to authorize and choose which repositories to grant access to. You can select all repos or pick specific ones.
4. Open a pull request. That's it. Tenki will automatically review the PR and post its findings as comments.

The whole thing takes less than five minutes. If you're a team lead rolling this out, the person doing the install needs admin access to the GitHub org (to authorize the app) and that's the only permission requirement on your side.

If you don't want to wait for a new PR, you can trigger a review on any existing open PR by tagging @tenki-reviewer in a comment. Useful for testing on a PR you already know has issues.

Step 2: Reading Your First Review

When Tenki reviews a PR, it posts two comments simultaneously: a Summary and a Review Comment. Both appear immediately and update live as the analysis runs. You'll see a 👀 emoji while it's working and a 👍 when the analysis is complete. The whole process typically takes about three minutes.

The Summary

The Summary is a high-level, decision-oriented overview. It tells you what was reviewed, groups findings by severity, gives a short recap of key issues, lists the files examined, and includes a security risk assessment.

The security assessment is one of three levels:

• LOW — no security vulnerabilities identified
• MEDIUM — security edge cases introduced
• HIGH — exploitable vulnerabilities found

This is the comment your team lead or on-call reviewer should read first. It answers the question "should I look at this PR more carefully?" in about ten seconds.

The Review Comment

The Review Comment is the detailed breakdown. It's organized into three sections:

• Security — findings with severity levels and explanations
• Code Quality — structural or maintainability concerns
• Other Observations — performance risks, architectural concerns, repeated anti-patterns

At the bottom of every Review Comment is a single recommendation: APPROVE, APPROVE with minor suggestions, or CHANGES REQUESTED. This is what matters for merge gating, which we'll set up later.

One thing to note: Tenki only reports issues introduced by the PR itself. It won't flag pre-existing problems in the codebase or things that can't be addressed within the PR's scope. That keeps the noise level low and means every finding is actually actionable by the PR author.

What to Do If the Review Fails

If you see the 😕 emoji instead of 👍, the analysis failed. This usually means the PR is too large for a single analysis pass. Tag @tenki-reviewer in a comment to retry. If it fails again, break the PR into smaller chunks or exclude auto-generated files like lockfiles and schema dumps.

Step 3: Tune Your Severity Threshold

Out of the box, Tenki only surfaces High severity findings. That's the right default for most teams on day one because it keeps the signal-to-noise ratio tight. You'll only see things that are genuinely merge-blocking: security vulnerabilities, data-loss risks, logic errors that would break production.

But after a week or two of running, you'll have a feel for how much Tenki catches and whether you want more coverage. The severity threshold setting lives in the Tenki dashboard under Settings for your connected repository. You can enable three levels:

• High only (default) — merge-blocking signal. Best for teams that want Tenki to stay quiet unless something is genuinely wrong.
• High + Medium — adds security edge cases and code quality concerns. Good for teams in a hardening phase or preparing for a security audit.
• High + Medium + Low — full coverage including minor observations. Useful during refactors, new team onboarding, or when you want the most thorough feedback possible.

My recommendation: start with High only. Run it for a sprint. If your team is constantly saying "I wish Tenki had caught that earlier," bump it to High + Medium. If nobody reads the Medium findings, drop back down. There's no penalty for changing it.

Adjusting Comment Verbosity

Separate from severity, you can control how much detail Tenki puts into each finding. The Comment Detail Level setting has three modes:

• Concise — brief vulnerability overview, just enough to act on
• Standard (default) — a few sentences per issue with enough context to understand the problem
• Detailed — in-depth explanations of each finding, good for teams where the PR author might not immediately understand the security implications

Standard works well for most teams. If your engineers are senior and just want the what without the why, try Concise. If you're onboarding junior developers who benefit from the educational context, try Detailed.

Step 4: Add Custom Context for Your Repo

Generic code review catches generic problems. To get the most out of Tenki, give it context about your specific codebase.

Create a markdown file in your repository (call it whatever you want, something like .tenki/review-context.md works) and add the file path in the Custom Context panel in your Tenki dashboard. Tenki applies this context to every review in that repo.

What goes in the file is up to you. Some things that work well:

• Team coding standards and architectural constraints
• Critical paths and high-risk modules that deserve extra scrutiny
• Files to ignore (generated code, vendor directories, migrations)
• Domain-specific business rules the reviewer wouldn't know from the code alone

This step is optional but it makes a real difference. A five-minute context file turns a generic reviewer into one that knows your project's conventions.

Step 5: Make Tenki a Required Status Check

This is the step most teams skip on day one, and it's the one that actually makes Tenki a merge gate instead of just a comment bot.

Once Tenki has reviewed at least one PR in your repo, its check name will appear in GitHub's list of available status checks. You can then require it in your branch protection rules:

1. Go to your repository's Settings > Branches (or Settings > Rules > Rulesets if you're using the newer rulesets UI)
2. Edit (or create) a branch protection rule for your default branch
3. Enable "Require status checks to pass before merging"
4. Search for the Tenki check name and add it as a required check

Now when Tenki issues a CHANGES REQUESTED verdict, the PR physically can't be merged until the issues are addressed and the review passes. The merge button goes gray. No one can bypass it unless they have admin override permissions.

If you're using GitHub's newer repository rulesets instead of branch protection rules, the same approach applies. Rulesets support status checks as a requirement and they let you apply the rule across multiple repositories from the org level, which is useful if you're rolling Tenki out to many repos at once.

Common First-Run Issues

A few things trip teams up during the first day. Here's what to check:

Tenki doesn't review a PR. The most common cause is that the GitHub App doesn't have access to the repo. Go back to your GitHub organization settings, find the Tenki Reviewer app under Installed GitHub Apps, and confirm the repository is in the allowed list. If you selected "Only select repositories" during install, you need to add new repos manually.

Tenki doesn't respond to @tenki-reviewer. Double-check the app installation. Verify that workflows are enabled and that the API key is set in your repository secrets. Also make sure you're tagging the correct handle.

"Context Window Exceeded" error. The PR is too large. Break it into smaller PRs, or exclude auto-generated files like package-lock.json, lockfiles, and generated schemas using an ignore list.

Reviews on bot PRs you don't want reviewed. Use the Ignore Usernames setting to exclude Dependabot, Renovate, or any other automation accounts from triggering reviews. Or set Automatic Review to Off and trigger reviews manually on the PRs that matter.

If none of these solve it, reach out to hello@tenki.cloud or use the in-app chat. The support team is responsive.

Where to Go From Here

Once the basic setup is working and your team has a sprint's worth of reviews under their belt, there are a few natural next steps:

• Per-repo Custom Context. Each repository can have its own context file. A payments service should have different review priorities than a marketing site. Write context files that reflect each repo's risk profile.
• Org-wide rollout. When you install the Tenki GitHub App, you can grant it access to all repositories in your org at once. Pair that with org-level rulesets to require the Tenki status check across every repo without configuring branch protection one by one.
• Different severity per repo. Your core API might run at High + Medium while internal tooling stays at High only. Tenki's settings are per-repository, so you can tune each one independently.
• Pair with Tenki Runners. If your CI is already on GitHub Actions, Tenki Runners can speed up builds by up to 30% and cut costs by up to 60% compared to GitHub-hosted runners. Code review and CI from one platform.

The whole point of starting with a minimal setup is that it costs you almost nothing to try. Five minutes of installation, one PR to see the output, and you'll know whether it catches things your team currently misses. At $1 per review, the math is pretty simple: if Tenki catches one bug per week that would've otherwise made it to production, it pays for itself many times over.