Your backend and frontend shouldn't share one code reviewer

A payments service and a design system fail in different ways. A generic reviewer pointed at every repository treats a database migration, a React prop change, and a webhook handler too similarly.

Good review has local judgment. It knows which files are generated, which invariants are sacred, which tools can answer questions, which validation command proves the risky part, and which data should never leave the repo boundary.

A reviewer should know the repo the way the owning team does.

What repo-specific review means

A repo configuration is not just a prompt. It is a durable review profile: standing instructions, knowledge sources, tools, validation runtime, observability links, and privacy rules.

The goal is simple: when a PR opens, the reviewer should already know what the repo owner would check first.

Example: payments-api

For a backend payments service, the important failures are usually semantic and operational. The code can compile while still double-charging a customer, breaking idempotency, or deploying a migration that locks a hot table.

A useful Spinal configuration might include these standing rules:

Repository: payments-api
Rules:
- Money values must use Decimal, never float.
- Payment mutations must be idempotent by idempotency_key.
- Database migrations must be backward-compatible and safe for rolling deploys.
- Webhook handlers must tolerate duplicate and out-of-order delivery.
- New provider states must be mapped to an explicit internal enum.

Then attach tools and knowledge that make those rules enforceable:

Tools:
- lookup_schema(table_name)
- check_deploy_scope(paths)
- load_webhook_fixture(provider, event_type)
- query_recent_payment_errors(route, time_window)

Now a PR that changes `webhooks/stripe.ts` is reviewed differently from a generic TypeScript change. Spinal can check whether the changed handler is idempotent, whether the enum mapping is exhaustive, and whether recent production errors make this path sensitive.

What the review can say

Instead of a generic warning, the review can make a specific claim:

Finding: duplicate webhook delivery can create two ledger entries.
Why: processPaymentSucceeded now writes before checking event_id uniqueness.
Repo rule: payment mutations must be idempotent by idempotency_key or event_id.
Evidence: Stripe webhook retry logs show duplicate delivery for this event type in the last 7 days.
Validation: replay duplicate payment_succeeded fixture against Postgres and assert one ledger entry.

That is the difference between a model reading a diff and a configured reviewer applying team judgment.

Example: design-system

A frontend design system has different failure modes. The risk is usually not a transaction invariant. It is a broken component contract, inaccessible markup, visual drift, or a generated artifact that creates review noise.

The configuration should reflect that:

Repository: design-system
Rules:
- Public component props are API contracts.
- Breaking prop changes require a migration note.
- Generated snapshots and build artifacts should not drive findings.
- Interactive components need keyboard and screen-reader coverage.
- Color changes must reference design tokens, not raw hex values.

The tools are different too:

Tools:
- lookup_component_owner(component)
- check_storybook_story(component)
- run_accessibility_scan(story_id)
- compare_visual_snapshot(component, variant)

Now a PR that changes `Select.tsx` can be reviewed against the component registry, Storybook coverage, accessibility expectations, and token rules.

Validation should follow the repo

The validation profile is where many generic reviewers break down. A backend service may need Postgres, Redis, migrations, provider fixtures, and replay tests. A frontend package may need Vitest, Storybook, Playwright, and visual snapshots.

Spinal uses the repo profile to decide what kind of validation is possible and where it should run: existing CI/CD, a service-specific test environment, or a dedicated sandbox.

Privacy also belongs at repo level

Different repositories carry different sensitivity. The payments service may need aggressive redaction for customer identifiers, payment tokens, provider payloads, and logs. The design-system repo may mostly need ignored generated files and fixture boundaries.

Privacy profile:
- Ignore: dist/**, snapshots/**, generated/**
- Redact: Authorization headers, provider tokens, PAN-like values
- Restrict tools: production log queries require approved routes only
- Model boundary: do not send files matching secrets/** or fixtures/private/**

This lets sensitive repos keep strong review without flattening every repository into the strictest possible mode.

A practical checklist

When configuring a repo, start with six questions:

1. What invariants does this repo own?
2. Which files or generated artifacts should the reviewer ignore?
3. What tools can answer repo-specific questions?
4. What observability sources map to this repo's runtime behavior?
5. What validation command proves a risky finding?
6. What data must be redacted or kept out of model context?

If those answers are missing, review quality depends on a generic model guessing your architecture. If they are captured, every PR starts with the judgment your team would normally carry in its head.

The payoff

Repo-specific review makes Spinal stricter where a repo needs strictness and quieter where a repo needs restraint. It reduces false positives, improves validation, and makes findings easier for developers to trust.

The deeper point is that agentic software delivery needs durable team context. A coding agent can write across many repos. The trust layer around it needs to know each repo on its own terms.