feat: improve sentry skill score from 84% to 94%

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