The check that reads your pull request before your reviewer does.
Skene reviews every pull request on the repository you link it to, compares the diff against the instrumentation your team said should exist, and comments on the exact lines where a tracking call was removed or renamed.
If the PR is clean it passes and says so. That review is one line, and it is the one you should see most of the time.
company_profile_saved missing at components/onboarding/CompanyProfileStep.tsx:89/skene fix only restores tracking calls this PR removed; it cannot add new events.Your agent will delete tracking and your tests will still pass.
Nothing turns red when a tracking call disappears, so you find out three sprints later.
The line that records an event is a side effect. Coding agents are good at logic and indifferent to side effects, so when one refactors a checkout flow the posthog.capture rides along with the change and does not survive it.
The feature still works. The tests still pass. Nothing turns red. The events just stop arriving, and you find out three sprints later when someone asks why a chart looks wrong.
You can fix the code that afternoon. You cannot go back and collect the six weeks you missed.
The review carries the fix.
Where the fix pins to one contiguous span you get a suggestion you can commit, not a description and a ticket to write later.
You do not get a description of what broke and a ticket to write later. Where the fix pins to one contiguous span, it arrives as a GitHub suggestion you commit in one click. Where it cannot, because the change is too big or spans files, you get a copy-pasteable prompt for your coding agent instead.
Commenting /skene fix restores tracking calls the pull request removed. It cannot add an event that was never there.
What it can and cannot do to your repository.
Four permissions, and nothing reaches your default branch without a pull request you merge.
Skene never pushes to your default branch. Everything it writes arrives as a pull request you review and merge yourself.
There are two checks and they work differently. The gate you can run in CI is a deterministic comparison: it returns the events your journey says should exist and do not. The pull request review is a model reading your diff against a policy, which is what lets it comment on the exact line and suggest a fix, and also what means it can be wrong.
You dismiss a review the way you dismiss any review. The deterministic check is the one to gate a merge on.
| Permission | Access | Used for |
|---|---|---|
| Contents | Read & write | Reading your code and skene-context/ files; committing updates back through pull requests |
| Pull requests | Read & write | Reading diffs, posting reviews, opening fix pull requests |
| Issues | Read & write | Responding to /skene fix comments |
| Metadata | Read | Listing the repositories the installation can access |
How often it comments.
A pull request that touches no instrumented code gets one line. The ones that get more are the ones you need to read.
Every pull request on the linked repository gets looked at. One that touches no instrumented code passes with a single line and nothing else, so the comments that say more are the ones where something you depend on actually changed.
Review activity collects on a Pull requests page in your workspace, so the history lives somewhere other than your notifications.
| Pull request | What the review said |
|---|---|
| #4812 | Touched no instrumented code. Passed with one line. |
| #4815 | Removed a tracked call. Commented on the exact line, with a fix. |
Who decides, and who fixes.
Your GTM team names what has to be trusted. Engineering reviews a pull request and writes no event names.
Your GTM team decides which funnels and lifecycle moments have to be trusted. Skene turns those into required instrumentation in the product, and tells you when a change breaks it. You get a specific finding on a specific line, with a fix you can read.
Nobody is asking engineering to own the reporting. They are asking you not to let it break silently, which is a smaller request and a much more reasonable one.
| Who | Owns |
|---|---|
| GTM | Which funnels and lifecycle moments have to be trusted |
| Skene | Turning those into required instrumentation, and saying which line broke it |
| Engineering | The code, and a pull request to merge or dismiss |
No second analytics tool.
PostHog, Mixpanel, Amplitude and Segment keep receiving exactly what they receive today.
Skene protects the instrumentation that feeds PostHog, Mixpanel, Amplitude, Segment, and whatever else your team already runs. Your dashboards stay where they are and keep working the way they do.
On the database side the default connection is read-only, and read-only means schema only: table, column, and type definitions. It does not read row data and does not write. There is a read-write mode for automations, it is opt-in, and none of the checks need it.
- PostHogKeeps receiving what it receives today
- MixpanelUnchanged
- AmplitudeUnchanged
- SegmentUnchanged
What you keep if we go away.
The core is MIT-licensed and runs with no Skene account and no service of ours behind it.
This is the question the open-source half exists to answer. The core is MIT-licensed and public at github.com/SkeneTechnologies/skene. It runs with no account, no connection to us and no service of ours behind it, against a model provider you supply, and it writes its output into your own repository as a plain YAML file. If Skene Cloud stopped tomorrow, the tool still runs.
Your product data stays in your own database. Uninstalling the GitHub App revokes every permission at the source, and anything already committed to your repository stays there.
Three steps, and none of them is a package install.
Nothing enters your dependencies and nothing enters your lockfile.
The check runs as a GitHub App, not as something you add to your dependencies. There is nothing to import and nothing in your lockfile. The deterministic check is also reachable from CI as a job you add yourself, which runs on your own runner and fails the build rather than commenting. That is a different path from the review that writes on the pull request, and the note further down says why the difference matters.
Sign in
Install the GitHub App
Turn on PR reviews
The command-line tool is a different product.
Skene OSS runs on your machine and writes the journey it finds into your own repository.
Skene OSS is MIT-licensed, runs on your machine, and needs no Skene account. It reads a codebase and writes the journey it finds into your repository. It does not watch releases and it does not comment on pull requests: those are Cloud.
Which one do you want?
The PR check if you want releases watched and tracking restored on a pull request. That is this page.
Skene OSS if you want to point something at a repo right now and read the output yourself.