Parser, indexer, comparator, reporter.
Four components. No background daemons, no agents talking to agents, no LLM in the hot path. Static analysis with a baseline and a semantic diff.
Parser
Static analysis, no runtime. Skene parses the repository into an AST and walks every call site. Nothing executes. Nothing reaches your customers' browsers or your servers. The same approach a TypeScript compiler or an ESLint plugin uses to read your code.
Indexer
For every place your code writes an event, Skene records the target table, the columns the payload sets, the file path, the line number, and the control-flow context. The output is a structured map. The map is your baseline.
Comparator
On a PR, Skene rebuilds the map for the new state of the repo and diffs it against the baseline. The diff is semantic. It ignores formatting and reordering and surfaces only changes that affect what your code writes into your Supabase tables.
Reporter
Findings get serialized in three shapes: a markdown PR comment, an MCP response back to the coding agent, and a JSON payload for the cloud API. One engine, three output formats.
Skene sits at the front of your data stack.
Parser, indexer, comparator, reporter is what Skene is. This is where it runs. The tracking gets designed and kept honest at the pull request, so everything downstream (your Supabase database, your warehouse, the numbers you actually act on) stays trustworthy. Click a layer, or watch it walk the stack.
Tracking checkpoint
Skene, on every pull request
Skene reads your repo and your Supabase schema, maps every event write to the table it lands in, and checks that map on each pull request. The tracking gets designed and caught here, before a rename in a checkout PR quietly breaks a chart.
It comments the moment a write breaks.
Here's the checkpoint doing its job. A migration drops a column your events depend on. Your CI is green. Skene reads the change against your Supabase schema, catches the break on the PR, and names the exact chart it would flatten, before the merge and weeks before you'd notice it in the data.
feat(billing): Add subscriptions schema & track workspace plan limits
main from feature/subscriptions-schemaSome checks were not successful
1 failing check in skene[bot] • caught a broken write before merge
Skene check failed: this change breaks tracking you rely on.
Removing workspace_id from public.subscriptions breaks the events that fill your workspace-health and time-to-value charts.
retention by workspaceThree things to know
Static, not runtime
Skene does not instrument your app, intercept network calls, or sit in your data pipeline. It reads the same source files your linter does.
Open core
The parser, indexer, and comparator are open source on GitHub; the cloud-managed surfaces (hosted API, dashboard) are paid. Audit what runs against your code.
Workspace isolation
When you run Skene on the cloud API, your indexed manifest lives in an isolated workspace tied to your repository. Manifests are not pooled, not used to train anything, not shared across customers.
Patch the code tomorrow. The data from this week is already gone.
A renamed event passes every test, ships green, and sits broken for weeks before anyone notices. Skene runs as a GitHub Action on every pull request, reads your Supabase schema read-only, and comments the moment a write breaks, while your data is still recoverable. Usage-based on tokens, with $5 of free cloud credit to start. A PR that touches none of your tracking costs nothing.