Skip to main content
Every review Sigilix posts has the same shape. Once you know the shape, you can scan a review in 10 seconds.

​
The structure

Sigilix · 12 minutes agoRequest changes
Sigilix Summary — Harmonia synthesized 4 findings across 3 specialists. 1 requires action before merge.
Unsanitized userId from req.params passed directly into a SQL template in auth.ts:142. Use the parameterized query pattern established in authService.ts.View diff →
Nested loop in aggregateReports scales with repo count. Consider indexing createdAt or paginating upstream.View diff →
The new branch in chargeCustomer has no test covering the partial-refund path. Add a case before merge.View diff →

​
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 Harmonia summary

The first paragraph is from Harmonia (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 Harmonia says “0 findings,” skim and move on. If Harmonia 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 — Metis, Argus, Iris, Eunomia (Harmonia never posts inline findings — it only synthesizes)
  • Category — the area within that specialist’s domain (e.g., Argus · Security)
  • Severity — Critical / Warning / Info
  • Proof-tier pill — VERIFIED (checked by execution or a signed receipt), GROUNDED (anchored to cited code), or MODEL (model judgment). See the believability pipeline.
  • 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 Harmonia 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 Harmonia 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 Believability Pipeline

The five gates behind every finding — and the proof-tier pills they earn.

Conversational Learnings

Teach Sigilix a rule in plain language and have it applied — and attributed — in later reviews.

sigilix.json

Per-role rules, path filters, deterministic checks, and per-subsystem opt-outs.