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 is distributed as a GitHub App. This page covers the deep details of how it interacts with GitHub.

​
Installation flow

See Installation for the full step-by-step. In short:
  1. Sign in at sigilix.ai/signup → authorize OAuth
  2. Pick a plan
  3. Click “Install Sigilix on a repository”
  4. Choose org + repo selection
  5. GitHub redirects back to Sigilix with the installation ID

​
Permissions deep dive

Sigilix requests these GitHub permissions:
PermissionAccessWhat we do with it
Pull requestsRead & writeRead PR diff/files; post reviews + inline comments
ContentsReadFetch file contents at PR head SHA for context
MetadataReadDefault; required by all GitHub Apps
IssuesRead & writeReply to @sigilix mentions
ChecksRead & write(Optional) Publish a check run alongside the review
Workflow runsRead(Optional) Diagnose CI failures via workflow log analysis
Anything not listed is not accessed:
  • ❌ Code outside opened PRs (we don’t scan main branch on push)
  • ❌ Releases, deployments, secrets, packages
  • ❌ Admin or billing surfaces
  • ❌ Code from repositories where Sigilix isn’t installed

​
Branch protection compatibility

Sigilix is designed to play well with branch protection rules. You can require a Sigilix review status check before merging:

​
Required status check

After a Sigilix review, the corresponding check run is created with conclusion:
  • success — verdict is APPROVE
  • failure — verdict is REQUEST_CHANGES with at least one Critical finding
  • neutral — review couldn’t run (rate limit, internal error)
To require this check before merge:
  1. Repository → Settings → Branches → Branch protection rules
  2. Add a rule for main (or your default branch)
  3. Check “Require status checks to pass before merging”
  4. Search for Sigilix and select it
Now PRs can’t merge until Sigilix’s check is success. If a developer pushes a fix, Sigilix re-reviews automatically and updates the check.

​
Required reviewers

Sigilix’s verdict (APPROVE or REQUEST_CHANGES) counts as a GitHub PR review. If your branch protection rule requires “1 approving review,” Sigilix’s APPROVE counts toward that.

​
CODEOWNERS interaction

If your repo has a CODEOWNERS file requiring a specific reviewer, Sigilix’s review doesn’t replace that requirement. Both the human reviewer and Sigilix’s verdict apply.

​
Multi-repo install

Most orgs install Sigilix on multiple repos. Tiers determine how many:
TierRepos
Free1
ProUp to 10
MaxUnlimited
To add a repo to an existing install:
  1. Open GitHub App settings
  2. Find the Sigilix install → Configure
  3. Add the repo to the selection
  4. Save
The next PR opened on that repo will be reviewed.

​
Per-repo configuration

sigilix.yaml lives at the root of each repo. Different repos can have different configurations — disable Spark on a marketing site, enable strict thresholds on a payment service, etc. There’s no org-level config. If you want shared rules across repos, copy them via a tool like git-template-monitor (or just commit the same sigilix.yaml to each repo).

​
Webhook delivery

Sigilix subscribes to these events:
  • pull_request — opened, synchronize, reopened, ready_for_review
  • issue_comment — created (filters for @sigilix mentions)
  • pull_request_review_comment — created (filters for inline mentions)
  • workflow_run — completed (only for failure-triage; opt-in)
GitHub’s webhook delivery has at-least-once semantics. Sigilix uses a (prNumber, headSha) dedupe key in KV to prevent duplicate reviews on redelivered webhooks. If a delivery fails (Sigilix’s HTTP endpoint returns non-200), GitHub retries with exponential backoff for up to 24 hours. After that, the delivery is marked failed and you can manually redeliver from the GitHub App webhook log.

​
GitHub Enterprise Server

Sigilix supports GitHub Enterprise Server (GHES) on Max tier. The webhook URL is configurable per-installation; reach out to set up a private installation against your GHES instance.

​
Token rotation

Sigilix mints installation tokens on demand using the App’s private key. Tokens expire after 1 hour and are not stored — they’re minted fresh for each review. If you suspect Sigilix’s private key has been leaked, rotate it from the GitHub App settings page. Old tokens become invalid; Sigilix’s deployment picks up the new key automatically (after a re-deploy, in dev; immediately, in production).

GitLab

Roadmap support for GitLab.

Bitbucket

Roadmap support for Bitbucket.