Specialists

Sigilix runs four domain specialists per review, in parallel — Logic & Architecture, Security, Performance, and Tests — unified by the synthesizer that runs after them. Each specialist has a focused prompt, a model tuned to its role, and a cross-provider fallback that makes a same-family provider outage unlikely to silence a specialist. A specialist can still be skipped if both primary and fallback fail — see the retry + fallback policy below.

Each specialist is named by its function. The same names are the role tokens (logic, security, performance, tests) you use in sigilix.json under rules.<role>.

The synthesizer is covered on its own page — see Synthesizer. This page is the four domain specialists. The synthesizer is separate and is not one of the four.

Logic & Architecture

What it catches:

• Circular dependencies between modules
• Layer-boundary violations (e.g., domain code importing from infrastructure)
• Interface drift between code and its tests/types
• Module cohesion issues

Model selection: the logic specialist runs a reasoning-heavy model — its proof-style chain-of-thought reasoning is well-suited for architectural arguments: tracing imports across files, evaluating layered architecture rules, and judging cohesion. When its primary provider is unavailable, Sigilix falls back to a model on a different provider with an uncorrelated outage profile, so a single provider incident can’t silence the logic role.

Sample finding:

[Logic] Boundary violation detected
domain/invoice.ts imports infra/stripe.ts
Rule: Domain may not depend on Infrastructure.
Suggested fix: Introduce `PaymentGateway` port in domain/.

Security

What it catches:

• Unsanitized inputs (SQL injection, XSS, SSRF, formula injection)
• Secret leakage in responses, logs, or version control
• Authentication and authorization bypasses
• Insecure regex patterns prone to ReDoS
• OWASP Top-10 patterns

Model selection: the security specialist runs a faster, higher-volume model than the logic specialist because security findings are higher-volume per PR and need turnaround. The cross-provider fallback ensures that if one provider is down, security still produces a verdict — security checks should never silently skip.

Sample finding:

[Security] Critical: Potential SSRF
utils/fetcher.ts:71 — user-supplied URL passed to fetch()
without an allowlist. Validate against approvedHosts[].

Performance

What it catches:

• N+1 query patterns in ORM-heavy code
• Hidden quadratic loops (especially newly inlined ones)
• Memory leaks (event listeners not removed, growing caches)
• Unbounded recursion or iteration
• Big-O regressions vs. the previous implementation

Model selection: the performance specialist runs a model tuned for cost-effective, high-throughput pattern-spotting, with a cross-provider fallback. The exact model choice is tuned over time from shadow telemetry — Sigilix keeps the primary that produces the highest-quality performance findings at the lowest latency, without changing this page each time.

Sample finding:

[Performance] O(n²) render loop
components/Table.tsx:112 — sorting inside render()
Memoize with useMemo keyed by sortKey.

Tests

What it catches:

• Dead code reachable only by impossible conditions
• Naming that doesn’t describe behavior (e.g., handleStuff when the function sends an email)
• Logic errors that pass type-checking (off-by-one, inverted conditions, swapped arguments)
• Missing test coverage on non-trivial branches added in the diff
• Inconsistent error handling between two functions added in the same PR

Model selection: the tests specialist’s surface is broad and shallow — it needs speed and breadth more than depth, so it runs a fast, high-coverage model with a cross-provider fallback. It often shares a model family with the security specialist, which lets Sigilix amortize warm-cache costs across two specialists.

Sample finding:

[Tests] Unreachable branch
checkout.ts:45 — early return bypasses tax calc
when total < 0. Remove or handle as error path.

Retry + fallback policy

Each specialist runs against its primary model with one retry on transient failure (503, 429, timeout). If retries are exhausted, the cross-provider fallback fires once. If the fallback also fails, that specialist’s contribution is skipped — the synthesizer synthesizes from the remaining specialists and the verdict is posted with a _3 of 4 specialists succeeded_ footnote.

The cross-provider design — primary and fallback on different infrastructure — is deliberate. Same-family fallbacks fail together when the upstream provider has an outage, defeating the fallback’s purpose.

Why these four domain specialists (and not more or fewer)?

The split was chosen empirically:

• Architecture, security, performance, tests are the four most-cited categories in code review failure-mode taxonomies.
• Adding a fifth domain specialist (e.g., a “documentation” specialist) didn’t materially improve catches — the tests specialist already covers naming and stale comments.
• Reducing to three domain specialists (e.g., merging logic and tests) left blind spots in cross-module reasoning.

The architecture supports adding domain specialists in the future. If a customer-driven category emerges (e.g., a domain-specific compliance specialist for financial code), it can plug into the synthesizer without changing the existing four.

Tuning per-repo

You can’t disable individual specialists — keeping the ensemble whole is what makes the synthesis work. What you can do per-repo:

• Influence what each catches via rules.<role> in sigilix.json (Rules & Guidance).
• Scope the review via pathFilters so a specialist sees less (Path Filters & Profile).
• Shift flag-worthiness via profile: "chill" | "assertive".

The synthesizer is always on. It’s how Sigilix produces a single coherent comment.

Independently of your config, the per-PR router can gate a specialist off when a change cannot need it (e.g., a docs-only PR) — with security and logic protected from ever being skipped unilaterally. See the review lifecycle.

Read next