You can fix code tomorrow. You cannot recover an event that never fired today. A feature bug can be patched and redeployed. A missing event leaves a permanent gap in the period you needed to measure.
The break you do not see
Product, growth and pricing decisions depend on event data. A pull request can rename or remove the call behind a funnel without breaking the feature itself. Nothing in the interface has to turn red. The report keeps drawing from an incomplete history, and the gap may surface only when somebody asks why a number moved.
Coding agents increase the number of changes that can touch those calls. A checkout rewrite, onboarding refactor or settings change can carry a tracking call with it. Functional tests may still pass because the user-facing path still works.
Review the change before it becomes history
Skene's GitHub App reviews pull-request diffs when PR reviews are enabled. It looks for tracking regressions and missing events, then leaves specific findings on the pull request. When a fix fits one contiguous block, the review can include a GitHub suggestion. Broader fixes carry a prompt that a coding agent can apply.
/skene fix has a narrower job. It can restore tracking that the pull request removed. It cannot invent an event that never existed, so a missing-event finding uses the prompt instead.
Skene also provides a deterministic check through its API and MCP tools. That check compares events scanned from the codebase with the planned baseline in the workspace. When a Supabase project is linked, it can verify whether expected database tables exist. These are two different checks: the pull-request review judges the diff, while the deterministic gate compares scanned evidence with the plan.
Your schema grounds the journey
A read-only Supabase connection supplies table, column, type and relationship definitions for the journey. Authorized measurement queries can also read table evidence when the connected role permits them. Read-only prevents database writes; it does not mean schema-only access. Skene combines schema structure with tracking calls found in the linked repository to build the lifecycle journey and its evidence inventory.
A step can be supported by a code event, by a database table or by both. The Events page shows detected events, database-backed steps and gaps in one place. A Status check rescans the code, rereads the schema and rematches events without rebuilding the journey.
Schema evidence and event evidence answer different questions. A table can show that a state is observable in the database. A tracking call can show what the application intends to record. Keeping both visible makes a change easier to review before it removes the evidence behind a report.
Keep the review outside the code generator
The tool that writes a change should not be the only tool checking what disappeared. Run the review where the change is visible: inside the coding agent through MCP, in CI through the deterministic endpoint, or on the pull request through the GitHub App.
That timing matters. Before merge, a missing call is a review finding. After release, it becomes missing history.
Try it
Connect a repository, run the first analysis and enable pull-request reviews. Add a read-only Supabase connection when you want schema evidence alongside code events. Read the docs or open the Skene OSS repository for the local analysis workflow.
Continue with Skene
How Skene works
Skene reads the event writes in your code and checks them against your Supabase schema on every PR.
Skene vs. analytics tools
Compare keeping your telemetry in your own Supabase to shipping events to hosted product analytics platforms.
Pricing
Skene OSS is free and the free audit costs nothing. Pro is $249 a month; Enterprise is quoted.