Tutorial

Connect your repositories

On Repositories, connect a GitHub account and pick which repositories the App may read. Sync pulls that selection in again after you change it on GitHub.

Each repository then has two independent switches:

• Enabled: the reviewer may read this repository at all. Nothing works until this is on.
• Automatic reviews: off by default. With it on, every pull request opened or reopened on that repository is reviewed without anyone asking.

The two checkboxes at the top apply the same change to every repository at once. This page is admin-only.

Ask for a review on a pull request

Comment @contextgoblin on any pull request in an enabled repository and it reviews that pull request. This works whether or not automatic reviews are on for the repository.

You get a short acknowledgement straight away, before the review starts. Only the repository's owners, members and collaborators can trigger a review this way.

What lands on the pull request

Automatic reviews and @contextgoblin mentions both post their result into the pull request itself: a Review Overview with a verdict and a summary, plus inline comments on the exact changed lines. Every finding carries a severity and its category: Architecture, Security, Logic or Tests.

The verdict is a real GitHub review state, not just text: Approve approves the pull request, Approve with comments leaves a non-blocking comment review, and Request changes requests changes. If you want that to actually block a merge, set up branch protection on the repository.

Start a review from the dashboard

On Review, paste the URL of a pull request in a connected repository and press Start review. The result appears in the dashboard; it is not posted to GitHub.

Progress runs live while it works: it prepares a workspace, builds the context, plans the review, runs the four specialists (one each for architecture, security, logic and tests), then collects everything into one report.

Runs

Runs is every review your organisation has done, newest first, however it was triggered. Expand a row to read that review's findings again.

Build the cross-repo map

On Repositories, the Cross-repo relations card has a Find relations button. It crawls your enabled repositories and detects how they depend on each other: package dependencies, HTTP calls, queues, shared tables. It runs in the background, so you can keep starting reviews while it works.

The result is the map on Knowledge, where nodes are repositories and edges are the relations found between them. From then on, the parts of that map touching a change are fed into reviews as extra context. Re-run it after a bigger refactor to keep it current.

Connect your own MCP servers

The best reviewers know things that aren't in the code. On MCP Servers you can connect Jira, Confluence, Notion, your own documentation, or anything else that speaks MCP. Give it a name, a URL and, if it needs one, a bearer token or HTTP headers.

Once connected, press Tools to choose which of that server's tools the review agents may call. They then read that context during a review, so the question stops being "is this code correct" and becomes "does this change do what the ticket asked for".

Tokens and header values go into your organisation's secret store and are never shown again.

Insights

Insights aggregates every review your organisation has run: how many there were, how many completed or failed, and the average turnaround.

Below that: findings split by category, review activity over the last two weeks, and which repositories are reviewed most. The repository dropdown narrows every figure on the page to one repository.

Invite your team

On Members, create an invitation for an email address. That produces a single-use link, valid for seven days.

Roles are owner, admin and member. Any member can start reviews and look at Runs, Knowledge and Insights; Repositories, MCP Servers and Settings are admin-only. Each organisation has exactly one owner, and only the owner can transfer that.

Settings, credits and API keys

Review effort is how much reasoning each review agent spends. It is one organisation-wide default, not a per-review control.

Review Credits is a USD balance that every review draws down at cost. A review in flight reserves what it might spend until it finishes. Credits are granted by us, so contact us if you need more.

MCP API keys let your own tools call the review server as your organisation, so you can start reviews from an editor or a CI pipeline. Press Show configuration for the snippet an MCP client needs.

Tell us what's wrong

The green bubble in the bottom right of every dashboard page sends us feedback directly. A bad finding, a missing one, anything that felt off. It helps.