Slack Assistant

The hosted GitHub App reviews every PR. But the questions that decide a change rarely start in the PR thread — they start in Slack. “Why does the checkout path swallow this error?” “What breaks if I rename chargeIntent?” “Did we ever decide on integer cents?” Those questions usually get answered from memory, or not at all.

The Slack assistant puts Sigilix where that conversation already happens. There is no separate product and no separate brain: the bot in your channels is @Sigilix, the same engine that runs the ensemble on your pull requests. When you @mention it, it answers from the same substrate it reviews against — and it answers the same way it reviews: grounding before judgment, citations before claims.

Grounded in earned context

The difference between @Sigilix in Slack and a generic chatbot bolted onto your repo is the substrate it reads from. A generic bot reads whatever fits in its window and fills the gaps with guesses. @Sigilix reads from the earned-context layer — the index, code graph, trust ledger, review memory, and evidence manifests that every hosted PR review deposits.

That means a Slack answer can cite the exact line a function fails on, the merged PR that established a pattern, and the ADR behind a decision — because that understanding was built and verified during real reviews, not improvised for the question. It is the same context-before-judgment discipline described in The Ensemble and enforced by the believability pipeline.

What it can do

A thread, end to end

A grounded answer often becomes a decision, and a decision often becomes work. @Sigilix is built to carry a thread across that whole arc without anyone leaving Slack:

@alex   @Sigilix why does the refund path skip the idempotency check?

@Sigilix  The refund handler short-circuits before the guard runs.
          In `payments/refunds.ts:142`, `processRefund()` returns early
          on `status === "pending"` — above the `assertIdempotent(key)`
          call at line 168 — so pending refunds never hit it.

          This was introduced in #604 ("fast-path pending refunds").
          The convention to guard every money-moving handler is set in
          ADR-0017 and enforced across `charges.ts` / `payouts.ts`.

@alex   that's a bug. @Sigilix open a PR to move the guard above the early return

@Sigilix  Opened #631 → `fix/refund-idempotency-order`. It moves
          `assertIdempotent(key)` above the pending short-circuit and adds
          a regression test mirroring `refunds.test.ts`. Ran the full
          ensemble: logic ✓  security ✓  performance ✓  tests ✓ — verdict: Approved.

The same grounding stack that lets it answer the first message is what lets it write a believable patch, a real regression test, and a review for the last one.

How it fits with the rest of Sigilix

Read next