Skip to main content

​
Capabilities

@Sigilix in Slack is not a chat veneer over a generic model. It is the review engine reachable from a thread, so everything it does is backed by the earned-context layer and disciplined by the believability pipeline: it cites real code, it doesn’t guess, and when it acts it produces artifacts a reviewer would accept. There are two broad modes. Answering — it reads the codebase and its review history to respond, grounded in citations. Acting — once a team aligns, it turns the conversation into a pull request, an issue, or a review. The same retrieval substrate sits under both.

​
Answering

Grounded codebase Q&A

Ask why something works the way it does, what a change affects, or how a subsystem fits together. Answers cite file:line, the merged PRs that set a pattern, and the ADRs behind a decision — pulled from the index, code graph, and review memory.

Stays in-thread until aligned

@Sigilix keeps explaining in the same thread — narrowing, pulling more context, weighing trade-offs — until the team has what it needs to decide. It treats a thread as a conversation, not a one-shot query.

​
Answer codebase questions, with citations

The core capability. @mention a question and @Sigilix retrieves from earned context, then answers anchored to concrete evidence — never a vibe. A typical answer names the file and line, the PR that introduced the behavior, and the convention or ADR that governs it. 
@dana   @Sigilix what enforces that every webhook handler verifies the signature?

@Sigilix  Two layers. `verifyWebhookSignature()` in
          `webhooks/verify.ts:31` is called by the shared
          `withWebhook()` wrapper (`webhooks/wrap.ts:18`), and every
          handler is registered through that wrapper — see
          `webhooks/index.ts:44-71`. The "all handlers go through
          withWebhook" rule was set in #512 and is the subject of
          ADR-0011. One handler, `legacyStripeRetry`, bypasses it
          (`webhooks/legacy.ts:9`) and is flagged as deprecated.
Because the answer is grounded, it carries the same trust character as a posted review finding: it points at code that exists.

​
Acting

When the conversation resolves into a decision, @Sigilix can carry it the rest of the way. Each action is produced with the same grounding and believability discipline as a review.

Open a PR from the thread

Once a team aligns on a change, @Sigilix opens a pull request — the change plus a regression test mirroring the existing suite — so the fix arrives review-ready, not as a sketch.

File a triaged issue

Turn a thread into a Linear or Jira ticket with a rewritten title, a priority/severity assessment, a likely owner, and links back to the relevant files and PRs.

Explain a failing CI run

@Sigilix reads the job logs against the diff and replies with a grounded root cause in file:line terms — not a paraphrase of the stack trace.

Summarize a PR or review

Get an effort estimate, which gates passed, the risk-ranked files, and the verdict — a concise read of where a PR stands.

Run a review on demand

Trigger the full Metis / Argus / Iris / Eunomia + Harmonia ensemble on a PR or branch. The verdict posts to GitHub; a summary posts to the channel.

Remember team conventions

Conventions, ADRs, and past verdicts are retained and applied — so the next answer reflects what the team has already decided.

​
Open a PR from the thread

When a thread lands on “this should change,” @Sigilix can author the change itself. It produces a branch, the edit, and a regression test that mirrors the existing suite — matching the repo’s test conventions rather than inventing its own — so the PR is something a human reviewer can evaluate immediately. It is not a code generator firing blind: the patch is grounded in the same context the answer was, and the change is scoped to the decision the team reached.

​
File a triaged issue

A raw “this is broken” message becomes a structured ticket. @Sigilix rewrites the title to be searchable, assigns a priority/severity from what it found, names a likely owner from code ownership and history, and links the relevant files and PRs so whoever picks it up starts with context. This is the same issue-triage pipeline the dispatcher routes GitHub and Linear events to, reachable from Slack.

​
Explain a failing CI run

Point @Sigilix at a failing run and it reads the job logs against the diff — not in isolation. The reply is a grounded root cause in file:line terms: which change broke which assertion, and why. Because it correlates the log with the actual code under change, the explanation lands on a cause, not a symptom.

​
Summarize a PR or review

A fast read on where a PR stands: an effort estimate, which believability gates the findings passed, the files ranked by risk, and the synthesized verdict from Harmonia. Useful before a standup, a merge decision, or handing a PR off.

​
Run the full ensemble on demand

@Sigilix review <PR or branch> runs the complete ensemble — Metis (logic & architecture), Argus (security), Iris (performance), and Eunomia (tests) in parallel, unified by Harmonia. The verdict and inline findings post to GitHub exactly as an automatic review would; a summary posts back to the Slack channel so the thread stays informed. See Commands for the full verb list.

​
Scoped and isolated by design

@Sigilix only sees what your GitHub App install scopes allow, and each Slack workspace is isolated as its own tenant — there is no cross-tenant context. A question in one workspace can never retrieve another workspace’s code or history. See Permissions & security.

How it answers

The retrieval and grounding flow behind every answer and action.

Commands

The exact verbs to @mention and what each one returns.