Prove what worked, from the tables you already have.
Skene computes the verdict on what you shipped from your own database. It checks the customer journey against the tables your product actually writes first, so the number it gives you holds up when somebody asks where it came from.
Read-only by default. No card.
- Supabaseconnected
- Productionacme-productionassigned
- GitHubacme/webappmainconnected
Grounded in your real schema
The journey is checked against the tables your product actually writes. Never row data.
A missing event holds the plan back
The plan reaches launch ready only when every event it needs is found in your code or your data. A table Skene could not sample blocks nothing.
Owner-controlled connection
Only a workspace owner can start or change it. Tokens are encrypted at rest.
One source is enough to start.
Supabase over OAuth, GitHub through an app scoped to the repositories you pick, or both. An unlinked environment reports as not linked.
- No workspace-wide switch between development and production
- Deploys and trigger installs target the production slot only
Read-only reads table, column and type definitions, never row data or table counts. When something needs to write, like deploying an automation, Skene asks you to upgrade the connection first.
Or point the CLI at exported SQL.
Skene OSS reads your repository and writes the customer journey it finds to skene-context/journey.yaml. It needs no Skene account, and you point it at your own model provider.
What changes when you opt in.
| Capability | Read-only (default) | Read-write (opt-in) |
|---|---|---|
| Table, column and type definitions | Yes | Yes |
| Table counts | No | Yes |
| Trigger deployment for automations | No | Yes |
| Who can start or change it | A workspace owner | A workspace owner |
| OAuth tokens at rest | AES-256-GCM encrypted | AES-256-GCM encrypted |
Start with the read-only connection.
Connect Supabase over OAuth, read-only by default. Reconnect with read-write when you want table counts or triggers.