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 analytics call site, Skene records the library, the event name, the properties object, the file path, the line number, and the control-flow context. The output is a structured manifest. The manifest is your baseline.
Comparator
On a PR, Skene rebuilds the manifest 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 gets sent to your analytics backend.
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.
Three 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.
See what your last 10 PRs quietly broke.
Install in a minute. The first repo audit runs in about as long as your CI does.
