Docs for merge-ready code.
Install Sigilix once, then use these docs to understand the review pipeline, triage surface, CLI, Slack assistant, configuration, and usage boundaries behind every grounded answer.
Sigilix is a hosted GitHub App for multi-agent AI code review — the mark of merge-ready code. Believability here is architectural, not a prompt: a finding cannot post unless it earns its way through a sequence of gates.
Every pull request is read in parallel by four domain specialists — Logic & Architecture, Security, Performance, and Tests — and then unified by the synthesizer, which cross-checks their findings, deduplicates noise, calibrates severity, and posts a single coherent review.
Before the LLM specialists fire, a deterministic layer scans the diff for secrets, dependency vulnerabilities, AST rule violations, and any regex rules you’ve defined in sigilix.json. Those findings are injected into the specialists as authoritative facts. And before any specialist judges a line, Sigilix expands context — pulling callers, dependencies, and symbols from the code graph, the repo index, and review memory — so the diff is judged against the whole repository, not a window.
The output looks like one comment from a senior engineer who’s read everything carefully.
Sigilix is live and self-serve. Start free, or start a 14-day Pro trial →. See pricing for Free, Pro, Teams, Max, and Ultra.
Install the GitHub App, point it at a repo, and get your first review in minutes.
The five gates a finding must clear before it can post — evidence, provenance, refute/execute, proof-tier receipts, memory.
How one webhook routes to many pipelines — overview, ensemble review, CI triage, issue triage, Q&A.
Teach Sigilix a rule in plain language and watch it apply — and attribute — that rule in later reviews.
The four specialists
Rather than lean on a single generalist model, Sigilix runs four domain specialists in parallel, each focused on what it does best, unified by a fifth role — the synthesizer.
Logic & Architecture
Correctness, control flow, edge cases, architectural fit.
Security
Injection, authz gaps, secret exposure, unsafe patterns. Security never silently skips.
Performance
Hot paths, allocations, N+1s, algorithmic regressions.
Tests
Coverage gaps, deleted assertions, weak or misleading test changes.
Each specialist runs a model tuned to its role — a reasoning-heavy model for logic, a faster high-volume model for security — behind a cross-provider fallback so one provider’s outage can’t silence a specialist. The synthesizer runs after the four, cross-checks their findings against each other, drops duplicates, calibrates severity, and writes the single review you actually read.
Why findings are believable
Every posted finding earns its place by clearing the five-stage believability pipeline:
Evidence
A finding must point at concrete evidence in the diff or surrounding code — not a vibe.
Provenance contracts
The finding must cite the exact code it’s about; claims that can’t be tied to real lines are rejected.
Refute / execute
Sigilix tries to refute the finding — and, where it can, checks the claim by execution — before letting it stand.
Proof-tier receipts
Every survivor carries a tier pill: VERIFIED (corroborated by a receipt from your own CI), REPRODUCED (demonstrated by execution in Sigilix’s sealed sandbox), GROUNDED (anchored to cited code and evidence), or MODEL (model judgment).
Memory
Past reviews, dismissals, and learned rules shape what posts next time — so the system gets quieter and sharper on your repo.
This replaces any single numeric confidence score: instead of “4 out of 5,” you see why a finding is trustworthy and what kind of evidence backs it.
One webhook, many pipelines
A single GitHub or Linear event doesn’t always deserve the full ensemble. The dispatcher routes each event to the pipeline it earns — a PR overview, a full ensemble review, CI-failure triage, issue triage, describe/improve, or an @sigilix Q&A. Cheap passes like the overview don’t wait behind the heavy ensemble, so fast feedback stays fast. See The Dispatcher.
The earned context layer
Every review deposits a reusable, verified understanding of your repo — the index, the code graph, the trust ledger, review memory, and evidence manifests. That earned context is what the Sigilix CLI and Deep-Research Chat and Triage all draw on, so each review makes the next one cheaper and more grounded.
Conversational Learnings
Disagree with a finding? Reply in plain language — @sigilix remember we use integer cents here — and Sigilix records the rule, applies it judiciously in later reviews, and attributes it inline (“applied because of a learned rule”). A “Learned something new” footer confirms capture; @sigilix forget … walks it back. See Conversational Learnings.
What Sigilix is not
- Not a code generator. Sigilix surfaces findings with line references and suggested patches. Your team decides what to merge.
- Not training on your code. Code is sent to model providers under their data-use commitments and discarded after the review. We don’t fine-tune on customer repositories.
What you’ll see on every PR
When Sigilix reviews a PR, you get one review from sigilix[bot] containing:
- A synthesizer summary — what changed, what concerns survived dedup, and whether the verdict is Approved or Request changes.
- Inline findings anchored to specific lines, tagged by specialist (logic, security, performance, tests) and severity (Critical / Warning / Info), each carrying its proof-tier pill.
- Suggested patches for findings where a clean fix is in scope.
The review goes where developers already are — in the PR thread. Beyond the PR, the same engine powers the Sigilix CLI and Deep-Research Chat, running on Sigilix’s own hosted models or — on paid tiers — your own provider key.
Where to start
If you’re evaluating Sigilix, skim the believability pipeline to understand the depth claim, then install on a single repo to see it review a real PR.
If you’re already installed and need to tune behavior, head to Configuration.