Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.sigilix.ai/llms.txt

Use this file to discover all available pages before exploring further.

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 — Core 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 →
Function name handleStuff does not describe its side effects (sends email + writes audit). Recommend dispatchAuditEmail.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 synthesizer summary

The first paragraph is from Core (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 Core says “0 findings,” skim and move on. If Core 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 — Glyph, Warden, Spark, Weave (Core never posts inline findings — it only synthesizes)
  • Category — the area within that specialist’s domain (e.g., Warden · Security)
  • Severity — Critical / Warning / Info
  • 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 Core 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 Core has high confidence the finding is 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 all 5 agents on the new diff
  • 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. 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
Mention replies are not full reviews — they’re conversational. They don’t change the verdict.

​
What’s next

The Ensemble

The architectural argument behind multi-specialist review.

sigilix.yaml

Tune severity thresholds, disable specialists, configure ignore patterns.