Anatomy of a Review
Every review Sigilix posts has the same shape. Once you know the shape, you can scan a review in 10 seconds.
The structure
Sigilix Summary — the synthesizer unified 4 findings across 3 specialists. 1 requires action before merge.
Security · Critical · VERIFIED
Unsanitized userId from req.params passed directly into a SQL template in auth.ts:142. Use the parameterized query pattern established in authService.ts.
Performance · Warning · GROUNDED
Nested loop in aggregateReports scales with repo count. Consider indexing createdAt or paginating upstream.
Tests · Info · GROUNDED
The new branch in chargeCustomer has no test covering the partial-refund path. Add a case before merge.
The verdict badge
Top-right of every review:
- Approved — no blocking findings; clean to merge once human review is done
- Request changes — at least one Critical or Warning finding the synthesizer judged blocking
The verdict updates on every push (pull_request.synchronize). If you fix the blocking findings and push, the next Sigilix review will flip to Approved.
The synthesizer summary
The first paragraph is from the synthesizer. It tells you:
- How many findings survived deduplication
- How many specialists contributed
- How many require action before merge
This is the only block worth reading if you’re triaging fast. If the synthesizer says “0 findings,” skim and move on. If the synthesizer says “1 critical,” that’s your thing.
The inline findings
Each finding is collapsed by default and lives on a specific line in the diff. Click to expand and read:
- Specialist tag — logic, security, performance, tests (the synthesizer never posts inline findings — it only synthesizes)
- Category — the area within that specialist’s domain (e.g., Security)
- Severity — Critical / Warning / Info
- Proof-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), or MODEL (model judgment). See Verification & the Trust Ledger.
- Body — what’s wrong, why, and the minimal fix
- View diff link — jumps to the exact line on GitHub
Severity calibration
Sigilix uses three severity levels. Calibration is done by the synthesizer during synthesis:
- Critical — broken correctness, security exposure, or data integrity risk. Should block the merge.
- Warning — important but not catastrophic. Logic bug in a cold path, missing error handling on a non-fatal boundary, performance regression.
- Info — nit-level. Naming, dead code, doc gaps. Surfaced for awareness but never blocks.
A finding’s severity can shift up or down during synthesis if multiple specialists flag the same code (escalation) or if the synthesizer judges the finding a false positive (suppression).
Re-reviews on push
When you push to a PR branch, Sigilix re-reviews on the new SHA. The new review:
- Replaces the old review summary (one summary per SHA)
- Re-runs the deterministic-checks layer and the four domain specialists incrementally on the changed lines, carrying forward findings on unchanged lines
- May change the verdict if findings were resolved
Old reviews on prior SHAs stay visible in the PR’s review history — Sigilix doesn’t delete them.
Mentions
You can @sigilix Sigilix on any PR comment thread or inline review-comment thread. Sigilix replies as a regular GitHub comment, grounded in the repo and review history. Use mentions to:
- Ask Sigilix to re-explain a finding
- Push back on a finding (“this is intentional because…”)
- Ask about adjacent code that wasn’t in the diff
- Teach a rule —
@sigilix remember we use integer cents here— which Sigilix records and applies, with inline attribution, in later reviews (@sigilix forget …walks it back). See Conversational Learnings.
Mention replies are not full reviews — they’re conversational. They don’t change the verdict.
What’s next
The five gates behind every finding — and the proof-tier pills they earn.
Teach Sigilix a rule in plain language and have it applied — and attributed — in later reviews.
Per-role rules, path filters, deterministic checks, and per-subsystem opt-outs.