Your backend and frontend shouldn't share one code reviewer.
A senior engineer who knows your payments service reviews a pull request differently than one who knows your design system. They carry different context, reach for different facts, and worry about different failure modes. A single generic AI reviewer pointed at every repository throws that away — it treats a database migration and a React component the same way.
Spinal does not. Every repository gets its own configured reviewer: its own instructions, its own tools, its own way of proving a finding, and its own rules about what it is allowed to see. You set it once per repo, and it applies to every pull request after.
A reviewer should know each repo the way the team that owns it does.
Different repos fail in different ways.
The risks that matter are not uniform across a codebase. In a backend service, the dangerous changes lock a hot table, break a migration's backward compatibility, or add a call to an already-strained dependency. In a frontend app, they ship a secret to the client, drift from the design system, or quietly regress accessibility.
A reviewer with one fixed brief either floods the low-risk repo with comments meant for the high-risk one, or misses what actually matters. The fix is not a cleverer generic prompt. It is giving each repo a reviewer configured for that repo.
Instructions: the reviewer's brief.
Write the standing rules for a repo in plain language — "migrations must be backward-compatible," "flag any new dependency in the PR body," "prefer typed query helpers." They become part of the reviewer's brief on every pull request, the way an onboarding doc shapes a new engineer.
You also choose how it shows up: a comment per issue or a single summary, and whether Spinal reviews every PR automatically, only when someone @-mentions it, or auto-reviews and runs tests.
Knowledge: ground it in your own docs.
Instructions tell the reviewer what to enforce; knowledge tells it why. Point a repo at the documents that explain it — an architecture decision record, a service runbook, the design-system guide — and the reviewer can reason from how your team actually decided to build things, not generic best practice.
A backend repo references its data-model and migration conventions; a frontend repo references its component and accessibility guidelines.
Tools: let the reviewer call your systems.
A diff rarely contains everything you need to judge it. Spinal can call HTTP endpoints you register per repo, each with a note telling it when to reach for that one. A backend repo might expose a service that returns the live database schema, so the reviewer can check a migration against the real table. Another might wire in feature-flag or deploy-scope lookups, or a customer-status endpoint.
The reviewer uses them mid-review, the way an engineer opens another tab to confirm a fact before approving.
Validation: prove findings in your runtime.
Spinal validates risky changes by writing tests and running them — but every repo runs differently. The validation profile captures yours: the runtime, the test command, the services a test needs (Postgres, Redis), the migrations to run first, and the environment to set. Spinal can scan the repo to infer it, then verify the setup in your own CI before it relies on it.
The backend's pytest-and-Postgres suite and the frontend's Vitest run are both first-class — no one-size-fits-all test harness.
Privacy: decide what it never sees.
Per repo, you list paths the reviewer will never read — gitignore-style globs for generated code, lockfiles, or sensitive directories — and regex patterns redacted from anything sent to the model, on top of built-in detectors for emails, phone numbers, and the like.
A payments repo can strip customer IDs and keys before review; an internal docs repo can leave everything in. Sensitive repos get protection without opting out of review.
A reviewer that knows the repo.
Configured this way, the reviewer arrives at each pull request with what a senior owner of that repo would have: the standing rules, the ability to look up the facts the diff omits, a way to prove a risky change in the repo's own test setup, and clear limits on what it can see. The result is higher signal — comments that fit the codebase — and findings grounded in your real systems instead of generic guesses.
It also means one team's strictness does not become another's noise. The payments repo can be exacting; the internal tool can stay light. Same engine, different reviewers.
Configure a repo. See the difference on the next PR.
Connect a repository, set its instructions, tools, and validation, then open a pull request — Spinal reviews it as that repo's reviewer, not a generic one. 15 days free, no credit card.