Smithery is now a part of Arcade.dev! Read more in our announcement here
Write and review technical documentation for Sentry SDK docs. Use when creating, editing, or reviewing documentation pages, especially MDX files in docs/platforms/.
Every section must answer: Why would a developer need this?
Bad:
## Server Actions
Use `captureException` in Server Actions to report errors.
Good:
## Server Actions
Server Actions that return error states to the client catch errors before Sentry sees them.
Report these manually so you don't lose visibility.
Organize around what developers are trying to do, not around API methods.
Bad structure (API-centric):
Good structure (intent-centric):
If the same pattern appears in multiple sections, consolidate it.
Ask yourself: "Am I showing the same code pattern again? If yes, reference the earlier example instead."
Bad:
## Error Boundaries
Sentry.captureException(error);
## Server Actions
Sentry.captureException(error);
## API Routes
Sentry.captureException(error);
Good:
## Where Manual Capture is Needed
These Next.js patterns catch errors before Sentry sees them:
- Error boundaries (error.tsx files)
- Server Actions returning error states
- API routes with custom error responses
[Single example with explanation of the pattern]
Don't just show code. Explain the specific condition that requires this approach.
Bad:
Add captureException to report these errors.
Good:
Next.js error boundaries intercept errors before they bubble up to Sentry's global handler.
Without manual capture here, these errors silently disappear from your Sentry dashboard.
Write clearly and concisely. Long pages with repeated patterns lose readers.
Best practices should add new information, not repeat earlier examples.
Bad best practice:
## Best Practices
### Use captureException in Error Boundaries
[same code shown earlier]
Good best practice:
## Quick Reference
- Error boundaries: Required for visibility (errors intercepted by Next.js)
- Server errors: Automatic unless you return custom responses
- Client errors: Automatic for unhandled exceptions
Use <SplitLayout> for side-by-side text/code when:
Don't use when:
Link to related docs rather than repeating content:
For automatic tracing, see <PlatformLink to="/configuration/apis/">API Reference</PlatformLink>.
Always include filename when showing file-specific code:
Consecutive fenced code blocks are automatically grouped into tabbed code snippets. Each tab can have a title and filename:
```swift {tabTitle:Swift}
SentrySDK.capture(error: error)
```
```objc {tabTitle:Objective-C}
[SentrySDK captureError:error];
```
{mdExpandTabs}The .md export (mainly used by LLMs via the "Copy page" button) collapses tab groups
by default: only the first tab is included, with a note listing the other tabs
(e.g. Other available variations of the above snippet: yarn, pnpm). This keeps context lean when tabs show
trivial variations an LLM can infer on its own.
Add {mdExpandTabs} to the first code fence in a group when the tabs contain code an LLM
cannot reliably derive from seeing just one tab. This is rare — most times, adding only
one tab to the produced .md is enough.
```swift {tabTitle:Swift} {mdExpandTabs}
SentrySDK.start { options in
options.dsn = "..."
}
```
```objc {tabTitle:Objective-C}
[SentrySDK startWithConfigureOptions:^(SentryOptions *options) {
options.dsn = @"...";
}];
```
Expand — the code is too different for an LLM to infer:
--import vs Bun)wrapHttpFunction vs wrapCloudEventFunction), serverless async/sync handlerscommonMain / iosApp / androidApp), Flutter navigation (Navigator / GoRouter / AutoRoute)import) vs CDN (<script>) vs Loader (sentryOnLoad)Collapse (default) — an LLM can figure it out from one tab:
@sentry/hono/cloudflare vs @sentry/hono/node in platform-includes/ snippets)When reviewing documentation:
