Reviewing pull requests

Indent reads the diff, runs and tests the code, works with you in the comments, and pushes commits to the branch — turning a raw pull request into one that’s ready to merge.

Enable review on a repository

Review is configured per repository under Code Review. Select a repository to open its settings:

• Review new PRs automatically — review every pull request when it opens. When this is off, the repository is inactive and Indent reviews only the pull requests you opt in to.
• Review mode — how reviews continue after the first one. Fully automatic keeps reviewing as new commits and check results arrive. Initial review only runs one round, then waits for you to ask for another.
• Maximum review cost — pause further reviews once a pull request has cost more than this amount. Leave it empty for no limit.
• Only review specific authors / Exclude authors — limit automatic review to an allowlist of authors, or skip pull requests from specific authors.
• Ignore draft PRs — skip drafts and start when the pull request is marked ready. On by default.
• PR summary comment — include a summary of the change in the review comment.
• CI failure summary — explain failed required checks.
• Wait for full analysis before commenting — hold the review until analysis finishes, instead of posting incrementally.
• Environment — run the review inside one of your environments so Indent can build and test the code.

To connect a repository first, see Connecting GitHub.

Start a review

Depending on the repository’s settings, Indent reviews either every pull request when it opens or only the ones you opt in to. To opt one in, add the indent label or mention @indent in a comment. This works even when automatic review is off. To opt one out, add the indent-ignore label. Indent skips drafts by default.

Read the review

Indent posts a single review comment and keeps it current as the pull request changes. It has three parts, in order:

• PR Summary — what the change does, in a collapsible section.
• Issues — each problem Indent found. Indent also posts every issue as an inline comment on the relevant lines.
• CI Checks — the state of the required checks at the latest commit, and which ones failed.

Each issue carries a severity:

• critical — breaks functionality, security, or data.
• functional — incorrect behavior.
• latent — a potential future issue with a trigger condition.
• nit — style or a minor point.

For example, Indent raises an accessibility issue:

Issues — 1 potential issue found Locked-selector tooltips are hover-only: the tooltip trigger is a non-focusable <span>. Keyboard and screen-reader users focusing the actual control never get the “can’t be changed” explanation.

Iterate in the comments

Reply to keep working with Indent:

• In an inline thread, reply directly. Indent responds without a mention.
• In a top-level comment, mention @indent.

Ask Indent to explain a finding or make a change. When you request a change, Indent edits the code, verifies it, and pushes a commit to the branch.

For example, a reviewer rejects the proposed approach and Indent implements an alternative:

jsegaran: @indent I don’t want to fail back compat. Lets have a default indent: Done — switched queryId to z.string().default("") instead of required, so nothing breaks on back compat. Added a decode test for a legacy call without queryId. Green locally: typecheck, lint, fmt, and the events/agent/session-processor suites.

A review is a multiplayer session, so anyone on the team can join the comments and steer the work.

You can also tell Indent to work directly with the pull request. @indent rebase rebases the branch onto its base, resolves conflicts, and force-pushes.

Ask for another review

In Initial review only mode, and on any pull request where Indent has stopped reviewing automatically, start a fresh round two ways:

• Select Request review in the review comment.
• Mention @indent in a comment on the pull request.

Either way Indent reviews the current head commit with the current check results, and reports which commit it reviewed. Adding the indent label doesn’t start a round once Indent has stopped reviewing automatically.

Cap what a review costs

Set Maximum review cost on the repository to stop a single pull request from consuming an unbounded amount of credit. The amount is what the review is billed to your organization, at least $0.01, and an empty field means no limit.

When a pull request passes the limit, Indent stops reviewing new commits and says so in the review comment:

Cost limit reached. Indent will no longer automatically review PR updates. Request another review below whenever needed.

Each further round needs its own request — authorizing one round doesn’t lift the cap for the rest of the pull request.

When billing blocks a review

If your organization is out of credits, its trial has ended, or it has reached its spending limit, Indent doesn’t start the review and says which of those it was, with a Manage billing link. Raise the limit or add credits and ask for the review again.

Autofix

For an issue that Indent has a concrete fix for, you can apply the fix from the web app. Indent turns the fix into a commit made by the review session, then pushes it to the branch.

Fix failing checks

Indent watches the pull request as new commits and check results arrive. When a check fails, ask Indent in a comment to fix it, or tell it to get every check green.

Review rules

Encode your team’s standards as review rules so Indent checks for them on every review. Rules are committed to the repository as .mdc files under .indent/rules/, versioned alongside your code.

Each rule is a Markdown file with YAML frontmatter:

• description — what the rule checks for.
• globs — glob patterns that scope the rule to specific files. Leave empty to apply to all files.
• when_to_use — additional context about when the rule applies.
• alwaysApply — apply the rule to every review regardless of the globs.

For example, .indent/rules/security.mdc:

---
description: Security review guidelines
globs: "**/auth/**, **/tokens/**, **/secrets/**"
when_to_use: When reviewing security-sensitive code
alwaysApply: false
---

# Security Guidelines

- Never log secrets, tokens, or API keys
- Validate all user input before processing
- Use parameterized queries for database operations
- Check authorization before performing sensitive operations

You can also give Indent repository guidance in AGENTS.md and Skills.