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 four-specialist ensemble — Logic & Architecture, Security, Performance, and Tests, unified by 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 included with your plan — sign up free or start a 14-day Pro trial, then run sigilix login. Questions? Contact support@sigilix.ai.
Install
The CLI ships through three channels — pick whichever fits your setup. macOS and Linux are supported; the installed binary is sigilix.
# npm
npm install -g @sigilix/cli
# bun
bun install -g @sigilix/cli # or run without installing: bunx @sigilix/cli
# Homebrew
brew install sigilix/tap/sigilix # or: brew tap sigilix/tap && brew install sigilixThere is also a standalone installer if you don’t want a package manager involved:
curl -fsSL https://sigilix.ai/install | bashPlatform support: macOS and Linux are officially supported. A Windows build exists but is currently best-effort and unverified — prefer WSL for a supported Windows experience.
Sign in
The CLI talks to api.sigilix.ai out of the box — no environment variables or endpoint configuration needed. Authenticate it to your Sigilix account once per device:
sigilix login # opens your browser to app.sigilix.ai and authorizes this device
sigilix whoami # shows the signed-in user, plan, and entitlements
sigilix logout # signs out (clears the stored key on this device)sigilix login opens app.sigilix.ai in your browser; approve the request there and the CLI receives a per-user API key it stores for this device. The CLI is tier-aware: sigilix whoami re-checks your plan and shows which entitlements are active — including whether bring-your-own model keys (a paid-tier feature) are enabled for your account. sigilix logout clears the key locally; to revoke it server-side, use your account settings at app.sigilix.ai.
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
logic, security, performance, and tests run in parallel and are unified by the synthesizer — 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.
Resolve the target
sigilix review reviews your uncommitted changes by default — staged, unstaged, and untracked files. Pass a target to review something else: a branch name (sigilix review main diffs your current branch against it), a commit hash, or a PR URL. The reviewer reads the full files being modified, not just the diff hunks, so code that only looks wrong in isolation is judged in context.
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.
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.
Run the ensemble
logic, security, performance, and tests review the expanded diff in parallel. Each emits candidate findings anchored to specific lines.
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.
Synthesize and print
The synthesizer 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 the synthesizer, then findings anchored to files and lines, each tagged by specialist (Logic / Security / Performance / Tests), by severity (Critical / Warning / Info), and by proof tier (VERIFIED / REPRODUCED / GROUNDED / MODEL).
# Review your uncommitted changes
sigilix review
# Reviewing 7 changed files (against origin/main)…
# deterministic checks ……… 1 dependency advisory injected
# earned context …………………… index + code graph + review memory loaded
# ensemble ……………………………… Logic · Security · Performance · Tests
# synthesis ……………………………… Synthesizer
#
# ── src/auth/session.ts ─────────────────────────────────────
# ✗ Critical · Security · GROUNDED L42
# Session token compared with == instead of a constant-time
# compare; vulnerable to timing analysis.
#
# ⚠ Warning · Logic · GROUNDED L88
# Early return skips the audit-log write on the error path.
#
# ── src/db/orders.ts ────────────────────────────────────────
# ⚠ Warning · Performance · MODEL L17
# Query inside the loop — likely N+1 over `order.items`.
#
# Verdict: Request changes · 1 Critical · 2 WarningsThe output above is illustrative — exact wording, glyphs, and counts depend on your repo and the change. The shape is real: a synthesizer summary, inline findings tagged by specialist and severity, and a proof-tier pill on every finding.
Common workflows
Review before you open the PR
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.
Review a branch, a commit, or a PR
Pass a target to review something other than your working tree — a branch name to diff your current branch against it, a commit hash to review that commit in isolation, or a PR URL to review the pull request itself.
sigilix review main # current branch vs. main
sigilix review 4f2c9ab # a single commit
sigilix review https://github.com/acme/api/pull/214 # a pull requestMake it a pre-push habit
Run sigilix review before you push — manually or wired into your own pre-push hook — 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 key
By default the CLI runs on Sigilix’s own hosted models. On paid tiers you can instead connect your own model-provider key (Anthropic, OpenAI, or another provider) and pay that provider’s usage directly. Whatever model you bring is still handed Sigilix’s verified context layer.
sigilix models # list the models available to your account
sigilix providers login # connect a provider with your own key (paid tiers)
sigilix run --model <provider/model> "…" # pick a model for a single runSigilix’s hosted models are tuned to prioritize the injected codebase context and learned memory that make a review grounded. A frontier model brought via BYOK carries strong internal priors and may not honor that context as fully — so Sigilix can’t guarantee a BYOK model uses your org memory and codebase context the way its hosted models do. Read the full grounding trade-off on Bring Your Own Key. (The hosted PR ensemble is unaffected — BYOK applies only to the CLI and chat.)
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.
Ask why a finding fired or what a change affects — answers grounded in the same earned-context layer.
The CLI commands — review, run, login, providers, and models — with representative usage.
The four-specialist architecture the CLI brings to the terminal.
The reusable, verified layer every review deposits — and what the CLI reads from.