An AI reviewer for every GitHub pull request
Build an AI pull request reviewer, issue triage, dependency bump PRs and check runs on GitHub, tested on your real repo. One click via the GitHub App.
- Category
- Developer tools
- Connect
- Connect with one click (OAuth) · managing connections
- Operations
- 31
- Triggers
- 8
GitHub is the deepest integration in MadMax, because MadMax's own review bot is built on it. An AI reviewer that reads the diff with the repository indexed as context, leaves inline comments as the MadMax bot, opens a check run and completes it with a verdict: that is a workflow on the canvas, and you can build your own variant. Runs go both ways. Events from your repositories arrive through the MadMax GitHub App with no URL or secret to manage, each one carries a sample payload so the AI knows the field paths before the first delivery, and the bot's own comments never start a run. The workflow writes reviews, comments, commits and merges back, or pauses for a one-click approval first; a merge respects branch protections and required checks, never bypasses them. Describe it in plain English and MadMax plans the steps, wires the GitHub operations, and runs the whole thing against a real pull request before you activate it.
What teams build
- The pull request event fires on open and synchronize, the run reacts with eyes, opens a check run, reads
get_pr_diffandlist_pr_files, and an AI agent with the repository in a knowledge base posts a review with inline comments as the bot, then completes the check with pass or fail. - A watch trigger polls a dependency's
list_tagsand fires per new release, the run creates a branch, writes the updated lockfile withput_fileand opens a PR, and an approval posts to Slack with one-click buttons beforemerge_prruns and the branch is deleted. - The issues event fires on open, an AI classify step sorts it into bug, question or feature, questions get an answer grounded in your docs knowledge base posted with
comment_as_bot, and bugs email the maintainers with the issue link.
How it connects
One click. Press Connect on the GitHub card in Settings → connectors, approve the MadMax GitHub App on the repositories you choose, and the connection is ready. The app's user tokens expire after eight hours and MadMax refreshes them automatically; a revoked grant reconnects in place with nothing to rewire. Connections are per workspace, private to you or shared with the team, and each GitHub step picks the one it uses. See managing connections.
Related
Every GitHub operation MadMax can run
Straight from the integration's manifest, so this list is what the steps on the canvas can actually do today.
| Operation | What it does |
|---|---|
| comment as bot | Add a conversation comment AS THE MADMAX BOT (comment_issue posts as the connected user). |
| comment issue | Add a comment to an issue or pull request. |
| create branch | Create a branch at `sha` (get it from `get_branch_head`). `branch` is the bare name; the refs/heads/ prefix is added. |
| create check run | Open a check run AS THE MADMAX BOT on a commit. It shows in the PR's checks list as in progress until `update_check_run` completes it. |
| create issue | Open a new issue. |
| create pr | Open a pull request. |
| create pr review | Post a review AS THE MADMAX BOT: a summary body plus inline comments anchored to diff lines. `comments` is a JSON array of {path, line, body} (line = the NEW-side line number; add side: "LEFT" for a deleted line). `event` COMMENT leaves the PR state alone; APPROVE / REQUEST_CHANGES change it. |
| delete branch | Delete a branch (cleanup after a merged PR). 204 on success. |
| delete issue comment | Delete one of the bot's PR / issue comments. 204 on success. |
| delete review comment | Delete one of the bot's inline review comments. 204 on success. |
| get branch head | The commit sha at the tip of a branch: what you branch FROM. |
| get file | Read a file. `text` is the DECODED file content, so use it directly, no base64 handling needed. `sha` is the blob sha `put_file` needs when updating this file. |
| get pr | One pull request: title, body, state, head/base, author, changed-file counts. |
| get pr diff | The pull request as a unified diff (text). Large PRs are truncated by GitHub past ~20k lines, so page by file with list_pr_files for those. |
| get tree | Every path in the repository at a branch/tag/commit, in one call (recursive). `tree` is the list: filter `type == "blob"` for files, then read each with get_file. `truncated` is true past GitHub's ~100k-entry limit. |
| graphql | Run a GraphQL QUERY against GitHub's v4 API, one request for what would be many REST calls. The batch file read: alias one `object(expression: "<ref>:<path>") { ... on Blob { text isBinary byteSize } }` per path under `repository(owner:, name:)`, ~50 per query (about one rate-limit point). `result` is the response's data object: in a step, `payload.result.repository` (alias → blob; `text` is null for binaries). `errors` is the GraphQL errors list (null when clean). Queries only: use the REST operations to change things. |
| list issues | List issues in a repository. Returns the matching page. |
| list pr comments | Conversation comments on a pull request (or issue), oldest first: author, body, id. |
| list pr files | Files changed in a pull request, each with its own patch (unified diff hunk) and status. |
| list pr reviews | List the reviews on a pull request (root array under `raw`). Used by the review bot to find its own earlier reviews before posting a fresh one. |
| list review comments | Inline review comments on a pull request's diff: path, line, body, author, thread (in_reply_to_id). |
| list tags | List a repository's tags. ORDER IS NOT GUARANTEED newest-first (GitHub returns ref order), so never treat item [0] as "latest". As a `watch` poll target with dedup on `name` this is fine: dedup is order-agnostic and fires once per unseen tag. Any step that needs "the newest" must compare versions itself. |
| merge pr | Merge a pull request. Fails cleanly (405) when the PR isn't mergeable: branch protections and required checks are respected, never bypassed. |
| put file | Create or update a file with a commit on `branch`. `content` is PLAIN TEXT; the platform base64-encodes it for GitHub's API; never pre-encode. Updating an EXISTING file requires `sha` (from `get_file`); omit it when creating a new file. |
| react to comment | Add an emoji reaction AS THE MADMAX BOT to a PR / issue comment: the review bot's 👀 on pickup and 👍 on finish. `content` is one of +1, -1, laugh, confused, heart, hooray, rocket, eyes. |
| react to review comment | Add an emoji reaction AS THE MADMAX BOT to an inline review comment (a thread reply). Same `content` values as react_to_comment. |
| reply review comment | Reply AS THE MADMAX BOT in an inline review thread. |
| update check run | Complete a check run with a conclusion (success | neutral | failure | action_required) and an output summary; `details_url` links the check to the review. |
| update issue | Update an issue or PR: close/reopen, retitle, or replace the body. |
| update pr | Update a pull request's description (and/or title) AS THE MADMAX BOT. Used to merge a review summary into the PR body. |
| update pr review | Rewrite the body of one of the bot's earlier reviews (GitHub never deletes a submitted review). The review bot collapses superseded reviews to a one-line note. |
GitHub events that can start a workflow
Fires when a comment is created, edited, or deleted on an issue or pull request.
Fires on issue activity; `action` distinguishes opened, closed, labeled, assigned, etc.
Fires on pull request activity; `action` distinguishes opened, closed, reopened, synchronize, etc.
Fires when a review is submitted, edited, or dismissed; `review.state` is approved, changes_requested, or commented.
Fires when commits are pushed to a branch or tag.
Fires on release activity; `action` distinguishes published, created, edited, prereleased, etc.
Fires when a repository is starred or unstarred.
Fires when a GitHub Actions workflow run is requested, in progress, or completed. Check `workflow_run.conclusion` for success/failure on `action: completed`.
Works with
Describe the workflow. MadMax builds it and tests it on your data.
Free to start, no card. Connect your apps, say what should happen in plain English, and watch each step run against real data before anything goes live.