How Maige Works With Your GitHub Repository

Maige connects to a GitHub repository and runs natural-language rules against issues and pull requests: you describe the behavior you want, and it acts through the GitHub API. Connecting a repo creates three things — a webhook, embeddings of your entire codebase, and a sandbox environment — and you then write rules such as "label .env PRs as 'needs-approval' unless opened by @maintainer." One important condition up front: Maige has been sunset and remains open-source on GitHub as a public archive, and new signups are closed. The workflow below describes how the product was designed to operate, which is useful if you are evaluating the archived project or reading its code.

What connecting a repository actually sets up

The connection step is not just an OAuth handshake. According to the project, connecting creates:

• A webhook — so GitHub events (issues opened, PRs opened) reach Maige.
• Embeddings of your entire codebase — a searchable representation the AI uses as context when it acts.
• A sandbox environment — a place where Maige can run simple code snippets.

That combination explains the scope of what it can do: the webhook supplies the trigger, the embeddings supply codebase awareness, and the sandbox supplies a place to execute.

Writing rules in natural language

Rules are plain text descriptions of what should happen when issues and PRs are opened. The project's own examples show the pattern:

+ maige always assign UI-related issues to @username
+ maige label .env PRs as 'needs-approval' unless opened by @maintainer
+ maige review all incoming PRs per our CONTRIBUTING.md

Each rule names a trigger condition (UI-related issues, .env PRs, incoming PRs) and an action (assign, label, review). Conditions can include exceptions, as in the unless opened by @maintainer clause. The rules are customizable with text, so the constraint is how precisely you can describe the condition — not a fixed menu of options.

What Maige can do once triggered

Maige works through the GitHub API and, per the project, "can do anything you could do in the UI." The documented capabilities are:

The practical takeaway: think of Maige as an actor with your GitHub permissions driven by written policy, rather than a fixed set of toggles.

Monitoring runs and giving feedback

Runs are visible in a dashboard, where you can monitor what Maige did and provide feedback. This matters for rule quality: a rule like "assign UI-related issues" depends on Maige correctly judging what counts as UI-related, and the dashboard is where you'd catch misclassifications and tighten the wording. The project also suggests telling your community how to use the workflows — the rules only help if contributors know, for example, that .env PRs get flagged automatically.

Cost and availability, as stated

The project listed a Standard Plan at $30.00 USD/month, with the first 30 issues free, and an Enterprise plan marked "coming soon" for large teams. It also stated that new signups are closed and existing users can still sign in. Because the service has been sunset, treat the pricing as historical rather than a current offer; the open-source archive on GitHub is the durable artifact.

Deciding whether this model fits your needs

• If you want a working hosted service today: Maige is not an option — signups are closed and the product is sunset.
• If you want to self-host or study the approach: the open-source archive is the starting point; the three-part setup (webhook, embeddings, sandbox) and the text-rule model are the design to evaluate.
• If you are comparing tools conceptually: the distinguishing feature is natural-language rules over a codebase-aware agent with GitHub write access, rather than a fixed automation builder. Weigh that against the review burden — broad rules like "review all incoming PRs" need a clear written standard to be useful.