Skip to main content
Sigilix subscribes to one stream of events from your forge: a GitHub or Linear webhook fires, and a single endpoint receives it. What happens next is not one fixed behavior. The dispatcher reads the event, decides what kind of work it represents, and routes it to the pipeline built for that work. The motivation is simple: not every event deserves the full ensemble. Posting a fast description of what a PR changes is a different job than running four domain specialists plus a synthesizer over the diff. If both went through the same heavy path, the cheap passes would wait behind the expensive ones. The dispatcher keeps them separate.

​
One event in, the right pipeline out

​
The pipelines

PR overview

A fast pass that describes what the pull request changes. Cheap to run and useful immediately — it does not wait behind the full ensemble.

Ensemble review

The full five-specialist pass: four domain specialists (Metis, Argus, Iris, Eunomia) unified by Harmonia, the synthesizer. This is the deep review.

CI-failure triage

When a check fails, Sigilix reads the failure and posts a grounded, inline root-cause analysis instead of leaving you to scroll the raw log.

Issue triage

Linear and Jira issues get rewritten titles, priority, estimate, labels, and assignee, plus a grounded root-cause comment and a link to the relevant PR.

describe / improve

Slash commands route to targeted pipelines: /sigilix describe summarizes a change, /sigilix improve proposes refinements. See Commands.

@mention Q&A

Mention @sigilix with a question and the dispatcher routes it to a grounded Q&A pipeline that answers against the repo and review history.

​
Why route at all

The point of the dispatcher is cost and latency isolation. The expensive work — the five-specialist ensemble running models tuned per role — is reserved for the events that need depth. Everything else takes a path sized to its job.
A single endpoint that always ran the full ensemble would be slow and wasteful. A PR that only needs a one-paragraph overview would pay the price of a deep security, logic, performance, and test review. A CI failure would be analyzed by four domain specialists when it only needs a grounded read of the failure log. By classifying the event first, the dispatcher matches effort to need:
1

Receive

A webhook arrives from GitHub or Linear — a PR opened, a check failed, a comment posted, an issue created.
2

Classify

The dispatcher inspects the event and the comment body (for slash commands and mentions) to decide which pipeline it belongs to.
3

Route

The event is handed to its pipeline. Fast pipelines return quickly; the ensemble runs its full pass independently.
4

Respond

Each pipeline writes back to the place the developer already is — the PR thread, the check, or the issue.

Review Lifecycle

What happens inside the ensemble pipeline once the dispatcher hands it a PR.

The Believability Pipeline

The five gates a finding must clear before it can post.