Docs menu
⌘K

Ship

Pull request reviews

Midas can review pull requests on GitHub. Connect a repository once, and every new pull request can be reviewed automatically by the same agent that writes code. The review runs on a checkout of the pull request, posts its findings on GitHub, and records the result in the dashboard.

Connect a repository

In the dashboard, open Settings, then GitHub, then the Reviews Configuration tab. Install the MIDAS GitHub App on the account or organization that owns the repository, then choose which repositories the app may review. The connection belongs to the workspace, so a shared organization keeps one setup for everyone.

Linking an installation proves that the person connecting it can administer it on GitHub. After that, reviews are billed to the workspace wallet and the history is visible to the workspace.

Start a review

  • Automatic. By default a review starts when a pull request is opened. You can also review new pushes or every event.
  • On demand. Open Reviews, then Pull requests, and choose Start review on a pull request that has not been reviewed.

A review is keyed to the repository, pull request, and head commit. A new push gets a new review. Starting the same commit twice does not bill twice, and a failed or skipped review can be retried. When a review is scheduled, MIDAS adds itself to the reviewer list on the pull request.

Reviews start from GitHub or the dashboard. A CLI command for the GitHub review system is not available yet. The local /review command reviews a diff inside a session, and is separate from the GitHub system.

What a review posts

  • Inline comments on the lines where a finding applies.
  • A summary on the pull request, or an updated PR description, depending on your settings.
  • A confidence score, the findings, a short PR summary, and an optional sequence diagram.
  • An optional GitHub check run, so a branch protection rule can require it.
  • An approval, if auto-approve is on and the review clears the confidence and risk settings.

Posting to GitHub is best effort. If GitHub rejects a comment or a check run, the review still completes and the error is recorded with the review, so a delivery problem does not lose the findings.

Review settings

One review policy applies to the workspace. Settings are stored per organization, so a personal workspace and an organization can differ.

  • Automatic reviewsNever, on PR opened, on new pushes, or on all events.
  • Review draftsInclude draft pull requests, or wait until they are ready.
  • FiltersInclude or exclude by author, repository, branch, label, title, or path.
  • StrictnessLow comments on everything, medium skips nitpicks, high raises only confident defects.
  • Custom rulesPlain-English standards scoped to file patterns and repositories.
  • Context filesFiles the reviewer reads first: a style guide, CONTRIBUTING.md, AGENTS.md.
  • Linked repositoriesRead related repositories as context, so an API change is checked against its client.
  • SummaryChoose the PR description, confidence score, findings, PR summary, and sequence diagram.
  • Status checkPost a GitHub check run, with a minimum confidence from 0 to 5.
  • Auto-approveApprove a PR that clears the confidence bar, up to a risk ceiling you set.

A filter is a rule with a field, an operator, and one or more values. A custom rule is a sentence such as Do not add a dependency without a note in the pull request, optionally scoped to paths and repositories. Context files are read before the diff, which is how the reviewer learns a convention that is not obvious from the code. Linked repositories let the reviewer read a client and a service together.

The dashboard

  • Analytics: review totals, findings over time, bugs caught, severity, contributors, and top repositories.
  • Pull requests: open and closed pull requests, search, filters, bulk selection, review status, and a Start review action.
  • One pull request: merge status, confidence, risk, findings, and the link back to GitHub.
  • Configuration: installations, repository access, triggers, filters, strictness, custom rules, context files, linked repositories, summaries, status checks, and auto-approve.

Review status moves through queued, running, completed, failed, and skipped. The dashboard shows which commit was reviewed and links to the posted review.

Billing

A review runs the same agent through the MIDAS gateway, and the spend is billed to the wallet of the workspace that owns the installation. Review cost appears with the rest of your usage. There is no separate per-review price.

Review locally

The terminal has its own review commands for work that has not reached GitHub:

/review                       # uncommitted changes
/review <commit>              # one commit
/review <branch>              # the branch against the current branch
/review <PR number or URL>    # a pull request, with gh

Add /standards-review for over-engineering, /ui-review for UI and UX issues, or the audit form of either for the whole repository.

Current limits

  • Reviews are triggered from GitHub or the dashboard, not from the CLI.
  • The dashboard does not merge pull requests. Review and merge on GitHub.
  • Midas does not track which findings were resolved after a review.

Next steps