The developer reference.
The exact strings behind the developers page: commands and flags, the two checks, the GitHub App permissions, and the Supabase connection.
What it can and cannot do to your repository.
The deterministic gate compares planned and discovered events. Call it over HTTP or as an MCP tool from your coding agent.
The model review reads the diff when a pull request is opened, reopened or synchronized. It comments on exact lines and can be wrong.
In CI, the scanner posts findings to the check endpoint. A not-ok answer fails the build without commenting on the pull request.
Reviews collect on a Pull requests page in your workspace.
Four permissions, and nothing else.
The App is scoped to the repositories you select, and every change it makes arrives as a pull request.
- ContentsReading your code and skene-context/ files; committing updates back through pull requests.Read & write
- Pull requestsReading diffs, posting reviews, opening fix pull requests.Read & write
- IssuesResponding to /skene fix comments.Read & write
- MetadataListing the repositories the installation can access.Read
Skene OSS, from the terminal.
The three ways to run it, the two schema flags, and the model providers it takes.
The full subcommand list, flag tables and engine HTTP API are in the Skene OSS docs: see the CLI reference and the HTTP API reference.
Two flags, seven providers, two agents.
- Two schema flags, and neither is the default
--schema-dirtakes a directory of exported .sql files;--db-urltakes a live PostgreSQL string, Supabase included. The CLI introspects at runtime and never persists credentials. Neither flag is required. - Seven values for --provider
openai, gemini, anthropic/claude, lmstudio, ollama, generic or skene, and
--api-keysets the key. lmstudio and ollama run locally and need no key. Skene charges nothing for the run;--provider skenepoints the CLI at Skene as a model provider without making the run a Cloud product. - Two agents, seven lifecycle stages
One emits a milestone per user-facing table in your schema; the other emits one per user-facing route, handler, analytics call or job in your repository. Milestones land across discovery, onboarding, activation, engagement, retention, expansion and virality.
No second analytics tool.
Your analytics tools keep receiving the same events.
The scanner recognises thirteen analytics platforms by pattern. It detects missing calls without reading event data.
You connect your own Supabase project over OAuth, with read-only access by default for schema inspection. Read-write access is opt-in and adds table counts and trigger deployment. A plan's measurement uses the connected data available for its inputs.
| What each check uses | |
|---|---|
| PostHog, Mixpanel and the rest | Unchanged |
| A second analytics tool | Not required |
| Repository scanning | Reads source code |
| Schema inspection | Does not read row values |
| After-launch measurement | Uses connected data inputs |
| Database writes | Read-write access is opt-in |
What to check before you connect a repository.
The full flag tables and the engine HTTP API are in the Skene OSS docs.
Does the check that fails my build use a model?
Do I have to connect a database?
Does anything land in my dependencies?
uvx skene analyse-journey . runs it with nothing installed, and the TUI binary comes from GitHub Releases. The pull request check runs as a GitHub App.Does this change what my analytics tools receive?
Put the check on a pull request.
The case for it, the review it writes, and what you keep if we go away are on the developers page.