Help us improve
Share bugs, ideas, or general feedback.
From sentryx
Instrument an app with SentryX — a self-hosted Sentry-analog that unifies error tracking, distributed tracing, and product analytics/funnels, correlated by trace_id — exposed over a remote MCP server named `sentryx`. Use whenever the sentryx MCP tools are present (get_started, whoami, create_project, instrument_hint, define_event/funnel/feature, get_funnel, search_issues, get_issue, get_trace, prepare_fix_bundle) or the user mentions SentryX, "instrument my app", "error tracking", "distributed tracing", "define a funnel", "product analytics", "trace debugging", "set up Sentry / SentryX", "OTLP", or "fix this bug with SentryX". Teaches the connect-once flow, the instrument flow (detect stack → 5 product questions → create_project → snippets → define_* → verify), and the fix-bugs flow (search_issues → prepare_fix_bundle). NOT for hosted Sentry.io, Datadog, or PostHog — those are different tools.
npx claudepluginhub kyzdes/claude-skills --plugin sentryxHow this skill is triggered — by the user, by Claude, or both
Slash command
/sentryx:sentryxThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
SentryX is a **self-hosted observability platform** — error tracking + distributed tracing + product analytics/funnels, all **correlated by `trace_id`** — exposed over a remote MCP server named `sentryx`. This skill tells you how to take a raw app from zero to fully instrumented, and how to use the read tools to fix high-impact bugs without spelunking.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Explores codebases via GitNexus: discover repos, query execution flows, trace processes, inspect symbol callers/callees, and review architecture.
Share bugs, ideas, or general feedback.
SentryX is a self-hosted observability platform — error tracking + distributed tracing + product analytics/funnels, all correlated by trace_id — exposed over a remote MCP server named sentryx. This skill tells you how to take a raw app from zero to fully instrumented, and how to use the read tools to fix high-impact bugs without spelunking.
Don't read everything. Call get_started first — it returns who you are, your org's projects, the tool catalogue, and the exact next step. Pull only what the task needs (instrument_hint, get_funnel, prepare_fix_bundle). Reading every issue or trace "to understand the app" is the failure mode this skill exists to prevent — it burns your context before you've instrumented anything or fixed a single bug.
SentryX MCP is remote, over Streamable HTTP at /api/mcp, authed by an org Bearer token. The human mints the token in the web UI; you register the server:
claude mcp add --transport http sentryx https://mcp.moone.dev/api/mcp \
--header "Authorization: Bearer <token>"
project:create, define:write, read).https://mcp.moone.dev/api/mcp (fallback https://ingest.moone.dev/api/mcp); local http://localhost:8080/api/mcp. Note: sentryx.moone.dev is the web UI, not the MCP.whoami (returns your org + scopes) and get_started (orients you). A 401 means a bad/missing Bearer — see references/connect.md.When a user first connects (or asks to "set up SentryX"):
get_started; tell them what's wired (project? funnels? recent errors?).whoami.track()), correlated by trace_id. The web UI shows /issues, /p/<slug>/funnels, and traces.search_issues → prepare_fix_bundle).The hero path: a raw repo → errors + traces + funnels live in the web. Follow it in order.
package.json (node/nextjs), requirements.txt/pyproject.toml (python), go.mod (go), an SPA entry (browser). That picks the instrument_hint stack.steps (ordered event names).track() carries a stable user_id (cross-session) or a per-session_id distinct_id.define_feature keys.window_seconds.create_project(name, slug) → {project_id, dsn, otlp_http, otlp_grpc, track_url, is_new}. Idempotent on slug; capture dsn, otlp_*, track_url.instrument_hint(stack, dsn, track_url) → {errors_snippet, tracing_snippet, track_snippet, notes}.dsn (+ release, environment).otlp_http / otlp_grpc.track() and call it at each funnel step (Q2) and each feature (Q4). Every track() must carry distinct_id + user_id + session_id, and trace_id when in a request — that backbone is what correlates a product event to the error/trace in the same flow. Copy-paste per stack: references/example-instrumentation.md.define_event(name) for each event you emit, define_funnel(key, name, steps, window_seconds), define_feature(key, event_names).get_funnel(funnel_key). Monotonically decreasing step counts + a biggest_drop = instrumentation is correct. The project now shows in the web.Full end-to-end recipe with example calls: references/workflow.md.
Any agent with the org token gets the full read picture:
search_issues(status?, level?, q?) — list issues, newest activity first → pick an id.prepare_fix_bundle(issue_id) — the hero tool. One call returns a ~250–600-token, fix-ready bundle: summary, exception, in-app frames + source context, breadcrumbs, the correlated trace (with bottleneck), impact (times_seen / affected_users), similar issues, and suspect commits. Fix from this; don't reconstruct it by hand.get_issue(issue_id) for the latest-event summary, get_trace(trace_id) to drill into spans + correlated errors.get_funnel — where users drop off tells you what to fix or build next.SentryX records and audits the fix; you do the actual work — read the bundle, write the patch, and open a DRAFT PR with gh. SentryX never patches code (there is no server-side patch service). The loop, with idempotency so a retried step audits exactly once:
record_fix_attempt(issue_id, summary, idempotency_key) — call this the moment you start from prepare_fix_bundle, before opening a PR. Sets the issue's fix_status='investigating' and logs an audit entry. Use a stable key like fix-<issue_id>-<short-sha> so retries don't double-log.git checkout -b fix/issue-<issue_id>
git commit -am "Fix: <summary>"
gh pr create --draft --title "Fix: <summary>" --body "Fixes issue #<issue_id> in SentryX. <root cause from prepare_fix_bundle>"
link_pr(issue_id, pr_url, idempotency_key) — call this after gh pr create returns the URL. Sets fix_status='pr_open' + stores pr_url. Use a stable key like pr-<issue_id>-<pr_number>.resolve_issue(issue_id) — call this only after the PR is merged/deployed. Sets the issue status='resolved', fix_status='fixed', and logs the resolve.Use list_fix_attempts(issue_id) before starting to check whether a fix is already in flight (don't open a duplicate PR). Full step-by-step recipe: references/workflow.md (recipe 2).
Every MCP tool — meta (get_started, whoami), write (create_project, define_*, instrument_hint), and read (search_issues, get_issue, get_trace, get_funnel, prepare_fix_bundle) — with inputs, outputs, and when to use: references/tools.md.
See also:
references/tools.md — every MCP tool with I/O shapes and when to use.references/workflow.md — end-to-end recipes: onboard a project, fix a high-impact error, analyze a funnel drop-off.references/connect.md — token mint walkthrough + connect troubleshooting (401, whoami, rotate/revoke).references/example-instrumentation.md — copy-paste snippets per stack (Node/Next, Python, Go, browser): Sentry init, OTLP env, and the track() helper.