Overview
Sigma user documentation
Sigma reviews pull requests on GitHub. The pull request is where you read and discuss its findings; the Sigma workspace holds repository settings and the run history. One GitHub App, Sigma Mnemoverse, posts the reviews.
Closed beta and feedback
Sigma is in closed beta. We are working with a small group of invited GitHub accounts to improve review quality and reliability on real projects. Requesting beta access does not grant access automatically.
Thank you for trying Sigma. Positive and negative feedback are both welcome: tell us what you were doing, what you expected, what happened, and whether a review was useful.
To send feedback or get help, reply to your invitation email or write to
[email protected], and mention Sigma. If a review is involved, include the
pull request link and the check title. The
Mnemoverse contact page lists the same
address.
Getting started with an invitation
- Open the invitation link and sign in with the GitHub account it names. The link is personal and expires. Accept it in a browser with JavaScript enabled.
- On Connection, install the Sigma Mnemoverse App on an account the invitation allows, then tick the repository and save. Invited accounts start with On request: nothing runs until someone asks. Without admin rights on a project, use your own fork (see Beta access and removing Sigma).
- Open a pull request in that repository and comment
/sigma review. The caller needs write access (Who may call Sigma). - A neutral check named after the reviewer, for example "Sigma Charlie v7", moves from Review queued to Review published, and the review appears on the pull request (Check titles). When the shared beta limit or a provider window is reached, the check says so and the review waits (Limits and budget).
- Read verified findings first; unverified suspicions are leads, not findings (Reading a review).
Invited accounts run on Sigma's own model access (the gateway executor),
where the review container has no network. It reads your code and the change;
it cannot download dependencies, and tests that need the network do not run.
Each review records which checks ran and what could not be read or executed
(Reading a review).
Current availability
The steps above describe the invited gateway beta. A complete first external-user setup has not yet passed acceptance.
Running reviews on your own computer with your own provider sign-in is an intended option. Personal runner self-service is not yet available on this hosted beta, as checked on 8 October 2026. Installation, sign-in, account switching and retry are still awaiting an accepted setup and recovery flow. Descriptions of personal results in these pages do not establish that the option is available to your account.
If setup does not finish
Wide tables: scroll horizontally to see more columns.
| What you see | What to do |
|---|---|
| Invitation already accepted | Open the invitation page and select Sign in with GitHub under Already joined Sigma? |
| Invitation expired, revoked or invalid | Ask the Sigma maintainer for a replacement invitation. |
| Invitation for a different GitHub account | Use the account named in the invitation, then reopen the original invitation link. Check the Signed in as badge on Connection before saving. |
| Repository missing or not permitted | Check the App's selected repositories with Manage on GitHub, and that its account is allowed by your invitation. If it is still excluded, ask the Sigma maintainer. |
| Repository connected by another account | Ask that account or the Sigma maintainer to resolve the connection; another sign-in does not take it over. |
| No check after a review request | Confirm the repository is enabled, a reviewer is Automatic or On request, and the caller has write access. Check for an existing queued run before sending a new request; see Who may call Sigma. |
Keep the invitation link private. When asking for help, describe the step and displayed reason; do not include invitation codes or provider credentials.
What Sigma is
- It reviews a snapshot of the pull request's exact head and base commits.
- A producer proposes findings; a fresh verifier checks them. Only confirmed findings count as verified.
- A reviewer is a lineage (Bravo or Charlie) at a version on an executor. Each configured reviewer has its own mode, findings and history, and several reviewers can review the same pull-request state.
- Each reviewer posts one neutral progress check and one review with up to five inline findings. Rules can add a separate Approve or Request changes when its requirements pass.
- For hosted reviews, after a push, an Automatic reviewer reviews the new head and then follows up on its own earlier findings.
What Sigma is not
- Sigma never merges pull requests or edits your code. Its permissions allow reviews and checks, not commits.
- A neutral progress check is not an approval. Branch protection stays with the repository's administrators; Sigma configures no merge gate.
- A configured reviewer is not proof that its login works, that the login belongs to the person reading the page, or that a usage estimate is a bill. Execution and costs are kept separate.
- Sign-in is by invitation. An invited GitHub account also needs an approved App installation and current GitHub permissions to connect repositories. Signing in to Mnemoverse, granting GitHub access and authorizing a model provider are separate connections.
Who this documentation is for
The main text is written for a developer who reads a review and replies on GitHub. Three other readers get short callouts where their situation differs:
For coding agents. An agent acting on a review in an automated loop: what to parse, what counts as a finding, what a selector may and may not do.
For maintainers. The person who connects repositories, chooses modes, replies in finding threads and watches the budget.
For operators. The person running an instance: executors and logins, caps, waiting windows, rebinding. Procedures live in the operator runbooks under
docs/runbooks/; this documentation only says what they affect.
How to read this documentation
The current behaviour descriptions were checked against Sigma's deployed code on 8 October 2026. Another installation may run older reviewers, other executors, or Comments without Rules. Read the identity and recorded status on the actual run. Not yet available marks behaviour that is planned or designed but not shipped. Historical reviews and checks keep the wording and version they were published with.
Pages
- What Sigma does with your code: what is fetched, what cannot be reviewed, where it runs, what leaves the host, what is kept, the secret guard.
- Reviewers and executors: lineages and versions, the two stages, three execution paths, costs, provider constraints, waiting, choosing one reviewer.
- Modes and requests: Automatic, On request, Off; connecting a repository; explicit requests; permissions; drafts; pushes; catch-up after downtime.
- Reading a review: check titles, notices, the review's layout, severity, verification, the aggregate verdict, what agents can parse and the run page.
- Replies and rechecks: deferral, targeted rechecks, what a push does to open findings.
- Limits and budget: holds, waiting, what the maintainer can do, quotas.
- Glossary: the terms used throughout Sigma.