Keep your events aligned with your Supabase schema.
You built fast on Supabase, maybe with Lovable, Bolt, or v0, and you do not have an analytics person. Then an agent renamed a column and your tracking stopped matching your tables. Skene reads your schema read-only and catches the mismatch on the pull request, before the data is gone.
The database is the contract.
Your Supabase schema already defines what every event is supposed to look like: the tables, the columns, the types. Skene reads that schema read-only and maps each event your code writes to the table it lands in. On every pull request, and on a schedule after merge, it checks that the two still match. It moves no data and duplicates nothing.
The event fired. Did it land?
PR #482 · checkout_completed
property renamed plan_tier -> tier
schema column public.orders.plan_tier (no column "tier")
result insert drops "tier"; revenue-by-plan
stops recording on mergeOne line in a checkout refactor, flagged before it ships. Without the check, the table keeps taking writes that quietly miss a column, and the gap is permanent.
Read-only, by design.
Skene connects to Supabase over OAuth and reads the schema. It never writes, never moves rows, and never copies your data into its own store. The check runs against structure, not records.
Built for teams without an analytics person.
The event fired. Did it land? When there is no one whose job is to watch the pipeline, that question goes unanswered until a number looks wrong. Skene answers it on the pull request, in the same place you already review code.
See what your last 10 PRs quietly broke.
Install in a minute. The first repo audit runs in about as long as your CI does.
