Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.sigilix.ai/llms.txt

Use this file to discover all available pages before exploring further.

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.

​
The commands

CommandWhat it doesWhen to use
/sigilix reviewRe-runs the full specialist ensembleAfter a rebase, or when you want a fresh review independent of webhook timing
/sigilix improvePosts apply-able suggested-change comments for the latest diffWhen you want concrete patches, not just commentary
/sigilix describe [pr|internal|external]Drafts a PR description, internal changelog, or external changelogBefore merge, when filling in the PR body or release notes
/sigilix helpInline list of available commandsWhen you forget the syntax
You can also write @sigilix <free text question> for a conversational reply that scopes context to the PR.

​
/sigilix review

Re-runs the four specialists + Core synthesizer on the current head SHA. Useful when:
  • You just rebased and want a fresh review instead of waiting on the webhook.
  • The previous review was on a stale SHA (rare, but happens during force-push storms).
  • You want to test a sigilix.json change without pushing a new commit.
The output is a normal review comment — same shape as the automatic ones.

​
/sigilix improve

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.

​
/sigilix describe [mode]

Drafts text for the human-authored parts of a PR. Three modes:
ModeOutputWhere to paste it
pr (default)A PR description draft with Summary + Testing sectionsThe PR body
internalInternal-audience changelog entryYour team’s release notes / Linear
externalUser-facing changelog entry — no internal jargonYour public changelog
/sigilix describe pr
/sigilix describe internal
/sigilix describe external
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.

​
/sigilix help

Posts an inline list of commands and their usage. No model call, no rate-limit cost — useful for fast self-service.

​
Configuring commands via sigilix.json

The commands block lets you tune prompts and models per-command, per-repo. Both fields are optional. 
{
  "commands": {
    "review": {
      "model": "kimi-k2.6:cloud"
    },
    "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": "glm-5.1:cloud"
    }
  }
}

​
prompt — addendum

Appended to the command’s system prompt. Don’t rewrite the prompt; add to it. 
{
  "commands": {
    "describe": {
      "prompt": "Always start with 'You can now...' for external changelogs."
    }
  }
}

​
model — override

Override the default model for this command. The allowlist:
  • glm-5.1:cloud
  • kimi-k2.6:cloud
  • qwen3-coder:480b-cloud
  • deepseek-v4-pro:cloud
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 (which use kimi-k2.5:cloud and qwen3-coder-next:cloud). The specialist ensemble is internally tuned for cross-provider resilience and uses specific versions for that purpose; command overrides expose a broader, more current selection because commands run independently of the ensemble’s cross-provider failover logic.

​
What you can’t override

KnobWhy not
Individual specialist models for reviewSpecialists are tuned together; per-repo overrides risk de-tuning the ensemble. Use guidance to influence behavior instead.
The synthesizer modelSame — the synthesizer is fixed to keep cross-PR comparability.
Per-command rate limitsPlan-tier defaults apply. Bursts beyond your tier queue or 429.

​
Defaults

Without a commands block, each command uses Sigilix’s vetted defaults:
CommandDefault model
reviewThe full specialist + synthesizer ensemble (see Specialists)
improveglm-5.1:cloud
describeglm-5.1:cloud
Mention reply (@sigilix ...)glm-5.1:cloud

​
Disabling a command

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.

​
Telemetry

Every command invocation records:
  • Command + mode (e.g., describe:external)
  • Whether overrides were applied (prompt-override, model-override)
  • Whether the override was valid (e.g., model on allowlist)
  • Duration, finding count (for review / improve), and output length
Useful for spotting commands that produce empty output or low-yield runs.

Rules & Guidance

Tune the prompts via guidance — usually a lighter touch than per-command overrides.

Opt-outs

Disable subsystems including describe.