Back to Details

sentry-sdk-skill-creator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create a Sentry SDK Skill Bundle

创建Sentry SDK技能包

Produce a complete, research-backed SDK skill bundle — a main wizard SKILL.md plus deep-dive reference files for every feature pillar the SDK supports.
生成一个完整、基于调研的SDK技能包——包含一个主向导SKILL.md文件，以及SDK所支持的每个功能支柱的深度参考文件。

Invoke This Skill When

何时调用本技能

  • Asked to "create a Sentry SDK skill" for a new platform
  • Asked to "add support for [language/framework]" to sentry-agent-skills
  • Building a new 
    sentry-<platform>-sdk
    skill bundle
  • Porting the SDK skill pattern to a new Sentry SDK
Read 
${SKILL_ROOT}/../../docs/sdk-skill-philosophy.md
first — it defines the bundle architecture, wizard flow, and design principles this skill implements.
  • 被要求为新平台「创建Sentry SDK技能」时
  • 被要求为sentry-agent-skills「添加对[语言/框架]的支持」时
  • 构建全新的
    sentry-<platform>-sdk
    技能包时
  • 将SDK技能模式移植到新的Sentry SDK时
请先阅读
${SKILL_ROOT}/../../docs/sdk-skill-philosophy.md
——它定义了本技能所遵循的包架构、向导流程和设计原则。

Phase 1: Identify the SDK

阶段1：确定SDK

Determine what you're building a skill for:
bash
undefined
明确你要为其构建技能包的SDK：
bash
undefined

What SDK? What's the package name?

目标SDK是什么？包名称是什么？

Examples: sentry-go, @sentry/sveltekit, sentry-python, sentry-ruby, sentry-cocoa

示例：sentry-go, @sentry/sveltekit, sentry-python, sentry-ruby, sentry-cocoa


Establish the **feature matrix** — which Sentry pillars does this SDK support?

| Pillar | Check docs | Notes |
|--------|-----------|-------|
| Error Monitoring | Always available | Non-negotiable baseline |
| Tracing/Performance | Usually available | Check for span API |
| Profiling | Varies | May be removed or experimental |
| Logging | Newer feature | Check minimum version |
| Metrics | Newer feature | May be beta/experimental |
| Crons | Backend only | Not available for frontend SDKs |
| Session Replay | Frontend only | Not available for backend SDKs |
| AI Monitoring | Some SDKs | Usually JS + Python only |

**Reference existing SDK skills** to understand the target quality level:

```bash
ls skills/sentry-*-sdk/ 2>/dev/null

建立**功能矩阵**——该SDK支持哪些Sentry功能支柱？

| 功能支柱 | 查阅文档 | 备注 |
|--------|-----------|-------|
| 错误监控 | 始终可用 | 不可妥协的基础功能 |
| 追踪/性能 | 通常可用 | 检查是否有Span API |
| 性能剖析 | 视情况而定 | 可能已移除或处于实验阶段 |
| 日志 | 较新功能 | 检查最低版本要求 |
| 指标 | 较新功能 | 可能处于Beta/实验阶段 |
| 定时任务 | 仅后端可用 | 前端SDK不支持 |
| 会话重放 | 仅前端可用 | 后端SDK不支持 |
| AI监控 | 部分SDK支持 | 通常仅JS和Python SDK支持 |

**参考现有SDK技能包**以明确目标质量标准：

```bash
ls skills/sentry-*-sdk/ 2>/dev/null

Read 1-2 existing SDK skills for pattern reference

阅读1-2个现有SDK技能包以参考模式


---

---

Phase 2: Research

阶段2：调研

This is the most critical phase. Skill quality depends entirely on accurate, current API knowledge. Do NOT write skills from memory — research every feature against official docs.
这是最关键的阶段。 技能包的质量完全取决于准确、最新的API知识。请勿凭记忆编写技能包——需对照官方文档调研每个功能。

Research Strategy

调研策略

Spin off parallel research tasks (using the 
claude
tool with 
outputFile
) — one per feature area. Each task should:
  1. Visit the official Sentry docs pages for that feature
  2. Visit the SDK's GitHub repo for source-level API verification
  3. Write thorough findings to a dedicated research file
Read 
${SKILL_ROOT}/references/research-playbook.md
for the detailed research execution plan, including prompt templates and file naming conventions.
启动并行调研任务（使用
claude
工具并指定
outputFile
）——每个功能领域对应一个任务。每个任务需：
  1. 访问该功能的官方Sentry文档页面
  2. 访问SDK的GitHub仓库以进行源码级API验证
  3. 将详尽的调研结果写入专用的调研文件
阅读
${SKILL_ROOT}/references/research-playbook.md
获取详细的调研执行计划，包括提示模板和文件命名规范。

Research Batching

调研批量处理

Batch research tasks by topic area. Run them in parallel where possible:
BatchTopicsOutput file
1Setup, configuration, all init options, framework detection
research/<sdk>-setup-config.md
2Error monitoring, panic/exception capture, scopes, enrichment
research/<sdk>-error-monitoring.md
3Tracing, profiling (if supported)
research/<sdk>-tracing-profiling.md
4Logging, metrics, crons (if supported)
research/<sdk>-logging-metrics-crons.md
5Session replay (frontend only), AI monitoring (if supported)
research/<sdk>-replay-ai.md
Important: Tell each research task to write its output to a file (
outputFile
parameter). Do NOT consume research results inline — they're large (500–1200 lines each). Workers will read them from disk later.
按主题领域批量处理调研任务。尽可能并行执行：
批次主题输出文件
1安装、配置、所有初始化选项、框架检测
research/<sdk>-setup-config.md
2错误监控、恐慌/异常捕获、作用域、信息补充
research/<sdk>-error-monitoring.md
3追踪、性能剖析（若支持）
research/<sdk>-tracing-profiling.md
4日志、指标、定时任务（若支持）
research/<sdk>-logging-metrics-crons.md
5会话重放（仅前端）、AI监控（若支持）
research/<sdk>-replay-ai.md
重要提示： 告知每个调研任务将结果写入文件（通过
outputFile
参数）。请勿直接在线处理调研结果——结果内容较大（500-1200行）。后续工作流将从磁盘读取这些文件。

Research Quality Gate

调研质量校验

Before proceeding, verify each research file:
  • Has actual content (not just Claude's process notes)
  • Contains code examples with real API names
  • Includes minimum SDK versions
  • Covers framework-specific variations
bash
undefined
在进入下一阶段前，验证每个调研文件：
  • 包含实际内容（而非仅Claude的流程说明）
  • 包含带有真实API名称的代码示例
  • 标注了最低SDK版本
  • 涵盖框架特定的差异
bash
undefined

Quick verification

快速验证

for f in research/<sdk>-*.md; do echo "=== $(basename $f) ===" wc -l "$f" grep -c "^#" "$f" # should have multiple headings done

**Re-run any research task that produced fewer than 100 lines** — it likely failed silently.

---
for f in research/<sdk>-*.md; do echo "=== $(basename $f) ===" wc -l "$f" grep -c "^#" "$f" # 应包含多个标题 done

**若调研文件内容不足100行，请重新执行该调研任务**——它可能已静默失败。

---

Phase 3: Create the Main SKILL.md

阶段3：创建主SKILL.md文件

The main SKILL.md implements the four-phase wizard from the philosophy doc. It must stay under 500 lines.
主SKILL.md文件需实现哲学文档中定义的四阶段向导。文件长度必须控制在500行以内。

Gather Context First

先收集上下文信息

Before writing, run a scout or read existing skills to understand conventions:
  • Frontmatter pattern (name, description, license)
  • "Invoke This Skill When" trigger phrases
  • Table formatting and code example style
  • Troubleshooting table conventions
开始编写前，先查看现有技能包以了解规范：
  • 前置元数据格式（名称、描述、许可证）
  • 「何时调用本技能」的触发短语
  • 表格格式和代码示例风格
  • 故障排查表格规范

SKILL.md Structure

SKILL.md文件结构

markdown
---
name: sentry-<platform>-sdk
description: Full Sentry SDK setup for <Platform>. Use when asked to "add Sentry
  to <platform>", "install <package>", or configure error monitoring, tracing,
  [features] for <Platform> applications. Supports [frameworks].
license: Apache-2.0
---
markdown
---
name: sentry-<platform>-sdk
description: 为<Platform>提供完整的Sentry SDK安装配置。当被要求「为<platform>添加Sentry」「安装<package>」，或为<Platform>应用配置错误监控、追踪、[功能列表]时使用。支持[框架列表]。
license: Apache-2.0
---

Sentry <Platform> SDK

Sentry <Platform> SDK

Invoke This Skill When

何时调用本技能

[trigger phrases]
[触发短语]

Phase 1: Detect

阶段1：检测

[bash commands to scan project — package manager, framework, existing Sentry, frontend/backend]
[用于扫描项目的bash命令——包管理器、框架、已存在的Sentry、前端/后端类型]

Phase 2: Recommend

阶段2：推荐

[opinionated feature matrix with "always / when detected / optional" logic]
[带有「始终启用/检测到X时启用/可选」逻辑的功能矩阵]

Phase 3: Guide

阶段3：引导

Install

安装

Quick Start — Recommended Init

快速开始——推荐初始化配置

Framework Middleware (if applicable)

框架中间件（若适用）

For Each Agreed Feature

针对每个确认启用的功能

[reference dispatch table: feature → ${SKILL_ROOT}/references/<feature>.md]
[参考调度表：功能 → ${SKILL_ROOT}/references/<feature>.md]

Configuration Reference

配置参考

[key init options table, environment variables]
[关键初始化选项表格、环境变量]

Verification

验证

[test snippet]
[测试代码片段]

Phase 4: Cross-Link

阶段4：交叉关联

[detect companion frontend/backend, suggest matching SDK skills]
[检测配套的前端/后端，推荐匹配的SDK技能包]

Troubleshooting

故障排查

[common issues table]
undefined
[常见问题表格]
undefined

Key Principles for the Main SKILL.md

主SKILL.md文件的核心原则

  1. Keep it lean — deep details go in references, not here
  2. Detection commands must be real — test them against actual projects
  3. Recommendation logic must be opinionated — "always", "when X detected", not "maybe consider"
  4. Quick Start config should enable the most features with sensible defaults
  5. Framework middleware table — exact import paths, middleware calls, and quirks
  6. Cross-link aggressively — if Go backend, suggest frontend. If Svelte frontend, suggest backend.
  1. 保持精简——详细内容放入参考文件，而非主文件
  2. 检测命令必须真实有效——需在实际项目中测试
  3. 推荐逻辑必须明确——使用「始终启用」「检测到X时启用」，而非「可考虑」
  4. 快速开始配置应启用最多功能——同时使用合理的默认值
  5. 框架中间件表格——包含准确的导入路径、中间件调用方式和注意事项
  6. 积极交叉关联——若为Go后端，推荐前端技能包；若为Svelte前端，推荐后端技能包

Phase 4: Create Reference Files

阶段4：创建参考文件

One reference file per feature pillar the SDK supports. These are deep dives — they can be longer than the main SKILL.md.
为SDK支持的每个功能支柱创建一个参考文件。这些文件是深度讲解——长度可以超过主SKILL.md文件。

Reference File Structure

参考文件结构

markdown
undefined
markdown
undefined

<Feature> — Sentry <Platform> SDK

<功能> — Sentry <Platform> SDK

Minimum SDK: 
<package>
vX.Y.Z+
最低SDK版本要求：
<package>
vX.Y.Z+

Configuration

配置

Code Examples

代码示例

Basic usage

基础用法

Advanced patterns

高级模式

Framework-specific notes (if applicable)

框架特定说明（若适用）

Best Practices

最佳实践

Troubleshooting

故障排查

IssueSolution
undefined
问题解决方案
undefined

What Makes a Good Reference

优质参考文件的标准

Read 
${SKILL_ROOT}/references/quality-checklist.md
for the full quality rubric.
Key points:
  • Working code examples — not pseudo-code, not truncated snippets
  • Tables for config options — type, default, minimum version
  • One complete example per pattern — don't show 5 variations of the same thing
  • Framework-specific notes — call out when behavior differs between frameworks
  • Minimum SDK version at the top — always
  • Honest about limitations — if a feature was removed (like Go profiling), say so
阅读
${SKILL_ROOT}/references/quality-checklist.md
获取完整的质量评估标准。
核心要点：
  • 可运行的代码示例——而非伪代码或截断的片段
  • 配置选项表格——包含类型、默认值、最低版本要求
  • 每种模式一个完整示例——无需展示同一模式的5种变体
  • 框架特定说明——明确指出不同框架间的行为差异
  • 顶部标注最低SDK版本——必须包含
  • 如实说明限制——若某功能已移除（如Go SDK的性能剖析），需明确告知

Feature-Specific Guidance

各功能的指导要点

FeatureKey things to cover
Error MonitoringCapture APIs, panic/exception recovery, scopes, enrichment (tags/user/breadcrumbs), error chains, BeforeSend, fingerprinting
TracingSample rates, custom spans, distributed tracing, framework middleware, operation types
ProfilingSample rate config, how it attaches to traces, or honest "removed/not available"
LoggingEnable flag, logger API, integration with popular logging libraries, filtering
MetricsCounter/gauge/distribution APIs, units, attributes, best practices for cardinality
CronsCheck-in API, monitor config, schedule types, heartbeat patterns
Session ReplayReplay integration, sample rates, privacy masking, canvas/network recording
功能核心覆盖内容
错误监控捕获API、恐慌/异常恢复、作用域、信息补充（标签/用户/面包屑）、错误链、BeforeSend、指纹识别
追踪采样率、自定义Span、分布式追踪、框架中间件、操作类型
性能剖析采样率配置、如何关联到追踪，或如实说明「已移除/不支持」
日志启用标志、日志API、与主流日志库的集成、过滤规则
指标计数器/仪表盘/分布API、单位、属性、基数最佳实践
定时任务签到API、监控配置、调度类型、心跳模式
会话重放重放集成、采样率、隐私掩码、画布/网络录制

Phase 5: Verify Everything

阶段5：全面验证

Do NOT skip this phase. SDK APIs change frequently. Research can hallucinate. Workers can fabricate config keys.
请勿跳过此阶段。 SDK API会频繁更新。调研过程可能出现幻觉，生成的内容可能包含虚构的配置项。

API Verification

API验证

Run a dedicated verification pass against the SDK's actual source code:
Research prompt: "Verify these specific API names and signatures against
the <SDK> GitHub repo source code: [list every API from the skill files]"
Things that commonly go wrong:
  • Config option names with wrong casing (
    SendDefaultPii
    vs 
    SendDefaultPII
    )
  • Fabricated config keys that don't exist (
    experimental.tracing
    — verify it's real)
  • Deprecated APIs used instead of modern replacements (
    configureScope
    → 
    getIsolationScope
    )
  • Features listed as available when they've been removed (profiling in Go SDK)
  • Wrong minimum version numbers
针对SDK的实际源码执行专门的验证步骤：
调研提示：「对照<SDK> GitHub仓库的源码，验证以下这些特定API的名称和签名：[列出技能包文件中的所有API]」
常见问题：
  • 配置选项名称大小写错误（
    SendDefaultPii
    vs 
    SendDefaultPII
    ）
  • 虚构的配置项（
    experimental.tracing
    ——需验证是否真实存在）
  • 使用已废弃的API而非现代替代方案（
    configureScope
    → 
    getIsolationScope
    ）
  • 标注为可用但已移除的功能（Go SDK的性能剖析）
  • 最低版本号错误

Review Pass

审核环节

Run a reviewer on the complete skill bundle:
  • Technical accuracy of code examples
  • Consistency between main SKILL.md and reference files
  • Consistency with existing SDK skills in the repo
  • Agent Skills spec compliance (frontmatter, naming, line count)
对完整的技能包进行审核：
  • 代码示例的技术准确性
  • 主SKILL.md文件与参考文件的一致性
  • 与仓库中现有SDK技能包的一致性
  • 符合Agent Skills规范（前置元数据、命名、行数限制）

Fix Review Findings

修复审核发现的问题

Triage by priority:
  • P0: Misleading claims (advertising removed features) — fix immediately
  • P1: Incorrect APIs, deprecated methods — fix before merge
  • P2: Style inconsistencies, version nitpicks — fix if quick
  • P3: Skip
按优先级处理：
  • P0：误导性声明（宣传已移除的功能）——立即修复
  • P1：错误的API、已废弃的方法——合并前修复
  • P2：风格不一致、版本细节问题——若修复简单则处理
  • P3：跳过

Phase 6: Register and Update Docs

阶段6：注册并更新文档

After the skill passes review:
  1. Update README.md — add to the SDK Skills table
  2. Update AGENTS.md — if the philosophy doc or skill categories section needs it
  3. Add usage examples — trigger phrases in the Usage section
  4. Document the bundle pattern — if this is a new SDK, note the references/ structure
技能包通过审核后：
  1. 更新README.md——添加到SDK技能包表格中
  2. 更新AGENTS.md——若哲学文档或技能分类部分需要更新
  3. 添加使用示例——在Usage部分添加触发短语
  4. 记录包模式——若这是新SDK，需标注references/目录结构

Commit Strategy

提交策略

Each major piece gets its own commit:
  1. docs: add sdk-skill-philosophy reference
    (if new)
  2. feat(<platform>-sdk): add sentry-<platform>-sdk main SKILL.md wizard
  3. feat(<platform>-sdk): add reference deep-dives for all feature pillars
  4. docs(readme): add sentry-<platform>-sdk to available skills
  5. fix(skills): address review findings
    (if any)
每个主要部分单独提交：
  1. docs: add sdk-skill-philosophy reference
    （若为新增）
  2. feat(<platform>-sdk): add sentry-<platform>-sdk main SKILL.md wizard
  3. feat(<platform>-sdk): add reference deep-dives for all feature pillars
  4. docs(readme): add sentry-<platform>-sdk to available skills
  5. fix(skills): address review findings
    （若有）

Checklist

检查清单

Before declaring the skill complete:
  • Philosophy doc read and followed
  • All feature pillars researched from official docs (not from memory)
  • Research files verified (real content, correct APIs, >100 lines each)
  • Main SKILL.md under 500 lines
  • Main SKILL.md implements all 4 wizard phases
  • Reference file for each supported feature pillar
  • APIs verified against SDK source code
  • Review pass completed, findings addressed
  • Profiling/removed features honestly documented (not advertised)
  • Cross-links to companion frontend/backend skills
  • README.md updated
  • All commits polished with descriptive messages
在宣布技能包完成前，确认以下事项：
  • 已阅读并遵循哲学文档
  • 所有功能支柱均基于官方文档调研（非凭记忆）
  • 调研文件已验证（包含真实内容、正确API、超过100行）
  • 主SKILL.md文件长度低于500行
  • 主SKILL.md文件实现了全部4个向导阶段
  • 每个支持的功能支柱都有对应的参考文件
  • API已对照SDK源码验证
  • 已完成审核环节，且问题已修复
  • 性能剖析/已移除功能已如实记录（未宣传）
  • 已添加到配套前端/后端技能包的交叉关联
  • README.md已更新
  • 所有提交都有描述性的提交信息