Claude Code skills

Install the Otis skills into Claude Code and get a set of slash commands: ask Otis about your product (/otis), and walk Claude Code through instrumenting your app (/otis-analyze, /otis-instrument, /otis-verify, /otis-status). The skills run locally in your own Claude Code session; live project state, Otis's analysis, and reference material come from Otis's MCP server.

If you want Otis to run instrumentation for you automatically, use the GitHub App. For Cursor and other MCP-capable agents, see MCP server. All three paths share the same project state.

What you get

Five slash commands plus live access to your Otis project:

The four instrumentation skills (analyze, instrument, verify, status) are multi-step workflows: the skill tells Claude Code which steps to take, and Claude Code reads code, writes code, runs tests, and calls Otis's MCP server for live project state and reference material. /otis is different — it hands your question to Otis's product-intelligence agent and relays the answer (see Ask Otis about your product).

Install

npx @runotis/setup --team <team-slug> --project <project-slug>

What the setup command does:

1. Writes .mcp.json pointing at your Otis project's MCP endpoint.
2. Writes the five skill files into .claude/skills/{otis,otis-analyze,otis-instrument,otis-verify,otis-status}/SKILL.md.
3. Prefetches SDK and measurement reference docs into .otis-cache/docs/ for zero-latency reads.
4. Adds .otis-cache/ to your .gitignore.

Re-run the same command any time to sync the latest skill files and docs. Pass --refresh to force a full rewrite.

First-time auth

Claude Code's built-in MCP OAuth handles auth automatically. The first time a skill calls the MCP server, Claude Code opens a browser window for you to sign in via Clerk (the same login you use for the Otis dashboard). There are no API keys to manage and no secrets stored in your repo.

Ask Otis about your product

/otis is the odd one out among the skills: instead of changing code, it consults Otis — your project's product-intelligence agent — about how your product is actually used. Otis holds the telemetry-derived insights, analytics, and project memory your coding agent doesn't.

/otis what are users struggling with this week?
/otis why are people dropping off in onboarding?

You don't have to type /otis — once the MCP server is connected, Claude Code recognizes a product-usage question and invokes the skill on its own. Otis replies with a distilled answer plus a deep link to the full dashboard view, and it's read-only: it analyzes and recalls, but won't change your project state.

For the underlying askOtis tool and its options (discussing a specific insight, continuing a conversation), see MCP server → Ask Otis about your product.

Typical flow

Start in a repo where you've run npx @runotis/setup:

/otis-analyze       → profile the codebase, pick measurements
/otis-instrument    → add SDK + instrumentation, run tests, open a PR
# merge the PR and deploy
/otis-verify        → check arriving spans against expectations

/otis-status is always available as a read-only summary of where things stand.

/otis-analyze

Claude Code scans your entry points, framework usage, and any existing telemetry; writes a codebase profile back to your Otis project; then assesses which Otis measurements are a good fit based on the patterns it sees. Recommendations are surfaced in-session for you to accept or skip, and saved back to your project.

/otis-instrument

For each measurement you've accepted:

• Installs @runotis/sdk if not already present.
• Adds initialization following the right integration guide for your runtime.
• Adds per-measurement instrumentation in code — wrap() around AI framework calls, traced() around relevant helpers, context pulled from your auth.
• Records declared span mappings back into your project so the dashboard knows what to expect.
• Runs your lint, type-check, and test scripts. Fixes obvious failures in-place.
• Opens a single PR with all the changes.

/otis-verify

Runs local checks again, then uses the MCP server to inspect recent ingestion:

• Has instrumentation code hit production yet (spans arriving in the last 24 hours)?
• Are the expected attributes showing up on those spans?
• Are any measurements silent that should be producing spans?

Surfaces issues directly in-session, and can propose fixes if the instrumentation code needs adjustment.

/otis-status

Shows the current phase of each measurement: recommended / in progress / instrumented / verified / skipped, plus any open issues.

What gets written to your repo

• .mcp.json — points at your Otis project. Commit this to share with your team.
• .claude/skills/otis*/SKILL.md — the five skills (/otis plus the four instrumentation workflows). Commit these.
• .otis-cache/docs/ — prefetched SDK and measurement reference. Gitignored; regenerate any time with npx @runotis/setup.
• .otis-cache/ itself is added to .gitignore if not already present.

Working alongside the GitHub App

Skills and the GitHub App write to the same project state. If the GitHub App has already run on this repo, /otis-analyze picks up the existing profile and measurement recommendations instead of starting from scratch. Conversely, changes you make through the skills are visible to the automated path — so post-deploy verification works whether instrumentation landed via a GitHub App PR or a local one.

Updating

Re-run npx @runotis/setup --team <team-slug> --project <project-slug> at any time. The setup command content-hashes what's already on disk; if nothing's changed it prints "Already up to date." Add --refresh to force-rewrite skill files and refetch docs.