Skip to main content

​
Sigilix CLI

The hosted GitHub App reviews every PR. The Sigilix CLI brings that same review to where the change is born: your working tree. Run it against a dirty branch, a stash, or a diff range and you get the same five-specialist ensemble — Metis (logic & architecture), Argus (security), Iris (performance), and Eunomia (tests), unified by Harmonia (the synthesizer) — behind the same believability gates that decide what posts on a PR. The point is not “AI in the terminal.” The point is parity without rebuild. The CLI does not re-derive your repository from scratch each run. It reaches for the earned-context layer — the index, code graph, trust ledger, review memory, and evidence manifests that hosted reviews deposit — so a local review is judged against the whole repository, not the window of lines you happen to have changed.
The Sigilix CLI is part of the private beta. Availability is per-account during the beta — join the private beta to get access, and contact support@sigilix.ai if you are already in and want it enabled for your account.

​
Why review locally

A PR review is a great backstop, but it fires after you have pushed, opened a PR, and asked teammates for their attention. By then the cost of a finding is higher — context-switching, force-pushes, re-review churn. The CLI moves the same depth one step earlier:

Same ensemble

Metis, Argus, Iris, and Eunomia run in parallel and are unified by Harmonia — identical roles to the hosted review, not a stripped-down lint pass.

Same gates

Findings clear the same believability pipeline before they surface, so the terminal is as quiet and as trustworthy as the PR thread.

Same context

The CLI fetches the earned-context layer instead of rebuilding it, so a local review reasons about callers and dependencies across the repo.

Before the PR

Catch the Critical finding while the fix is still a one-line edit in your editor — not a force-push after CI.

​
How it works

The CLI is a thin client over the same engine the hosted App runs. It does three things: it figures out what changed, it fetches the verified understanding of your repo, and it runs the ensemble behind the gates.
1

Resolve the diff

The CLI computes the change set the same way the hosted review does — a diff against a base (your merge-base with the default branch by default), or an explicit range you pass. Path filters and the profile from your sigilix.json are honored, so the CLI reviews exactly what a PR would.
2

Run deterministic checks first

Before any model fires, the deterministic layer scans the diff for secrets, dependency vulnerabilities, AST rule violations, and any regex rules you’ve defined. Those findings are injected into the specialists as authoritative facts — exactly as on a PR. See Deterministic Checks.
3

Fetch earned context

Instead of re-indexing your repo on every invocation, the CLI reaches for the earned-context layer the hosted reviews already built — the index, code graph, trust ledger, review memory, and evidence manifests. The diff is expanded with callers, dependencies, and symbols before any line is judged.
4

Run the ensemble

Metis, Argus, Iris, and Eunomia review the expanded diff in parallel. Each emits candidate findings anchored to specific lines.
5

Pass the believability gates

Every candidate must clear the five-stage believability pipeline — evidence, provenance, refute/execute, proof-tier receipts, memory — before it is allowed to surface.
6

Synthesize and print

Harmonia cross-checks the survivors, drops duplicates, calibrates severity, and prints one coherent review: a summary plus inline findings tagged by specialist and severity, each carrying its proof-tier pill.

​
What a review looks like

A local review reads like the PR review you already know — one summary from Harmonia, then findings anchored to files and lines, each tagged by specialist (Metis / Argus / Iris / Eunomia), by severity (Critical / Warning / Info), and by proof tier (VERIFIED / GROUNDED / MODEL). 
# Review the working tree against the default-branch merge-base
sigilix review

# Reviewing 7 changed files (against origin/main)…
#   deterministic checks ……… 1 dependency advisory injected
#   earned context …………………… index + code graph + review memory loaded
#   ensemble ……………………………… Metis · Argus · Iris · Eunomia
#   synthesis ……………………………… Harmonia
#
# ── src/auth/session.ts ─────────────────────────────────────
#   ✗ Critical · Argus · GROUNDED   L42
#     Session token compared with == instead of a constant-time
#     compare; vulnerable to timing analysis.
#
#   ⚠ Warning · Metis · GROUNDED    L88
#     Early return skips the audit-log write on the error path.
#
# ── src/db/orders.ts ────────────────────────────────────────
#   ⚠ Warning · Iris · MODEL        L17
#     Query inside the loop — likely N+1 over `order.items`.
#
# Verdict: Request changes · 1 Critical · 2 Warnings
The output above is illustrative — exact wording, glyphs, and counts depend on your repo and the change. The shape is real: a Harmonia summary, inline findings tagged by specialist and severity, and a proof-tier pill on every finding.

​
Common workflows

The default loop: make your change, run sigilix review, fix what surfaces, then push. Because the CLI uses the same diff resolution and the same gates as the hosted App, what you clear locally is what the PR review would have found — minus the round-trip.
Point the CLI at an explicit diff range to review a series of commits, a feature branch against its base, or a single commit in isolation. This is useful when you want to review work that is already committed but not yet pushed.
sigilix review --base origin/main
sigilix review --range HEAD~3..HEAD
The CLI honors the path filters and profile from your sigilix.json, so monorepo packages, generated files, and vendored directories are excluded exactly as they are on a PR. You can also narrow a single run to a subtree when you only want feedback on one area.
sigilix review --path "packages/api/**"
Because the CLI exits with a non-zero status when a blocking finding survives the gates, you can wire it into a Git pre-push hook or a CI step as a fast first pass — letting the hosted PR review be the authoritative backstop rather than the first time anyone sees the problem.

​
Bring your own model

On paid tiers, the CLI does not lock you to one provider. Point Sigilix at OpenAI’s Codex CLI, Anthropic’s Claude Code, or your own SDK and provider keys, and you pay that provider’s usage directly. Your model still fetches Sigilix’s verified context layer, so it inherits the precision without re-deriving the repo. 
# Inspect and set the model behind your terminal workflow
sigilix config model
See Bring Your Own Models for the full picture, and note that the hosted PR ensemble itself runs per-role tuned models with cross-provider fallback — BYO applies to the CLI and chat surfaces.

​
How the CLI relates to the hosted App

The CLI and the GitHub App are two surfaces over one engine. The App is the authoritative, always-on backstop on every PR; the CLI is the same review pulled forward into your terminal. Crucially, the relationship is symbiotic: hosted reviews build the earned-context layer, and the CLI reads from it. The more your repo is reviewed, the cheaper and more grounded every local review becomes.

Deep-Research Chat

Ask why a finding fired or what a change affects — answers grounded in the same earned-context layer.

Command reference

The CLI commands — review, chat, config, and auth — with representative usage.

The Ensemble

The five-specialist architecture the CLI brings to the terminal.

Earned Context

The reusable, verified layer every review deposits — and what the CLI reads from.