GitHub App

The Otis GitHub App is the automated path. You connect a repo, and Otis does the instrumentation work end to end: profiling the codebase, picking relevant measurements, adding SDK calls, opening a pull request, and verifying that spans arrive correctly once you deploy.

If you'd rather drive instrumentation yourself from your coding agent, use Claude Code skills or the MCP server for Cursor and other MCP-capable agents. All three paths share the same project state, so you can start with the GitHub App and refine locally later.

What it does

Once connected to a repo, Otis works through four stages:

1. Profile — reads your codebase (entry points, framework, existing telemetry) and writes a codebase profile into your project.
2. Analyze — picks which of Otis's measurements apply to your app, and records that against the project.
3. Instrument — installs the SDK (if needed), adds instrumentation per selected measurement, runs your tests and type-check, and opens a single pull request against your default branch.
4. Verify — once the PR is merged and deployed, Otis watches arriving spans. If a measurement is instrumented but no matching spans appear, or attributes are missing, it surfaces the issue and can raise a follow-up PR.

Each stage saves its output into your Otis project, so you can see where a run is up to, review recommendations, and intervene at any point from the dashboard.

What you need

• An Otis project.
• A GitHub repo you can install an app on.
• The Otis SDK must support your runtime — see the Next.js, Node.js, Serverless, or OpenTelemetry integration guides. Otis instruments TypeScript / JavaScript codebases today.

Connecting a repo

Installation is driven from your Otis project's onboarding flow in the dashboard. You pick which repos Otis should have access to through the standard GitHub App install screen; Otis only reads repos you explicitly grant and only opens PRs on those.

What the pull request looks like

A single branch with:

• The Otis SDK added to package.json (or your lockfile equivalent) if not already present.
• Initialization wired into your app's entry points following the right integration guide for your runtime.
• Per-measurement instrumentation: wrap() calls around AI framework usage, traced() around relevant helper functions, context propagation (userId, sessionId, chatId) pulled from your auth layer.
• Declared span→measurement mappings saved back to your Otis project so the dashboard knows what to expect from the arriving spans.
• .otis-cache/ added to .gitignore.

Review it like any other PR: tests and type-check have already run in the sandbox, but you should still exercise the app locally before merging.

After you merge

Otis watches for spans from the new instrumentation to arrive. For each measurement:

• First spans seen — the measurement moves to verified.
• Silent (no matching spans after a reasonable window) — Otis flags the issue on your project and can open an adjustment PR with suggested fixes.
• Partial (spans arrive but some expected attributes are missing) — same feedback loop.

Verification runs adaptively: fast cadence right after a merge, slowing down as the project stabilizes. You don't need to trigger anything manually.

Privacy and security

• The GitHub App only reads repos you've granted access to, and only opens PRs on those repos.
• Codebase analysis runs in an ephemeral sandbox. No raw source code leaves Otis's backend other than through the pull request you explicitly merge.
• Spans arriving post-deploy go through the same PII redaction and identifier hashing as any other Otis traffic.
• The Otis GitHub App never pushes to your default branch directly — all code changes arrive as pull requests.

Working alongside your own coding agent

The GitHub App path and the Claude Code skills path write to the same project state. If Otis has already run a sandbox analysis on your repo, running /otis-analyze in Claude Code picks up where it left off rather than starting over. Edits you make locally using the skills sync back so the automated path stays current.

Use the GitHub App when you want Otis to do the initial heavy lift. Use the local path when you want fine-grained control over the instrumentation code or are iterating on a private branch that the GitHub App doesn't see.