Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →langfuse/sentry-instrumentation
Decide whether and how errors report to Sentry.
Passed 20 of 22 test cases with the skill, and 9 of 22 without it.
and 16 more in the full report
11 fixed9 passed either way2 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
I am adding error handling for an expired JWT token in web/src/features/auth/useSession.ts. Following our telemetry decision tree, what outcome should I select and how should it be documented in my PR?
| Checked | Without skill | With skill |
|---|---|---|
| Classifies expired session as an expected user-facing state that should render UX | Passed | Passed |
| Instructs writing a one-line decision summary in the PR description | Missed | Passed |
The instructions your model reads when the skill loads.
One idea: an event in Sentry is a promise that a human should act. If
nobody would act on it, do not send it. If you send it, make it legible (a
real Error with a stack — never a string/object/SyntheticEvent) and
routable (an area tag, a message stable enough to group). Sentry is not a
log sink; the server-side observability stack is where firehose logs live.
When adding or changing an error path in web/**, decide explicitly whether it
should reach Sentry — do not captureException (or console.error) reflexively.
Run the decision tree, then say in one line what you chose and why (in the plan
or PR description). The three outcomes:
| The failure is… | Do | Never |
|---|---|---|
| an expected user-facing state — a missing/forbidden resource, expired session, invalid user input, a malformed URL in user content | render the UX (error page / toast / plain text) | capture — it is the product working as designed |
| a transport / offline / infra failure — fetch failed, a 5xx on a poll, an LB blip | let the UI degrade; the server owns this signal | capture client-side — it is an amplified, lower-fidelity copy of a server truth |
| our code failed — an invariant broke, a parse threw, a worker failed to load | captureException a real Error with an area tag via the shared helpers | pass a raw string/object/Event |
console.error is a capture API here. instrumentation-client.ts enables
captureConsoleIntegration({ levels: ["error"] }), so every console.error
becomes a Sentry event. Logging an object yields an opaque [object Object]
fingerprint; logging non-actionable info still mints an issue. For
non-actionable logging use console.warn; to report a real failure, capture it
properly (below).
captureException:
captureUnknownError(context, value, extra?)
— turns any caught value into a legible Error (real Errors pass through
with their stack; everything else is synthesized), tags area, and logs via
console.warn so the console integration does not double-capture.reportWorkerLoadError({area, source, event, extra?})
— extracts the real fields from a Worker ErrorEvent
(message/filename/lineno/colno) instead of stringifying it to
[object ErrorEvent]. Every worker's onerror reports through this one;test cases passed, vs 9 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.