/sigilix review, improve, describe, and help — what each command does, when to use it, and how to override prompts and models per-repo via sigilix.json.
Sigilix listens for @sigilix mentions and /sigilix <command> strings on PR comments. Each command runs a focused pipeline that’s narrower than a full review. This page documents the commands plus the commands block in sigilix.json (ARC-185) that lets you tune them per-repo.
After a rebase, or when you want a fresh review independent of webhook timing
/sigilix improve
Posts apply-able suggested-change comments for the latest diff
When you want concrete patches, not just commentary
/sigilix describe [pr|internal|external]
Drafts a PR description, internal changelog, or external changelog
Before merge, when filling in the PR body or release notes
/sigilix help
Inline list of available commands
When you forget the syntax
You can also write @sigilix <free text question> for a conversational reply that scopes context to the PR, and @sigilix remember … / @sigilix forget … to teach or retract a repo rule (see Conversational Learnings).
Runs a smaller pipeline focused on producible patches. The output is a comment containing GitHub’s native suggested-change blocks, which let reviewers click “Commit suggestion” to apply them directly.Use improve when you want fixes you can apply, not just findings to read.
The draft is posted as a comment between visible markers (<!-- sigilix:describe:pr:start --> … <!-- sigilix:describe:pr:end -->) so you can copy the section between them./sigilix describe apply (auto-write the description in place) is a planned follow-up.
Beyond the slash commands, Sigilix listens for plain @sigilix mentions on a PR or comment thread:
@sigilix <question> — a grounded, conversational reply scoped to the PR. Sigilix answers against the diff, the cited code, and the repo’s earned context (code graph, index, review history) rather than guessing from the question text alone.
@sigilix remember … / @sigilix forget … — teach or retract a repo rule. See below.
Mentions run a lighter pipeline than a full review and are not subject to the review rate limit.
You can teach Sigilix a rule in plain language and it will apply that rule judiciously in later reviews — and attribute it inline when it does (“applied because of a learned rule”). This is the headline mechanism for shaping reviews over time; it complements the longer-form, repo-wide guidance and per-role rules in sigilix.json.Two ways to capture a learning:
Form
Example
Effect
Reply to a finding
Reply to a Sigilix comment: “We use integer cents here, not floats — this is intentional.”
Sigilix records the rule and stops re-flagging the pattern it was wrong about.
Explicit command
@sigilix remember we always import from the package root, never deep paths
Sigilix records the stated rule.
To retract a rule:
@sigilix forget the integer-cents rule
When a learning is captured, Sigilix confirms with a “Learned something new” footer on its reply so you know the rule was stored. In subsequent reviews, when a learning changes the outcome, the affected finding (or the decision to suppress one) carries an inline attribution noting which learned rule applied — so the memory is auditable, never silent.Conversational Learnings is per-repo and accrues across PRs. For the full model — capture, injection, judicious application, and the carve-outs that protect Critical/security findings from being learned away — see Conversational Learnings.
The commands block lets you tune prompts and models per-command, per-repo. Both fields are optional.
{ "commands": { "review": { "model": "model-id-from-allowlist" }, "improve": { "prompt": "Always include the import statement in suggested patches when the patch references a new symbol." }, "describe": { "prompt": "Lead external changelogs with the user-facing impact, not the implementation. Skip internal ticket numbers.", "model": "model-id-from-allowlist" } }}
Override the default model for this command, using a model identifier from Sigilix’s current allowlist. The allowlist tracks the providers and model versions in production and changes over time, so don’t pin a specific model ID here from memory — check the live allowlist (or run /sigilix help) for the current set.Unknown model names fall back to the command’s default with a single warning logged in telemetry. The review proceeds — the validation is fail-open.
The command-override allowlist is intentionally a different set of model identifiers from the specialist fallbacks. The specialist ensemble is internally tuned for cross-provider resilience and pins specific model versions for that purpose; command overrides expose a broader, more current selection because commands run independently of the ensemble’s cross-provider failover logic.
describe ships with an explicit on/off (ARC-191) since some teams keep PR descriptions strictly human-authored:
{ "describe": { "enabled": false }}
(Note: that’s the top-level describe key, not nested under commands. The two coexist — describe.enabled is the kill switch; commands.describe is the tuning block.)Other commands don’t have an explicit kill switch — if you want Sigilix to ignore mentions entirely, that’s an operator-side setting, not a per-repo one.
