Skip to main content

​
How It Answers

A generic chatbot answers from whatever it can fit in a context window, and fills the rest with plausible-sounding guesses. @Sigilix answers the way it reviews: it retrieves a verified understanding of your repo first, anchors every claim to real code, and refuses to assert what it can’t ground. This page walks the path a single @mention takes — from a Slack event to a cited answer, and optionally to an action. The throughline is the believability discipline from the believability pipeline: grounding before judgment. An answer must point at concrete evidence — a file and line, a merged PR, an ADR — or it doesn’t get made.

​
The flow

1

Slack event arrives

A team member @mentions @Sigilix in a thread. Slack delivers the event — the message text, the channel, the thread, and the workspace it came from.
2

Resolve workspace and permissions

@Sigilix resolves which workspace (which tenant) the event belongs to and which repositories that workspace’s GitHub App install can see. Everything downstream is scoped to that — no cross-tenant context, no repos outside the install’s grant. See Permissions & security.
3

Retrieve from earned context

@Sigilix pulls the relevant understanding from the earned-context layer: the repo index for the right files, the code graph for callers and dependencies, symbol-aware expansion to follow the symbols the question is actually about, and review memory for what past reviews and learnings already established.
4

Answer, grounded with citations

With real context in hand, @Sigilix composes an answer anchored to file:line, the PRs that set a pattern, and the ADRs behind a decision. Claims that can’t be tied to retrieved evidence don’t get made — the same provenance discipline a posted finding has to clear.
5

Optionally take an action

If the thread resolves into a decision, @Sigilix can act on it — open a PR, file a triaged issue, or run a review — reusing the same retrieved context so the artifact is grounded, not improvised. See Capabilities.

​
Why retrieval comes first

The same reason it does in reviews. A diff judged against a four-line window invents problems and misses real ones; a diff judged against the whole repository — callers, dependencies, conventions, history — gets judged like a senior engineer would judge it. A Slack question is the same shape: “why does this error get swallowed?” is unanswerable from the line alone, and trivially answerable once you can see the caller, the wrapper, and the PR that introduced the early return. So @Sigilix never answers from the message text alone. It retrieves first.

The repo, in context

The index and code graph mean answers reason about callers, dependencies, and symbols across the whole repository — the same context-before-judgment that powers reviews. Symbol-aware expansion follows the identifiers the question names instead of guessing at relevance from keywords.

The review history

Review memory makes past findings, their proof-tier receipts, and taught rules retrievable. @Sigilix can tell you not just what the code does, but what it has already learned and decided about it — including conventions captured via Conversational Learnings.

​
Grounding, not guessing

The believability discipline shows up in what @Sigilix won’t do. If retrieval comes up empty — the question is about code outside the install’s scope, or a subsystem with no earned context yet — it says so rather than fabricating a confident answer. A citation is a contract: the file and line it names exist, the PR it references is real, the ADR it points at is in the repo. This is the same provenance gate a posted review finding clears in the believability pipeline, applied to conversation. 
@sam   @Sigilix does the rate limiter use a sliding window or a token bucket?

@Sigilix  Token bucket. `RateLimiter` in `middleware/ratelimit.ts:22`
          refills `tokens` at `refillPerSec` and rejects when the bucket
          is empty (lines 40-58) — there's no windowed counter. It was
          switched from a fixed window to a token bucket in #471, and the
          choice is recorded in ADR-0009. The Redis-backed variant in
          `middleware/ratelimit-redis.ts` mirrors the same algorithm.
Every clause in that answer is anchored. That is the bar.

​
From answer to action

Because the action paths reuse the context retrieved for the answer, the hand-off from “explain” to “do” stays grounded. When you ask @Sigilix to open a PR, the patch and its regression test are built against the same files and conventions it just cited. When you ask it to file an issue, the triage (priority, owner, links) is drawn from the same graph and history. When you ask it to run a review, the ensemble fires with the same earned context it would use on an automatic review. The conversation and the work share one substrate.
Heavy work doesn’t block light work. Just as the dispatcher routes a cheap PR overview around the full ensemble, a quick @Sigilix answer doesn’t wait behind an on-demand review. Fast feedback stays fast.

Earned Context

The reusable, verified layer every review deposits — and what @Sigilix retrieves from.

The Believability Pipeline

The grounding-before-judgment discipline that makes the answers trustworthy.