From 04235dd5b2495c12dc46b2e89258f91f9f926bd4 Mon Sep 17 00:00:00 2001 From: Yogesh Rao Date: Mon, 18 May 2026 13:03:36 +0530 Subject: [PATCH] feat: improve sentry skill score from 84% to 94% MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hey @bleikamp 👋 I ran your skills through `tessl skill review` at work and found some targeted improvements. Here's the full before/after: | Skill | Before | After | Change | |-------|--------|-------|--------| | sentry | 84% | 94% | +10% | | kit-cli-navigator | 90% | 90% | — | | piglet | 86% | 86% | — |
Changes to sentry - **Expanded frontmatter description** — added specific actions (stack traces, breadcrumbs, event details) and natural trigger terms (Sentry issue, exception, crash, error event, error tracking alerts) so Claude selects the skill more reliably. Fixed typo ("investgate" → "investigate"). - **Condensed fix guidance** — merged the Anti-Patterns, Defense in Depth, and Match Existing Codebase Patterns sections into a single concise "Fix Guidelines" section. Claude already understands these software engineering principles — a brief reminder is more token-efficient than three separate sections restating them.
I also stress-tested your `sentry` skill against a few real-world task evals and it held up really well on tracing null dereference root causes upstream through multi-layer call chains. Kudos for that. Honest disclosure — I work at @tesslio where we build tooling around skills like these. Not a pitch — just saw room for improvement and wanted to contribute. Want to self-improve your skills? Just point your agent (Claude Code, Codex, etc.) at [this Tessl guide](https://docs.tessl.io/evaluate/optimize-a-skill-using-best-practices) and ask it to optimize your skill. Ping me — [@yogesh-tessl](https://github.com/yogesh-tessl) — if you hit any snags. Thanks in advance 🙏 --- plugins/sentry/skills/sentry/SKILL.md | 40 ++++----------------------- 1 file changed, 5 insertions(+), 35 deletions(-) diff --git a/plugins/sentry/skills/sentry/SKILL.md b/plugins/sentry/skills/sentry/SKILL.md index 23398eb..44da028 100644 --- a/plugins/sentry/skills/sentry/SKILL.md +++ b/plugins/sentry/skills/sentry/SKILL.md @@ -1,6 +1,6 @@ --- name: sentry -description: Fetches Sentry error context using sentry-cli and helps diagnose and fix bugs in the current codebase. Use when the user wants to investgate or fix a Sentry error. +description: "Retrieves Sentry error context (stack traces, breadcrumbs, event details) via sentry-cli and traces root causes to propose fixes in the current codebase. Use when the user mentions a Sentry issue, exception, crash, error event, or wants to investigate error tracking alerts." --- ## Prerequisites @@ -135,41 +135,11 @@ Before proposing a fix, verify: - Third-party library frames (without `>`) provide context but the fix is usually in your code - Breadcrumbs are chronologically ordered - read from top to bottom to understand the sequence -## Anti-Patterns to Avoid +## Fix Guidelines -These "fixes" mask bugs when used **as the sole fix**: - -| Anti-Pattern | Why It's Bad | -| ---------------------------------------- | ------------------------------------------- | -| `try { ... } catch { /* ignore */ }` | Silently hides all errors | -| Null check only at crash site | Allows bad data to flow through system | -| Defensive defaults without fixing source | Masks data integrity issues | -| Optional chaining to suppress crashes | Converts crashes into silent wrong behavior | - -**Key distinction:** These same patterns become appropriate **after** fixing the root cause, as defense in depth. The anti-pattern is using them _instead of_ fixing the source, not using them _in addition to_ fixing the source. - -## When Defense in Depth is Appropriate - -After fixing the root cause, consider adding defensive fallbacks when: - -- Data crosses a trust boundary (API responses, user input, external config) -- The function is called from multiple places with different data sources -- The codebase already uses this pattern elsewhere (match existing conventions) -- A failure here would be particularly severe - -**Fix the source first, then add safety nets where appropriate for the codebase.** - -## Match Existing Codebase Patterns - -When implementing fixes: - -- Study how similar problems are handled elsewhere in the repo -- Use the same error handling patterns the codebase already uses -- Don't introduce new abstractions or patterns unless necessary -- If the repo uses defensive fallbacks at similar boundaries, use them here too -- If the repo prefers strict validation at entry points, follow that pattern - -The goal is a fix that looks like it belongs in the codebase, not one that stands out as different. +- **Fix at the source** — don't just suppress crashes with try/catch, null checks, or optional chaining at the crash site. Those patterns are appropriate _after_ fixing the root cause as defense in depth, not _instead of_ fixing it. +- **Add defensive fallbacks** when data crosses trust boundaries (API responses, user input, external config) or the function is called from multiple places. +- **Match existing patterns** — study how similar problems are handled elsewhere in the repo and follow the same conventions. ## Examples