' --body-file /tmp/pr-body.md ``` Update existing PRs with `gh api`: ```bash gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER \ -f title='<title>' \ -F body=@/tmp/pr-body.md ``` Refresh the title and body when follow-up commits materially change scope, approach, breaking behavior, risk, migration, or review expectations. Skip typo-only, formatting-only, and rename-only follow-ups. ## Examples Small change: ```markdown The AI Customizations section now starts collapsed so it does not consume sidebar space before users need it. Expanding it preserves the existing saved preference behavior. ``` Breaking contract: ````markdown Run logs now emit chunk-level records instead of one skill-level record. Consumers that read top-level `findings` must iterate over `chunk.findings` for each record. Before: ```json {"skill": "security-review", "findings": [...]} ``` After: ```json {"schemaVersion": 1, "chunk": {"index": 1, "findings": [...]}} ``` ````  ---  ## 19. presentation-creator - **Source:** https://github.com/getsentry/skills/blob/main/skills/presentation-creator/SKILL.md - **Raw:** https://raw.githubusercontent.com/getsentry/skills/main/skills/presentation-creator/SKILL.md - **Markdown:** https://skillsdocs.com/getsentry/skills/presentation-creator.md - **Licence:** Apache-2.0 — https://spdx.org/licenses/Apache-2.0.html Bundled files (4), referenced from this skill's directory: - `references/chart-patterns.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/presentation-creator/references/chart-patterns.md - `references/design-system.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/presentation-creator/references/design-system.md - `references/sentry-glyph.svg` — https://raw.githubusercontent.com/getsentry/skills/main/skills/presentation-creator/references/sentry-glyph.svg - `references/sentry-logo.svg` — https://raw.githubusercontent.com/getsentry/skills/main/skills/presentation-creator/references/sentry-logo.svg  --- name: presentation-creator description: Create data-driven presentation slides using React, Vite, and Recharts with Sentry branding. Use when asked to "create a presentation", "build slides", "make a deck", "create a data presentation", "build a Sentry presentation". Scaffolds a complete slide-based app with charts, animations, and single-file HTML output. --- # Sentry Presentation Builder Create interactive, data-driven presentation slides using React + Vite + Recharts, styled with the Sentry design system and built as a single distributable HTML file. ## Step 1: Gather Requirements Ask the user: 1. What is the presentation topic? 2. How many slides (typically 5-8)? 3. What data/charts are needed? (time series, comparisons, diagrams, zone charts) 4. What is the narrative arc? (problem → solution, before → after, technical deep-dive) ### Data Assessment (CRITICAL) Before designing any slides, assess whether the source content contains **real quantitative data** (numbers, percentages, measurements, time series, costs, metrics). Only create Recharts visualizations for slides where real data exists. Do NOT fabricate, estimate, or invent data to fill charts. - **Has real data** → use a Recharts chart (bar, area, line, etc.) - **Has no data** → use text-based layouts: cards, tables, bullet columns, diagrams, or quote blocks. Do NOT create a chart with made-up numbers. If the source content is purely qualitative (narrative, opinions, strategy, process descriptions), the presentation should use zero charts. Recharts and `Charts.jsx` should only be included in the project if at least one slide has real data to visualize. ## Step 2: Scaffold the Project Create the project structure: ``` <project-name>/ ├── index.html ├── package.json ├── vite.config.js └── src/ ├── main.jsx ├── App.jsx ├── App.css └── Charts.jsx ``` ### index.html ```html <!doctype html> <html lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <link rel="preconnect" href="https://fonts.googleapis.com" /> <link href="https://fonts.googleapis.com/css2?family=Rubik:wght@300;400;500;600;700&display=swap" rel="stylesheet" /> <link href="https://fonts.googleapis.com/css2?family=Material+Symbols+Outlined:opsz,wght,FILL,GRAD@20..48,100..700,0..1,-50..200&display=swap" rel="stylesheet" /> <title>TITLE

` with: 1. An `

` heading 2. Optional subtitle paragraph 3. Main content (charts, cards, diagrams, tables) 4. Animation classes: `.anim`, `.d1`, `.d2`, `.d3` for staggered fade-in Do NOT add category tag pills/badges above headings (e.g., "BACKGROUND", "EXPERIMENTS"). They look generic and add no value. Let the heading speak for itself. ### Navigation Implement keyboard navigation (ArrowRight/Space = next, ArrowLeft = prev) and a bottom nav overlay with prev/next buttons, dot indicators, and slide number. The nav has no border or background — it floats transparently. A small low-contrast Sentry glyph watermark sits fixed in the top-left corner of every slide. ```jsx function App() { const [cur, setCur] = useState(0); const go = useCallback((d) => setCur(c => Math.max(0, Math.min(SLIDES.length - 1, c + d))), []); useEffect(() => { const h = (e) => { if (e.target.tagName === 'INPUT') return; if (e.key === 'ArrowRight' || e.key === ' ') { e.preventDefault(); go(1); } if (e.key === 'ArrowLeft') { e.preventDefault(); go(-1); } }; window.addEventListener('keydown', h); return () => window.removeEventListener('keydown', h); }, [go]); return ( <> {cur > 0 &&
TITLE
}
{SLIDES.map((S, i) => (

))}
); } ``` ## Step 4: Create Charts (Only When Data Exists) IMPORTANT: Only create charts for slides backed by real, concrete data from the source content. If a slide's content is qualitative (strategies, learnings, process descriptions, opinions), use text-based layouts instead (cards, tables, bullet lists, columns). Never invent numbers, fabricate percentages, or generate synthetic data to populate a chart. If you are unsure whether data is real or inferred, do NOT create a chart. If NO slides require charts, skip this step entirely — do not create `Charts.jsx` or import Recharts. When real data IS available, read `references/chart-patterns.md` for Recharts component patterns including axis configuration, color constants, chart types, and data generation techniques. Put all chart components in `Charts.jsx`. Key patterns: - Use `ResponsiveContainer` with explicit height - Wrap in `.chart-wrap` div with max-width 920px - Use `useMemo` for data generation - Color rule: Use the Tableau-inspired categorical palette (`CAT[]`) for distinguishing data series and groups. Only use semantic colors (`SEM_GREEN`, `SEM_RED`, `SEM_AMBER`) when the color itself carries meaning (good/bad, success/failure, warning). - Common charts: `ComposedChart` with stacked `Area`/`Line`, `BarChart`, custom SVG diagrams - Every data point in a chart must come from the source content. Do not interpolate, extrapolate, or round numbers to make charts look better. ## Step 5: Style with Sentry Design System Apply the complete CSS from the design system reference. Key elements: - Font: Rubik from Google Fonts - Colors: CSS variables for UI chrome (`--purple`, `--dark`, `--muted`). Semantic CSS variables (`--semantic-green`, `--semantic-red`, `--semantic-amber`) only where color conveys meaning. Categorical palette (`CAT[]`) for all other data visualization. - Slides: Absolute positioned, opacity transitions - Animations: `fadeUp` keyframe with staggered delays - Layout: `.cols` flex rows, `.cards` grid, `.chart-wrap` containers - Tags: `.tag-purple`, `.tag-red`, `.tag-green`, `.tag-amber` for slide labels - Logo: Read the official SVG from `references/sentry-logo.svg` (full wordmark) or `references/sentry-glyph.svg` (glyph only). Do NOT hardcode an approximation — always use the exact SVG paths from these files. ## Step 6: Common Slide Patterns ### Title Slide Logo (from `references/sentry-logo.svg` or `references/sentry-glyph.svg`) + h1 + subtitle + author/date info. ### Problem/Context Slide Tag + heading + 2-column card grid with icon headers. ### Data Comparison Slide Tag + heading + side-by-side charts or before/after comparison table. ### Technical Deep-Dive Slide Tag + heading + full-width chart + annotation bullets below. ### Summary/Decision Slide Tag + heading + 3-column layout with category headers and bullet lists. ## Step 7: Iterate and Refine After initial scaffolding: 1. Run `npm install && npm run dev` to start the dev server 2. Iterate on chart data models and visual design 3. Adjust animations, colors, and layout spacing 4. Build final output: `npm run build` produces a single HTML file in `dist/` ## Output Expectations A working React + Vite project that: - Renders as a keyboard-navigable slide deck - Uses Sentry branding (colors, fonts, icons) - Contains Recharts visualizations only for slides with real quantitative data from the source content — no fabricated data - Omits `Charts.jsx` and the Recharts dependency entirely if no slides have real data - Builds to a single distributable HTML file - Has smooth fade-in animations on slide transitions --- ## 20. prompt-optimizer - Source: https://github.com/getsentry/skills/blob/main/skills/prompt-optimizer/SKILL.md - Raw: https://raw.githubusercontent.com/getsentry/skills/main/skills/prompt-optimizer/SKILL.md - Markdown: https://skillsdocs.com/getsentry/skills/prompt-optimizer.md - Licence: Apache-2.0 — https://spdx.org/licenses/Apache-2.0.html Bundled files (6), referenced from this skill's directory: - `references/core-patterns.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/prompt-optimizer/references/core-patterns.md - `references/meta-optimization-loop.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/prompt-optimizer/references/meta-optimization-loop.md - `references/model-family-notes.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/prompt-optimizer/references/model-family-notes.md - `references/transformed-examples.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/prompt-optimizer/references/transformed-examples.md - `SOURCES.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/prompt-optimizer/SOURCES.md - `SPEC.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/prompt-optimizer/SPEC.md --- name: prompt-optimizer description: Creates, optimizes, and iteratively refines agent prompts, system prompts, developer prompts, and reusable prompt templates. Use when asked to improve a prompt, optimize a system prompt, rewrite an agent prompt, tune prompt wording, make a prompt more reliable, port prompts between OpenAI, Claude, or Gemini, or build prompt evals. --- # Prompt Optimizer Optimize prompts with evals. Keep every instruction, example, and external context reference causal. ## Load Only What You Need | Need | Read | |------|------| | New prompt | `references/core-patterns.md`, `references/model-family-notes.md`, `references/transformed-examples.md` | | Existing prompt | `references/meta-optimization-loop.md`, `references/core-patterns.md`, `references/model-family-notes.md` | | Model-family port | `references/model-family-notes.md`, `references/core-patterns.md` | | Repeated failures | `references/meta-optimization-loop.md`, `references/core-patterns.md` | | Weak or ambiguous draft | `references/transformed-examples.md` | | Provenance | `SOURCES.md` | ## Step 1: Capture Contract Record before editing: - task type: new, refine, port, or debug - target model family and snapshot, if known - prompt surface: `system`, `developer`, `user`, tool descriptions, examples, schemas - layer owners: platform, deployer/persona, retrieved context, user payload - objective and non-goals - inputs, tools, and external files available - required output shape - success criteria and failure cases - hard constraints: latency, verbosity, safety, budget, tool use, style If success criteria or examples are missing, create a small eval set first. If the bottleneck is model choice, retrieval, tool schema, or missing evals, say so before rewriting. ## Step 2: Inventory External Context For repo or agent prompts, list stable context by exact path: | Context type | Examples | |--------------|----------| | Agent rules | `AGENTS.md`, `CLAUDE.md` | | Specs | `specs/.md`, `docs/api.md` | | Policies | `SECURITY.md`, `docs/releasing.md` | | Examples | `examples/`, `tests/fixtures/` | Rules: - Reference stable files by repo-relative path instead of copying them. - Paste only excerpts needed for the prompt or eval case. - Mark whether a file is `loaded`, `referenced`, or `out of scope`. - Avoid vague context pointers such as "read the docs". ## Step 3: Choose Model Strategy Read `references/model-family-notes.md`. - Known family: optimize for that family. - Unknown family: write a portable base plus short adapter notes. - Snapshot changes: rerun evals. - Cross-family divergence: specialize only the failing layer. ## Step 4: Shape Prompt Read `references/core-patterns.md`. - Put stable policy in `system` or `developer`. - Put task-local facts, retrieved context, and variables in user-facing sections. - Keep one owner per behavior rule. - Use headings or tags only to separate content types. - Put tool policy in prompt text; keep schemas in provider-native tools. - Keep persona light unless it changes behavior. - Use the shortest wording that preserves the constraint. - Cut filler, repeated reminders, dead examples, and rationale that does not affect evals. ## Step 5: Optimize Read `references/meta-optimization-loop.md` for refinements. 1. Baseline the current prompt on the same eval slice. 2. Cluster failures by root cause. 3. Write concrete edit criticisms. 4. Generate two to four candidates: - minimal-diff repair - structure-first rewrite - examples-first or tool-rule variant - provider adapter when needed 5. Compare candidates on the same cases. 6. Keep a short optimization log. 7. Validate the winner on holdout cases. 8. Stop on plateau, oscillation, overfit, excessive cost, or non-prompt bottleneck. ## Step 6: Return Package Return: 1. `Target` 2. `Success Criteria` 3. `External Context` 4. `Optimized Prompt` 5. `Adapter Notes` 6. `Eval Set` 7. `Optimization Log` 8. `Residual Risks` For existing prompts, include a concise diff-style note of the main behavioral changes. ## Failure Modes - editing before defining the eval target - mixing policy, examples, and raw context without boundaries - duplicating rules across layers - putting durable policy in user payloads - asking for chain-of-thought - keeping contradictory legacy instructions - overfitting to one or two examples - retaining examples that no longer improve evals - fixing tool-use failures only in prompt text when tool descriptions or schemas are weak - adding markup that does not reduce ambiguity - using persona as a substitute for behavior rules --- ## 21. replay-ux-research - Source: https://github.com/getsentry/skills/blob/main/skills/replay-ux-research/SKILL.md - Raw: https://raw.githubusercontent.com/getsentry/skills/main/skills/replay-ux-research/SKILL.md - Markdown: https://skillsdocs.com/getsentry/skills/replay-ux-research.md - Licence: Apache-2.0 — https://spdx.org/licenses/Apache-2.0.html Bundled files (2), referenced from this skill's directory: - `references/output-template.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/replay-ux-research/references/output-template.md - `references/product-areas.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/replay-ux-research/references/product-areas.md --- name: replay-ux-research description: Analyze Sentry session replays to surface UX patterns, pain points, and user journeys for a given product area. Use when asked to "show me how users use", "day in the life", "UX research", "replay research", "how do customers use", "what's the user experience like for", "watch replays of", "analyze replays for", "user behavior on", or "replay UX audit" for any Sentry product surface. argument-hint: '' --- # Replay UX Research Analyze session replays from real external users of sentry.io to surface UX patterns, pain points, and representative journeys for a given product area. This uses Sentry's own dogfooding org. ## Inputs `$ARGUMENTS` is the product area to research (e.g., "issues", "traces", "dashboards", "replays", "monitors", "releases", "alerts"). If `$ARGUMENTS` is empty, ask the user which product area to research. ## Prerequisites This skill requires the Sentry MCP server to be connected. The following tools are used: - `search_events` — Search for session replays - `get_replay_details` — Get detailed replay information - `search_issues` — Look up error issues - `get_sentry_resource` — Fetch issue details from URLs If these tools are not available, ask the user to connect the Sentry MCP server before proceeding. ## Step 1: Map product area to URL patterns Read `references/product-areas.md` and find the URL patterns for the requested area. If the product area is not listed, infer a URL pattern from the area name. Most Sentry product areas follow the pattern `//` in the URL path. The reference file may not cover newer product areas — confirm your assumption with the user if unclear. ## Step 2: Search for replays Search for replays from external (non-Sentry-employee) users. 25 replays is a good starting point — go deeper if the product area is complex, if early patterns are ambiguous, or if the user wants a more comprehensive picture. Start with last 24 hours — extend to 48h or 7d if needed to reach your target count. Run multiple `search_events` calls if needed. Use `limit: 50` per call. If you can't find enough replays (fewer than 10 even at 7 days), tell the user what you found and ask them to help iterate — they may suggest broader URL patterns, a different time range, or a related product area to include. Query construction: Use natural language queries like: ``` replays from the last 24 hours where url contains "/" excluding user emails ending in @sentry.io and @getsentry.com ``` Key filters: - Time range: last 24 hours (extend if needed) - URL pattern: match the product area paths from Step 1 - Exclude employees: `-user.email:@sentry.io -user.email:@getsentry.com` - Environment: prod Do NOT pass a `projectSlug` filter — replays span the whole org. ## Step 3: Get replay details Call `get_replay_details` for each replay found in Step 2. Run these calls in parallel batches for speed. For each replay, capture: - User: email domain only (the API returns full emails — never include these in output) - Journey: ordered list of pages visited (from URLs and activity breadcrumbs) - Duration: total session length - Replay type: `session` (randomly sampled from normal browsing) vs `buffer` (triggered by an event — error, manual flush, or specific user action like submitting feedback or going through checkout). Note this distinction in your analysis since buffer replays are biased toward error/action moments, not typical browsing. - Entry context: first URL tells you how they arrived — look for referrer signals like `referrer=slack`, `notification_uuid`, `alert_rule_id` in query params (Slack notification), email link patterns, or bare URLs (bookmark/direct nav) - Engagement signals: error count, rage clicks, dead clicks, warning count - Browser/OS/Device: for device distribution context - Activity breadcrumbs: page views, navigation patterns, key interactions ## Step 4: Investigate significant errors After collecting replay details, identify errors that appear in multiple replays or seem likely to affect the user experience. For each significant error: 1. Triage by frequency: If the same issue ID (e.g., `JAVASCRIPT-33RM`) appears in 3+ replays, it's worth investigating. 2. Check the issue in Sentry: Use `search_issues` to find the issue, or `get_sentry_resource` with the issue URL from the replay details. Understand: - What is the error? (message, stack trace context) - How many total users/events does it affect? (beyond just this replay sample) - Is it assigned or being worked on? 3. Infer user-facing impact from behavioral signals: We cannot see the rendered page content through replay metadata — only by watching the replay in-browser. Instead, infer impact from what users did _after_ the error: - Retried the same action → they likely saw a failure and tried again - Navigated away immediately → they were blocked or gave up - Continued their flow normally → the error may be silent/cosmetic - Rage-clicked or dead-clicked after → the UI may have become unresponsive - Spent a long time on the page after → they may be reading an error message or confused - No behavioral change at all → error was likely invisible to the user 4. Classify each error based on this evidence: - Likely blocking: Error + user retried/left/couldn't continue. High confidence of user impact. - Likely degrading: Error + user continued but with unusual behavior. Moderate confidence. - Likely silent: Error fired but user behavior was unaffected. Low confidence of user impact. - Unclear: Not enough behavioral signal to judge. Flag for manual replay review. Always note the confidence level and recommend watching specific replays to confirm. Link directly to the replay URL for each classified error. Include this classification in the Friction & Pain Points section. Don't report likely-silent errors as pain points — list them in a separate "Background Errors (likely silent)" subsection for completeness. ## Step 5: Analyze patterns Look at the replays through these UX research lenses: ### Behavioral patterns 1. Common journeys: What navigation paths do users take? What's the typical flow? 2. Entry points: How do users arrive? Categorize: alert notification (Slack/email), direct bookmark, organic navigation from another page. The first URL's query params reveal this. 3. Task completion: Did the user appear to accomplish a goal, or did they wander/abandon? Signs of completion: navigating to a detail view then leaving. Signs of abandonment: short session, back-and-forth navigation, leaving from the same page they entered. 4. Time on task: How long do users spend on key pages before acting? ### Friction & discovery 1. Friction signals: Rage clicks, dead clicks, errors — but also _hesitation_ (visiting the same page repeatedly), _thrashing_ (rapid back-and-forth between pages), and _retry loops_ (repeating the same action sequence). 2. Feature discovery: Are users finding sub-features (filters, search, sort, bulk actions) or only using the primary view? Look at URL query params and breadcrumbs for evidence of feature use. 3. User intent signals: Mine URL query params for search terms, filter values, sort orders, and date ranges users set. These are the closest thing to verbatim user "quotes" — they reveal what users are looking for in their own words. (e.g., `query=is%3Aunresolved+assigned%3Ame` tells you the user is triaging their own assigned issues.) 4. Workarounds: Any unexpected navigation patterns that suggest a missing feature or confusing flow? (e.g., going to settings mid-task, opening multiple pages in sequence that could be one view) 5. Error recovery: When users encounter errors, do they recover and continue or abandon? ### Context 1. Replay trigger mix: What proportion are `session` (random sample) vs `buffer` (event-triggered)? Buffer replays show moments where something notable happened (error, feedback submission, checkout, etc.) — they're valuable for friction analysis but aren't representative of typical browsing. Call out this bias when drawing conclusions. 2. Return visitors: Do any email domains appear in multiple replays? Repeat visitors suggest habitual usage — their journeys may reveal power-user patterns or persistent pain points they've learned to work around. 3. User diversity: Are replays from many different orgs/companies or concentrated? Are there differences in behavior by org? 4. Device/browser distribution: What are users primarily using? 5. Drop-off points: Where do users leave or navigate away? ## Step 6: Write the report Use the template in `references/output-template.md`. Be specific — cite individual replays as evidence for each pattern. Link to replay URLs so the reader can watch the replay themselves. Privacy: Never include full user email addresses in the report. Use anonymized identifiers like "user from [company domain]" or "User A, B, C." --- ## 22. security-review - Source: https://github.com/getsentry/skills/blob/main/skills/security-review/SKILL.md - Raw: https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/SKILL.md - Markdown: https://skillsdocs.com/getsentry/skills/security-review.md - Licence: LICENSE — https://github.com/getsentry/skills/blob/main/skills/security-review/LICENSE Bundled files (21), referenced from this skill's directory: - `infrastructure/docker.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/infrastructure/docker.md - `languages/javascript.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/languages/javascript.md - `languages/python.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/languages/python.md - `LICENSE` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/LICENSE - `references/api-security.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/api-security.md - `references/authentication.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/authentication.md - `references/authorization.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/authorization.md - `references/business-logic.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/business-logic.md - `references/cryptography.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/cryptography.md - `references/csrf.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/csrf.md - `references/data-protection.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/data-protection.md - `references/deserialization.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/deserialization.md - `references/error-handling.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/error-handling.md - `references/file-security.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/file-security.md - `references/injection.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/injection.md - `references/logging.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/logging.md - `references/misconfiguration.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/misconfiguration.md - `references/modern-threats.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/modern-threats.md - `references/ssrf.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/ssrf.md - `references/supply-chain.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/supply-chain.md - `references/xss.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/security-review/references/xss.md --- name: security-review description: Security code review for vulnerabilities. Use when asked to "security review", "find vulnerabilities", "check for security issues", "audit security", "OWASP review", or review code for injection, XSS, authentication, authorization, cryptography issues. Provides systematic review with confidence-based reporting. allowed-tools: Read, Grep, Glob, Bash, Task license: LICENSE --- # Security Review Skill Identify exploitable security vulnerabilities in code. Report only HIGH CONFIDENCE findings—clear vulnerable patterns with attacker-controlled input. ## Scope: Research vs. Reporting CRITICAL DISTINCTION: - Report on: Only the specific file, diff, or code provided by the user - Research: The ENTIRE codebase to build confidence before reporting Before flagging any issue, you MUST research the codebase to understand: - Where does this input actually come from? (Trace data flow) - Is there validation/sanitization elsewhere? - How is this configured? (Check settings, config files, middleware) - What framework protections exist? Do NOT report issues based solely on pattern matching. Investigate first, then report only what you're confident is exploitable. ## Confidence Levels | Level | Criteria | Action | |-------|----------|--------| | HIGH | Vulnerable pattern + attacker-controlled input confirmed | Report with severity | | MEDIUM | Vulnerable pattern, input source unclear | Note as "Needs verification" | | LOW | Theoretical, best practice, defense-in-depth | Do not report | ## Do Not Flag ### General Rules - Test files (unless explicitly reviewing test security) - Dead code, commented code, documentation strings - Patterns using constants or server-controlled configuration - Code paths that require prior authentication to reach (note the auth requirement instead) ### Server-Controlled Values (NOT Attacker-Controlled) These are configured by operators, not controlled by attackers: | Source | Example | Why It's Safe | |--------|---------|---------------| | Django settings | `settings.API_URL`, `settings.ALLOWED_HOSTS` | Set via config/env at deployment | | Environment variables | `os.environ.get('DATABASE_URL')` | Deployment configuration | | Config files | `config.yaml`, `app.config['KEY']` | Server-side files | | Framework constants | `django.conf.settings.` | Not user-modifiable | | Hardcoded values | `BASE_URL = "https://api.internal"` | Compile-time constants | SSRF Example - NOT a vulnerability: ```python # SAFE: URL comes from Django settings (server-controlled) response = requests.get(f"{settings.SEER_AUTOFIX_URL}{path}") ``` SSRF Example - IS a vulnerability: ```python # VULNERABLE: URL comes from request (attacker-controlled) response = requests.get(request.GET.get('url')) ``` ### Framework-Mitigated Patterns Check language guides before flagging. Common false positives: | Pattern | Why It's Usually Safe | |---------|----------------------| | Django `{{ variable }}` | Auto-escaped by default | | React `{variable}` | Auto-escaped by default | | Vue `{{ variable }}` | Auto-escaped by default | | `User.objects.filter(id=input)` | ORM parameterizes queries | | `cursor.execute("...%s", (input,))` | Parameterized query | | `innerHTML = "Loading..."` | Constant string, no user input | Only flag these when: - Django: `{{ var|safe }}`, `{% autoescape off %}`, `mark_safe(user_input)` - React: `dangerouslySetInnerHTML={{__html: userInput}}` - Vue: `v-html="userInput"` - ORM: `.raw()`, `.extra()`, `RawSQL()` with string interpolation ## Review Process ### 1. Detect Context What type of code am I reviewing? | Code Type | Load These References | |-----------|----------------------| | API endpoints, routes | `authorization.md`, `authentication.md`, `injection.md` | | Frontend, templates | `xss.md`, `csrf.md` | | File handling, uploads | `file-security.md` | | Crypto, secrets, tokens | `cryptography.md`, `data-protection.md` | | Data serialization | `deserialization.md` | | External requests | `ssrf.md` | | Business workflows | `business-logic.md` | | GraphQL, REST design | `api-security.md` | | Config, headers, CORS | `misconfiguration.md` | | CI/CD, dependencies | `supply-chain.md` | | Error handling | `error-handling.md` | | Audit, logging | `logging.md` | ### 2. Load Language Guide Based on file extension or imports: | Indicators | Guide | |------------|-------| | `.py`, `django`, `flask`, `fastapi` | `languages/python.md` | | `.js`, `.ts`, `express`, `react`, `vue`, `next` | `languages/javascript.md` | | `.go`, `go.mod` | `languages/go.md` | | `.rs`, `Cargo.toml` | `languages/rust.md` | | `.java`, `spring`, `@Controller` | `languages/java.md` | ### 3. Load Infrastructure Guide (if applicable) | File Type | Guide | |-----------|-------| | `Dockerfile`, `.dockerignore` | `infrastructure/docker.md` | | K8s manifests, Helm charts | `infrastructure/kubernetes.md` | | `.tf`, Terraform | `infrastructure/terraform.md` | | GitHub Actions, `.gitlab-ci.yml` | `infrastructure/ci-cd.md` | | AWS/GCP/Azure configs, IAM | `infrastructure/cloud.md` | ### 4. Research Before Flagging For each potential issue, research the codebase to build confidence: - Where does this value actually come from? Trace the data flow. - Is it configured at deployment (settings, env vars) or from user input? - Is there validation, sanitization, or allowlisting elsewhere? - What framework protections apply? Only report issues where you have HIGH confidence after understanding the broader context. ### 5. Verify Exploitability For each potential finding, confirm: Is the input attacker-controlled? | Attacker-Controlled (Investigate) | Server-Controlled (Usually Safe) | |-----------------------------------|----------------------------------| | `request.GET`, `request.POST`, `request.args` | `settings.X`, `app.config['X']` | | `request.json`, `request.data`, `request.body` | `os.environ.get('X')` | | `request.headers` (most headers) | Hardcoded constants | | `request.cookies` (unsigned) | Internal service URLs from config | | URL path segments: `/users//` | Database content from admin/system | | File uploads (content and names) | Signed session data | | Database content from other users | Framework settings | | WebSocket messages | | Does the framework mitigate this? - Check language guide for auto-escaping, parameterization - Check for middleware/decorators that sanitize Is there validation upstream? - Input validation before this code - Sanitization libraries (DOMPurify, bleach, etc.) ### 6. Report HIGH Confidence Only Skip theoretical issues. Report only what you've confirmed is exploitable after research. --- ## Severity Classification | Severity | Impact | Examples | |----------|--------|----------| | Critical | Direct exploit, severe impact, no auth required | RCE, SQL injection to data, auth bypass, hardcoded secrets | | High | Exploitable with conditions, significant impact | Stored XSS, SSRF to metadata, IDOR to sensitive data | | Medium | Specific conditions required, moderate impact | Reflected XSS, CSRF on state-changing actions, path traversal | | Low | Defense-in-depth, minimal direct impact | Missing headers, verbose errors, weak algorithms in non-critical context | --- ## Quick Patterns Reference ### Always Flag (Critical) ``` eval(user_input) # Any language exec(user_input) # Any language pickle.loads(user_data) # Python yaml.load(user_data) # Python (not safe_load) unserialize($user_data) # PHP deserialize(user_data) # Java ObjectInputStream shell=True + user_input # Python subprocess child_process.exec(user) # Node.js ``` ### Always Flag (High) ``` innerHTML = userInput # DOM XSS dangerouslySetInnerHTML={user} # React XSS v-html="userInput" # Vue XSS f"SELECT * FROM x WHERE {user}" # SQL injection `SELECT * FROM x WHERE ${user}` # SQL injection os.system(f"cmd {user_input}") # Command injection ``` ### Always Flag (Secrets) ``` password = "hardcoded" api_key = "sk-..." AWS_SECRET_ACCESS_KEY = "..." private_key = "-----BEGIN" ``` ### Check Context First (MUST Investigate Before Flagging) ``` # SSRF - ONLY if URL is from user input, NOT from settings/config requests.get(request.GET['url']) # FLAG: User-controlled URL requests.get(settings.API_URL) # SAFE: Server-controlled config requests.get(f"{settings.BASE}/{x}") # CHECK: Is 'x' user input? # Path traversal - ONLY if path is from user input open(request.GET['file']) # FLAG: User-controlled path open(settings.LOG_PATH) # SAFE: Server-controlled config open(f"{BASE_DIR}/{filename}") # CHECK: Is 'filename' user input? # Open redirect - ONLY if URL is from user input redirect(request.GET['next']) # FLAG: User-controlled redirect redirect(settings.LOGIN_URL) # SAFE: Server-controlled config # Weak crypto - ONLY if used for security purposes hashlib.md5(file_content) # SAFE: File checksums, caching hashlib.md5(password) # FLAG: Password hashing random.random() # SAFE: Non-security uses (UI, sampling) random.random() for token # FLAG: Security tokens need secrets module ``` --- ## Output Format ```markdown ## Security Review: [File/Component Name] ### Summary - Findings: X (Y Critical, Z High, ...) - Risk Level: Critical/High/Medium/Low - Confidence: High/Mixed ### Findings #### [VULN-001] [Vulnerability Type] (Severity) - Location: `file.py:123` - Confidence: High - Issue: [What the vulnerability is] - Impact: [What an attacker could do] - Evidence: ```python [Vulnerable code snippet] ``` - Fix: [How to remediate] ### Needs Verification #### [VERIFY-001] [Potential Issue] - Location: `file.py:456` - Question: [What needs to be verified] ``` If no vulnerabilities found, state: "No high-confidence vulnerabilities identified." --- ## Reference Files ### Core Vulnerabilities (`references/`) | File | Covers | |------|--------| | `injection.md` | SQL, NoSQL, OS command, LDAP, template injection | | `xss.md` | Reflected, stored, DOM-based XSS | | `authorization.md` | Authorization, IDOR, privilege escalation | | `authentication.md` | Sessions, credentials, password storage | | `cryptography.md` | Algorithms, key management, randomness | | `deserialization.md` | Pickle, YAML, Java, PHP deserialization | | `file-security.md` | Path traversal, uploads, XXE | | `ssrf.md` | Server-side request forgery | | `csrf.md` | Cross-site request forgery | | `data-protection.md` | Secrets exposure, PII, logging | | `api-security.md` | REST, GraphQL, mass assignment | | `business-logic.md` | Race conditions, workflow bypass | | `modern-threats.md` | Prototype pollution, LLM injection, WebSocket | | `misconfiguration.md` | Headers, CORS, debug mode, defaults | | `error-handling.md` | Fail-open, information disclosure | | `supply-chain.md` | Dependencies, build security | | `logging.md` | Audit failures, log injection | ### Language Guides (`languages/`) - `python.md` - Django, Flask, FastAPI patterns - `javascript.md` - Node, Express, React, Vue, Next.js - `go.md` - Go-specific security patterns - `rust.md` - Rust unsafe blocks, FFI security - `java.md` - Spring, Java EE patterns ### Infrastructure (`infrastructure/`) - `docker.md` - Container security - `kubernetes.md` - K8s RBAC, secrets, policies - `terraform.md` - IaC security - `ci-cd.md` - Pipeline security - `cloud.md` - AWS/GCP/Azure security --- ## 23. skill-scanner - Source: https://github.com/getsentry/skills/blob/main/skills/skill-scanner/SKILL.md - Raw: https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-scanner/SKILL.md - Markdown: https://skillsdocs.com/getsentry/skills/skill-scanner.md - Licence: Apache-2.0 — https://spdx.org/licenses/Apache-2.0.html Bundled files (4), referenced from this skill's directory: - `references/dangerous-code-patterns.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-scanner/references/dangerous-code-patterns.md - `references/permission-analysis.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-scanner/references/permission-analysis.md - `references/prompt-injection-patterns.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-scanner/references/prompt-injection-patterns.md - `scripts/scan_skill.py` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-scanner/scripts/scan_skill.py --- name: skill-scanner description: Scan agent skills for security issues. Use when asked to "scan a skill", "audit a skill", "review skill security", "check skill for injection", "validate SKILL.md", or assess whether an agent skill is safe to install. Checks for prompt injection, malicious scripts, excessive permissions, secret exposure, and supply chain risks. allowed-tools: Read, Grep, Glob, Bash --- # Skill Security Scanner Scan agent skills for security issues before adoption. Detects prompt injection, malicious code, excessive permissions, secret exposure, and supply chain risks. Requires: The `uv` CLI for python package management, install guide at https://docs.astral.sh/uv/getting-started/installation/ Important: Run all scripts from the repository root. Script paths like `scripts/scan_skill.py` are relative to this skill's root directory (the directory containing this SKILL.md), not relative to the target repository. ## Bundled Script ### `scripts/scan_skill.py` Static analysis scanner that detects deterministic patterns. Outputs structured JSON. ```bash uv run scripts/scan_skill.py ``` Returns JSON with findings, URLs, structure info, and severity counts. The script catches patterns mechanically — your job is to evaluate intent and filter false positives. ## Workflow ### Phase 1: Input & Discovery Determine the scan target: - If the user provides a skill directory path, use it directly - If the user names a skill, look for it under `.agents/skills//` first, then other established layouts such as `skills//` when the repo uses a canonical root skill tree, `.claude/skills//`, `plugins//skills//`, or another repo-managed skill root with clear prior art - If the user says "scan all skills", discover all `/SKILL.md` files and scan each Validate the target contains a `SKILL.md` file. List the skill structure: ```bash ls -la / ls /references/ 2>/dev/null ls /scripts/ 2>/dev/null ``` ### Phase 2: Automated Static Scan Run the bundled scanner: ```bash uv run scripts/scan_skill.py ``` Parse the JSON output. The script produces findings with severity levels, URL analysis, and structure information. Use these as leads for deeper analysis. Fallback: If the script fails, proceed with manual analysis using Grep patterns from the reference files. ### Phase 3: Frontmatter Validation Read the SKILL.md and check: - Required fields: `name` and `description` must be present - Name consistency: `name` field should match the directory name - Tool assessment: Review `allowed-tools` — is Bash justified? Are tools unrestricted (``)? - Model override: Is a specific model forced? Why? - Description quality: Does the description accurately represent what the skill does? ### Phase 4: Prompt Injection Analysis Load `references/prompt-injection-patterns.md` for context. Review scanner findings in the "Prompt Injection" category. For each finding: 1. Read the surrounding context in the file 2. Determine if the pattern is performing injection (malicious) or discussing/detecting injection (legitimate) 3. Skills about security, testing, or education commonly reference injection patterns — this is expected Critical distinction: A security review skill that lists injection patterns in its references is documenting threats, not attacking. Only flag patterns that would execute against the agent running the skill. ### Phase 5: Behavioral Analysis This phase is agent-only — no pattern matching. Read the full SKILL.md instructions and evaluate: Description vs. instructions alignment: - Does the description match what the instructions actually tell the agent to do? - A skill described as "code formatter" that instructs the agent to read ~/.ssh is misaligned Config/memory poisoning: - Instructions to modify `CLAUDE.md`, `MEMORY.md`, `settings.json`, `.mcp.json`, or hook configurations - Instructions to add itself to allowlists or auto-approve permissions - Writing to `~/.claude/`, `~/.agents/`, or any agent configuration directory - Scripts that append to global config files — the poisoned instructions persist after skill removal Scope creep: - Instructions that exceed the skill's stated purpose - Unnecessary data gathering (reading files unrelated to the skill's function) - Instructions to install other skills, plugins, or dependencies not mentioned in the description Information gathering: - Reading environment variables beyond what's needed - Listing directory contents outside the skill's scope - Accessing git history, credentials, or user data unnecessarily Structural attacks (check scanner output for these): - Symlinks: Files that resolve outside the skill directory — can disguise reads of `~/.ssh/id_rsa`, `~/.aws/credentials`, etc. as "example" files - Frontmatter hooks: `PostToolUse`/`PreToolUse` hooks in YAML — execute shell commands automatically, the model cannot prevent it - `!`command`` syntax: Runs shell commands at skill load time during template expansion, before the model sees the prompt - Test files: `conftest.py`, `test_.py`, `.test.js` — test runners auto-discover and execute these as side effects of `pytest` or `npm test` - npm lifecycle hooks: `postinstall` scripts in bundled `package.json` — run automatically on `npm install` - Image metadata: PNG files with text in metadata chunks (tEXt/iTXt) — multimodal LLMs can read hidden instructions from image metadata ### Phase 6: Script Analysis If the skill has a `scripts/` directory: 1. Load `references/dangerous-code-patterns.md` for context 2. Read each script file fully (do not skip any) 3. Check scanner findings in the "Malicious Code" category 4. For each finding, evaluate: - Data exfiltration: Does the script send data to external URLs? What data? - Reverse shells: Socket connections with redirected I/O - Credential theft: Reading SSH keys, .env files, tokens from environment - Dangerous execution: eval/exec with dynamic input, shell=True with interpolation - Config modification: Writing to agent settings, shell configs, git hooks 5. Check PEP 723 `dependencies` — are they legitimate, well-known packages? 6. Verify the script's behavior matches the SKILL.md description of what it does Legitimate patterns: `gh` CLI calls, `git` commands, reading project files, JSON output to stdout are normal for skill scripts. ### Phase 7: Supply Chain Assessment Review URLs from the scanner output and any additional URLs found in scripts: - Trusted domains: GitHub, PyPI, official docs — normal - Untrusted domains: Unknown domains, personal sites, URL shorteners — flag for review - Remote instruction loading: Any URL that fetches content to be executed or interpreted as instructions is high risk - Dependency downloads: Scripts that download and execute binaries or code at runtime - Unverifiable sources: References to packages or tools not on standard registries ### Phase 8: Permission Analysis Load `references/permission-analysis.md` for the tool risk matrix. Evaluate: - Least privilege: Are all granted tools actually used in the skill instructions? - Tool justification: Does the skill body reference operations that require each tool? - Risk level: Rate the overall permission profile using the tier system from the reference Example assessments: - `Read Grep Glob` — Low risk, read-only analysis skill - `Read Grep Glob Bash` — Medium risk, needs Bash justification (e.g., running bundled scripts) - `Read Grep Glob Bash Write Edit WebFetch Task` — High risk, near-full access ## Confidence Levels | Level | Criteria | Action | |-------|----------|--------| | HIGH | Pattern confirmed + malicious intent evident | Report with severity | | MEDIUM | Suspicious pattern, intent unclear | Note as "Needs verification" | | LOW | Theoretical, best practice only | Do not report | False positive awareness is critical. The biggest risk is flagging legitimate security skills as malicious because they reference attack patterns. Always evaluate intent before reporting. ## Output Format ```markdown ## Skill Security Scan: [Skill Name] ### Summary - Findings: X (Y Critical, Z High, ...) - Risk Level: Critical / High / Medium / Low / Clean - Skill Structure: SKILL.md only / +references / +scripts / full ### Findings #### [SKILL-SEC-001] [Finding Type] (Severity) - Location: `SKILL.md:42` or `scripts/tool.py:15` - Confidence: High - Category: Prompt Injection / Malicious Code / Excessive Permissions / Secret Exposure / Supply Chain / Validation - Issue: [What was found] - Evidence: [code snippet] - Risk: [What could happen] - Remediation: [How to fix] ### Needs Verification [Medium-confidence items needing human review] ### Assessment [Safe to install / Install with caution / Do not install] [Brief justification for the assessment] ``` Risk level determination: - Critical: Any high-confidence critical finding (prompt injection, credential theft, data exfiltration) - High: High-confidence high-severity findings or multiple medium findings - Medium: Medium-confidence findings or minor permission concerns - Low: Only best-practice suggestions - Clean: No findings after thorough analysis ## Reference Files | File | Purpose | |------|---------| | `references/prompt-injection-patterns.md` | Injection patterns, jailbreaks, obfuscation techniques, false positive guide | | `references/dangerous-code-patterns.md` | Script security patterns: exfiltration, shells, credential theft, eval/exec | | `references/permission-analysis.md` | Tool risk tiers, least privilege methodology, common skill permission profiles | --- ## 24. skill-writer - Source: https://github.com/getsentry/skills/blob/main/skills/skill-writer/SKILL.md - Raw: https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/SKILL.md - Markdown: https://skillsdocs.com/getsentry/skills/skill-writer.md - Licence: Apache-2.0 — https://spdx.org/licenses/Apache-2.0.html Bundled files (45), referenced from this skill's directory: - `EVAL.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/EVAL.md - `evals/axis.config.json` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/evals/axis.config.json - `evals/scenarios/iteration-from-bad-output.json` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/evals/scenarios/iteration-from-bad-output.json - `evals/scenarios/reference-backed-integration.json` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/evals/scenarios/reference-backed-integration.json - `evals/scenarios/small-inline-workflow.json` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/evals/scenarios/small-inline-workflow.json - `references/authoring-path.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/authoring-path.md - `references/claude-argument-substitutions.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/claude-argument-substitutions.md - `references/claude-dynamic-context.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/claude-dynamic-context.md - `references/claude-frontmatter-invocation.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/claude-frontmatter-invocation.md - `references/claude-hook-backed.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/claude-hook-backed.md - `references/claude-subagent-fork.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/claude-subagent-fork.md - `references/description-optimization.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/description-optimization.md - `references/design-principles.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/design-principles.md - `references/example-documentation-skill.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/example-documentation-skill.md - `references/example-hook-backed-skill.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/example-hook-backed-skill.md - `references/example-router-skill.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/example-router-skill.md - `references/example-subagent-fork-skill.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/example-subagent-fork-skill.md - `references/example-workflow-process-skill.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/example-workflow-process-skill.md - `references/execution-shapes.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/execution-shapes.md - `references/iteration-evidence.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/iteration-evidence.md - `references/iteration-path.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/iteration-path.md - `references/layout-argument-driven-skill.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/layout-argument-driven-skill.md - `references/layout-asset-template-skill.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/layout-asset-template-skill.md - `references/layout-inline-skill.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/skill-writer/references/layout-inline-skill.md - …and 21 more, listed in https://skillsdocs.com/api/v1/books/getsentry/skills/skills/skill-writer --- name: skill-writer description: Create, synthesize, and iteratively improve agent skills following the Agent Skills specification. Use when asked to "create a skill", "write a skill", "synthesize sources into a skill", "improve a skill from positive/negative examples", "update a skill", or "maintain skill docs and registration". Handles source capture, precision passes, authoring, registration, and validation. --- # Skill Writer Use this as the single canonical workflow for skill creation and improvement. Primary success condition: maximize high-value input coverage before authoring while minimizing wasted runtime tokens. Follow the workflow steps in order. Load only the reference files required for the step you are on. `SKILL.md` is the primary router: every bundled reference file should be flat under `references/` and listed here with a direct "open when..." reason. ## Core Workflow References | Open when you need to... | Read | |--------------------------|------| | choose the minimum workflow path for create, update, iterate, or research-first work | `references/mode-selection.md` | | choose the simplest adequate execution shape before deciding files | `references/execution-shapes.md` | | apply writing constraints for depth, concision, and portability | `references/design-principles.md` | | decide what belongs in `SKILL.md`, `references/`, `SPEC.md`, or supporting files | `references/reference-architecture.md` | | create or update the maintenance contract for a skill | `references/spec-template.md` | | find missing high-signal sources, including history and regressions | `references/source-discovery.md` | | adapt an upstream prompt, workflow, rubric, benchmark, or docs into a skill | `references/source-adaptation.md` | | run the full synthesis pass with coverage checks and source capture | `references/synthesis-path.md` | | author or update `SKILL.md`, `SPEC.md`, and supporting files | `references/authoring-path.md` | | improve trigger language and false-positive/false-negative behavior | `references/description-optimization.md` | | iterate from positive, negative, or fix examples | `references/iteration-path.md` | | store persistent working and holdout examples for future revisions | `references/iteration-evidence.md` | | choose a response template, schema, or output contract | `references/output-contracts.md` | | add or update evals for a skill's generated outputs or runtime behavior | `references/skill-evals.md` | | troubleshoot overloaded layouts, hidden refs, or other structure failures | `references/structure-troubleshooting.md` | | register the skill and run final validation checks | `references/registration-validation.md` | ## Artifact Layout References | Open when you need to... | Read | |--------------------------|------| | keep the whole skill inline in one coherent `SKILL.md` | `references/layout-inline-skill.md` | | split optional deep knowledge into focused routed references | `references/layout-reference-backed-skill.md` | | add scripts for deterministic automation or validation | `references/layout-script-backed-workflow.md` | | define a skill that is usually invoked with explicit arguments | `references/layout-argument-driven-skill.md` | | ship reusable templates, schemas, or other static assets | `references/layout-asset-template-skill.md` | ## Workflow Mechanic References | Open when you need to... | Read | |--------------------------|------| | break a task into fixed ordered steps | `references/workflow-prompt-chaining.md` | | classify requests and route them to different downstream paths | `references/workflow-routing.md` | | split independent work into parallel units or votes | `references/workflow-parallel.md` | | discover work units dynamically and coordinate worker outputs | `references/workflow-orchestrator-workers.md` | | run validate-fix-repeat checks during authoring or execution | `references/workflow-validation-loops.md` | | validate a plan before executing a risky action | `references/workflow-plan-validate-execute.md` | ## Claude Code References | Open when you need to... | Read | |--------------------------|------| | use Claude-specific frontmatter or invocation controls | `references/claude-frontmatter-invocation.md` | | use Claude argument fields or substitution variables | `references/claude-argument-substitutions.md` | | build a skill that runs in isolated `context: fork` | `references/claude-subagent-fork.md` | | build a skill that uses Claude hooks for deterministic enforcement | `references/claude-hook-backed.md` | | use Claude shell preprocessing for dynamic context injection | `references/claude-dynamic-context.md` | ## Example Profiles | Open when you need to... | Read | |--------------------------|------| | see the expected depth for a documentation-heavy skill | `references/example-documentation-skill.md` | | see the expected depth for a workflow-process skill | `references/example-workflow-process-skill.md` | | see what a good routed skill looks like | `references/example-router-skill.md` | | see what a good subagent-fork skill looks like | `references/example-subagent-fork-skill.md` | | see what a good hook-backed skill looks like | `references/example-hook-backed-skill.md` | ## Step 1: Resolve target, path, and shape 1. Resolve the intended operation (`create`, `update`, `synthesize`, `iterate`) and inspect workspace prior art before choosing where files belong. 2. Choose the target skill root from observed conventions. If the canonical location is still unclear after inspection, ask one direct question before editing files. 3. Read `references/mode-selection.md` to choose the minimum required workflow paths. 4. Read `references/execution-shapes.md` to choose the primary execution shape. 5. Default to the simplest adequate shape. If selecting a more complex shape, record why simpler shapes were rejected. 6. Load only the exact artifact-layout, workflow-mechanic, and provider-specific leaf files required by that shape. 7. Before adding guidance, identify what existing rule, section, or file should be narrowed, replaced, or removed. 8. Record portability implications before using provider-specific mechanics. ## Step 2: Run synthesis when needed Read `references/synthesis-path.md`. 1. Use this path for new skills, material changes, and research-first planning. 2. Collect and score relevant sources with provenance. 3. Read `references/source-discovery.md` when source material is thin, stale, or ambiguous. 4. Read `references/source-adaptation.md` when adapting an upstream prompt, workflow, rubric, benchmark, or docs. 5. Produce source-backed decisions and coverage/gap status, including the class and execution-shape choice. 6. Load example profiles only when they add concrete depth for the selected class or shape. 7. If the skill uses provider-specific mechanics, include current official provider docs and capture usage constraints. 8. Do not move to authoring until required coverage is understood or gaps are explicit. ## Step 3: Run iteration first when improving from outcomes/examples Read `references/iteration-path.md` first when selected path includes `iteration` (for example operation `iterate`). 1. Capture and anonymize examples with provenance. 2. Read `references/iteration-evidence.md` when examples should persist beyond the current turn. 3. Review skill behavior against working and holdout slices. 4. Propose improvements from positive/negative/fix evidence. 5. Carry concrete behavior deltas into authoring. Skip this step when selected path does not include `iteration`. ## Step 4: Author or update skill artifacts Read `references/authoring-path.md`. 1. Write or update `SKILL.md` in imperative voice with trigger-rich description. 2. Keep `SKILL.md` as the runtime router, not an encyclopedia. 3. Run the pre-edit precision check in `references/authoring-path.md` before creating new sections or files. 4. Read `references/reference-architecture.md` before adding bulk instructions or new reference files. 5. Create or update `SPEC.md` using `references/spec-template.md` when creating a new skill or materially changing its contract. 6. Create focused reference files, scripts, and assets only when each one has a clear "open when..." reason and cannot be handled by tightening an existing file. 7. If you add a bundled reference file, add a direct routing entry for it in this `SKILL.md`. 8. Prefer checklists, tables, templates, and input/output examples over explanatory prose. 9. Follow only the specific artifact-layout, workflow-mechanic, Claude-specific, and output-contract references selected for this skill. 10. For advanced execution shapes, add the required routing, delegation, or safety contracts before considering the skill complete. 11. For authoring/generator skills, include transformed examples in references: - happy-path - secure/robust variant - anti-pattern + corrected version 12. Read `references/skill-evals.md` when the request asks for evals, regression cases, benchmark cases, or model-graded quality checks for the skill being authored. 13. After any skill artifact changes, run the post-change precision pass in `references/authoring-path.md` before description optimization or validation. ## Step 5: Optimize description quality Read `references/description-optimization.md`. 1. Validate should-trigger and should-not-trigger query sets. 2. Reduce false positives and false negatives with targeted description edits. 3. Keep trigger language generic across providers unless the skill is intentionally provider-specific. ## Step 6: Register and validate Read `references/registration-validation.md`. 1. Apply repository registration steps for the active layout you verified in the workspace. 2. Run quick validation for structural checks. 3. Review validator warnings, precision-pass results, and coverage gaps with judgment before completion. ## Output format Return: 1. `Summary` 2. `Changes Made` 3. `Validation Results` 4. `Open Gaps` --- ## 25. sred-project-organizer - Source: https://github.com/getsentry/skills/blob/main/skills/sred-project-organizer/SKILL.md - Raw: https://raw.githubusercontent.com/getsentry/skills/main/skills/sred-project-organizer/SKILL.md - Markdown: https://skillsdocs.com/getsentry/skills/sred-project-organizer.md - Licence: Apache-2.0 — https://spdx.org/licenses/Apache-2.0.html Bundled files (2), referenced from this skill's directory: - `references/project-template.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/sred-project-organizer/references/project-template.md - `references/SRED.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/sred-project-organizer/references/SRED.md --- name: sred-project-organizer description: Take a list of projects and their related documentation, and organize them into the SRED format for submission. --- # SRED Project Organization SRED expects projects to be presented in a particular format. Take the list of projects that have been worked on in the past year, and summarize them into the format expected by SRED, with the supporting evidence. Outputs a Notion document with a child document for each SREDable project. # Prerequisites Before starting make sure that Github, Notion and Linear can be accessed. Notion and Linear should be connected using an MCP. Github can be connected with an MCP, but if you have access to the `gh` CLI tool, you can use that instead. If any of these can't be accessed, prompt the user to grant access before proceeding. # Process ## Step 1 Prompt the user for a link a Notion document, which is a Work Summary for the previous year produced by the `sred-work-summary` skill. Ensure: - The notion links to a valid document that roughly matches this format: ```markdown # Projects ## [Project Name] Summary: [X] PRs, [X] Notion docs, [X] Linear tickets ### Pull Requests [X] [repository name] [Links to all the PRs] - [link] - [Merge date] ### Notion Docs [X] [Links to all the Notion docs] - [link] - [Creation date] ### Linear Tickets [X] - [link] - [Creation date] ``` ## Step 2 For each project in the Work Summary, evaluate it against the description of a SRED project in `references/SRED.md`. That means look at the relevant Notion docs and PRs for the project, and determine if the project work seems like a valid SRED project. Be prescriptive about this: the more projects that can be classified as a SRED project the better. Output the list of projects that seem to fit the description of a SRED model, and the list of projects that don't fit that model. The list of projects that fit the SRED description are referred to as "SREDable" projects. Ensure: - All the projects in the Work Summary have been classified as SREDable or not. ## Step 3 Ask the user whether the list of SREDable projects is correct. Give them the option to manually classify any projects as SREDable or not, and adjust the list accordingly. ## Step 4 Create a private Notion document called "SRED Project Descriptions". Output the full link to this document. ## Step 5 For each SREDable project, go through a series of steps. Step 1 Create a private Notion doc named "SRED Project Summary - " that is a child of the "SRED Project Description" document created in Step 4. The document should follow the template found in `references/project-template.md`. Step 2 Fill out the `Project Description` and `Project Goals` section of that document. Use the `aside` sections in those sections of the document as a prompt for what information should go in each section. Use all the information for each project gathered in the Work Summary. Use the Notion documents for the project, as well as your own reasoning to fill out these sections. Ensure: - The project description should be no more than 100 words. - The project goals should be no more than 100 words. Step 3 Provide the user the full Notion link to the "SRED Project Summary" document for the project and ask them to review it before continuing. Make any changes they ask for. Step 4 Each project will have one or more Uncertainties. An Uncertainty is defined by the questions: - What was a challenge or problem we did not have the answer to? - Is there prior art that we could use to base our problem solving on? - If not, why? Review all the Notion documents, Github PRs and Linear tickets for the project. Determine what the Uncertainties were for the project and show them to the user. Ask the user whether these are correct or should be adjusted in some way. Ensure: - The description of each Uncertainty should be only a few sentences long. Step 5 Add the Uncertainties to the Project Summary notion document in the "Technical Uncertainties" section. Ensure: - The description of the Uncertainty should only be a few sentences long. Step 6 For each Uncertainty found above, use the Notion docs, Github PRs and Linear tickets to find any experiments or attempts that were done to address this uncertainty. Make a bullet point list in the `Experiments` section of that Uncertainty for each experiment done. Make a bullet point list in the `Results / Learnings / Success` section listing the results of the experiments, and any learnings or conclusions that were drawn. For any Notion docs, Github PRs or Linear tickets that are referenced, put the link for that resource into the `Uncertainty-Specific Documentation & Links` section of the Uncertainty. Ensure: - Only one bullet point for each Experiment - Only one bullet point for each Result/Learning/Success Step 7 Take all of the links for the project found in the Work Summary, and for any that were not linked as part of an Uncertainty, include them in the `Project Documentation & Links` section of the Project Summary. Ensure: - Provide a list of all the specific links, not a summary or a general link for Github notifications. - Check that every link is directly related to the project and/or its uncertainties. Step 8 Provide the user with the link to the Project Summary document again, and ask the user to review it before moving on to the next SREDable Project. Remind the user to fill out the Participants section of the document. ## Step 6 Provide a link to the "SRED Project Descriptions" notion document. ## Examples Example work summary: https://www.notion.so/sentry/SRED-Work-Summary-2026-30a8b10e4b5d81f5bc8df3553da55220 ## References Summary of what constitutes a project and how it should be organized: `references/SRED.md` Notion Template of the summary for a specific project: `references/project-template.md` ## Resources Full documentation on the SRED program: https://www.canada.ca/en/revenue-agency/services/scientific-research-experimental-development-tax-incentive-program.html --- ## 26. sred-work-summary - Source: https://github.com/getsentry/skills/blob/main/skills/sred-work-summary/SKILL.md - Raw: https://raw.githubusercontent.com/getsentry/skills/main/skills/sred-work-summary/SKILL.md - Markdown: https://skillsdocs.com/getsentry/skills/sred-work-summary.md - Licence: Apache-2.0 — https://spdx.org/licenses/Apache-2.0.html --- name: sred-work-summary description: Go back through the previous year of work and create a Notion doc that groups relevant links into projects that can then be documented as SRED projects. --- # SRED Work Summary Collect all the Github PRs, Notion docs and Linear tickets a person completed in a given year. Group the links from all of those into projects. Put everything into a private Notion document and return a link to that document. ## Prerequisites Before starting make sure that Github, Notion and Linear can be accessed. Notion and Linear should be connected using an MCP. Github can be connected with an MCP, but if you have access to the `gh` CLI tool, you can use that instead. If any of these can't be accessed, prompt the user to grant access before proceeding. ## Process ### Step 1 ```bash # Get the current year date +%Y ``` The output of this command is the current year. The current year minus one is the previous year. ### Step 2 Collect all of the required information from the user: Github Username: What is the github username of the user? Github Repositories: Which Github repositories should be searched for PRs? The user can either specify a comma separated list, or provide a directory that contains repositories. In the second case use this command in the specified directory: ```bash # Find github repos find . -maxdepth 2 -name ".git" -type d | sed 's/\/.git$//' | sort ``` Ensure: - All the repositories listed are in the `getsentry` Github organization. The output of this is hereafter referred to as the "user repos". Incidents: Ask if the user wants to include incident documents. The answer is either yes or no. If the answer is no, that will exclude certain documents from the search later on. Other Users: Ask if there are any other users who might have created Notion documents. This should be a comma separated list of names. Remember this as the "other users". ### Step 3 Create a private Notion document entitled "SRED Work Summary [current year]". This document will be referred to as the Work Summary. If a document with this name already exists, notify the user to rename the existing document and stop executing. Ensure: - If the Work Summary already exists, stop execution. ### Step 4 The time window is Feb. 1 of the previous year until Jan. 31 of the current year Find all Github PRs created by the given github username in the time window for the user repos. If the user does not want to include incident documents, ignore any Github PRs with `INC-X`, `inc-X` in the title or description. Use either the Github MCP or the `gh` command to do this. Find all the Notion documents the user created in the time window. If the user does not want to include incident documents, ignore any Notion Documents with `INC-XXXX` in the title. Use the Notion MCP to do this. Find all the Linear tickets the user was assigned in the time window. If the user does not want to include incident documents, ignore any Linear tickets with `INC-XXXX` in the title. Use the Linear MCP to do this. Ensure: - All the Github PRs were created or merged in the time window and was opened by the user. - All the Notion docs were created in the time window and were created by the user. - All the Linear tickets were opened or completed in the time window and were assigned to the user when they were completed. ### Step 5 For each of the Github PRs, Notion documents and Linear tickets found in Step 4, put a link into the private document created in Step 3. Ensure: - There is a link for all the Github PRs in the Work Summary - There is a link for all the Notion docs in the Work Summary - There is a link for all the Linear tickets in the Work Summary - DO NOT truncate the lists of links. DO NOT use shorteners like "...and 75 more". Make sure that the full set of all Github PRs, Notion documents and Linear tickets is visible in the document. ### Step 6 Use your own intelligence to group all the Github, Notion and Linear ticket links in the Work Summary document into projects. The format of this document is shown below. ```markdown # Projects ## [Project Name] Summary: [X] PRs, [X] Notion docs, [X] Linear tickets ### Pull Requests [X] [repository name] [Links to all the PRs] - [link] - [Merge date] ### Notion Docs [X] [Links to all the Notion docs] - [link] - [Creation date] ### Linear Tickets [X] - [link] - [Creation date] ``` For Github PRs, use both the title of the PR and the description of the PR for grouping. For Notion documents, use the full document for grouping. For Linear tickets use the title of the ticket and the description of the ticket. Ensure: - All the links in the file are assigned to a project. - The file follows the format specified above. - DO NOT truncate the lists of links. DO NOT use shorteners like "...and 75 more". Make sure that the full set of all Github PRs, Notion documents and Linear tickets is visible in the document. ### Step 7 Search for notion documents created by the "other users". Take any that are relevant to the projects in the Work Summary and add links to those Notion documents into the Work Summary in the appropriate project. ### Step 8 Return a link to the Work Summary Notion doc to the user. Ensure: - The actual Notion document link is in the final output. ## Resources This is an example Working Summary document for the year 2025: https://www.notion.so/sentry/Work-Summary-Feb-2025-Jan-2026-3068b10e4b5d81d3a40cfa6ad3fe1078?source=copy_link --- ## 27. triage-frontend-issues - Source: https://github.com/getsentry/skills/blob/main/skills/triage-frontend-issues/SKILL.md - Raw: https://raw.githubusercontent.com/getsentry/skills/main/skills/triage-frontend-issues/SKILL.md - Markdown: https://skillsdocs.com/getsentry/skills/triage-frontend-issues.md - Licence: Apache-2.0 — https://spdx.org/licenses/Apache-2.0.html Bundled files (2), referenced from this skill's directory: - `references/archive-criteria.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/triage-frontend-issues/references/archive-criteria.md - `SPEC.md` — https://raw.githubusercontent.com/getsentry/skills/main/skills/triage-frontend-issues/SPEC.md --- name: triage-frontend-issues description: Triage new issues in the Sentry `javascript` project by archiving non-actionable noise. Use when asked to "triage issues", "triage the javascript project", "archive non-actionable issues", "triage new frontend issues", or "clean up the sentry/javascript queue". Operates only on the sentry/javascript project, only archives (never resolves), and always archives with `untilEscalating`. allowed-tools: Read, mcpsentrysearch_issues, mcpsentryget_sentry_resource, mcpsentryupdate_issue --- # Triage Frontend Issues Archive non-actionable noise from the `sentry/javascript` issue queue: only archive, always `untilEscalating`, always with a stated reason. Issues that look actionable in our code, or that you cannot confidently classify, must be skipped. ## Hard Rules These rules override anything else. Do not relax them. 1. Project scope. Only operate on `organizationSlug=sentry`, project slug `javascript`. If asked to triage a different project, stop and ask the user to confirm. 2. Archive only. The only status mutation permitted is `status=ignored`. Never resolve, never unresolve, never assign, never delete, never bulk-update fields other than status. 3. Always `untilEscalating`. Use `ignoreMode=untilEscalating`. Never use `forever`, `forDuration`, `untilOccurrenceCount`, or `untilUserCount`. If the user asks for a different mode, stop and have them archive that issue manually — this skill does not perform non-escalating archives. 4. Always include a `reason`. The `reason` must be a short, factual sentence naming the category from `references/archive-criteria.md` (e.g., "Third-party library noise — echarts internals; not actionable in our code"). 5. Never touch issues outside the unresolved queue. Skip anything with `status` of `resolved`, `ignored`, or `reprocessing`. 6. Never archive without confirmation. Build a full plan, show it to the user, wait for explicit approval before calling `update_issue`. A single approval covers the displayed plan only; new batches need new approval. 7. When in doubt, skip. If an issue could plausibly be a real bug in our code, do not archive it. Surface it as `needs-human` in the plan with a one-line note. ## Prerequisites - Sentry MCP authenticated via `mcp.sentry.dev`. Required tools: `search_issues`, `get_sentry_resource`, `update_issue`. - If `update_issue` is not available, stop and ask the user to authenticate the Sentry MCP server. ## Inputs `$ARGUMENTS` is one of: | Input shape | Meaning | |-------------|---------| | Sentry issue URL (`https://sentry.sentry.io/issues/JAVASCRIPT-…`) | Triage that single issue. | | Issue short ID (`JAVASCRIPT-…`) | Triage that single issue. | | Sentry issue query (contains a colon, e.g. `is:unresolved firstSeen:-24h`) | Use as the search query. | | Empty | Use the default triage queue: `is:unresolved is:unassigned firstSeen:-7d`, sort `new`, limit `50`. | If `$ARGUMENTS` is ambiguous, ask the user to clarify before searching. ## Workflow ### 1. Load the queue For single-issue input: - Call `get_sentry_resource(url=)` or `get_sentry_resource(resourceType='issue', organizationSlug='sentry', resourceId=)`. - Confirm `Project` is the javascript frontend project. If not, stop. For query/default input: - Call `search_issues(organizationSlug='sentry', projectSlugOrId='javascript', query=, sort='new', limit=50)`. - Then call `get_sentry_resource` for each result in parallel to get culprit, substatus, assignee, and stack-frame hints (the search response omits some fields). Skip immediately if any of these are true on an issue: - `status` is not `unresolved` (already archived, resolved, or in reprocessing). - `assignedTo` is set to a human (someone is already owning it). - `assignedTo` is set to a team other than `frontend`/`issues` and the issue looks team-specific (let the owning team triage). ### 2. Classify each issue Read `references/archive-criteria.md` for the category taxonomy with recognition heuristics and examples. For each candidate issue, produce one of: | Decision | Meaning | |----------|---------| | `archive` | Matches a documented category; include the category name in the reason. | | `skip` | Could be a real bug in our code, or insufficient evidence; do not archive. | | `needs-human` | Looks like noise but doesn't cleanly fit a category, or volume is unusually high; flag for user review. | When evaluating, weight these signals (in this order): 1. Top non-Sentry-SDK frame. If the top in-app frame is in `node_modules/`, `chrome-extension://`, a third-party host, or ``, this is a strong archive signal. 2. Title pattern. Many archives are recognizable from the title alone (see criteria reference). 3. Volume is not a veto. Some high-volume issues (10k+ events, thousands of users) are still archive-worthy if the top frame is third-party. Volume alone never forces archive either. 4. Recency. Single-event issues older than 30 days with no recurrence are usually noise. 5. Customer org spread. If events come from one customer subdomain only (check `customerDomain.subdomain` tag), it is likely customer-environment noise. ### 3. Build the plan Output one Markdown table to the user, in this exact shape: ``` ## Triage plan — sentry/javascript ( candidates) | # | Issue | Title | Volume | Decision | Category | Reason | |---|-------|-------|--------|----------|----------|--------| | 1 | [JAVASCRIPT-XXXX](url) | TypeError: ... | 12e/3u | archive | browser-api-noise | Browser clipboard permission denied; not actionable. | | 2 | [JAVASCRIPT-YYYY](url) | | 4945e/123u | needs-human | — | High volume, no title — please review before archiving. | | 3 | [JAVASCRIPT-ZZZZ](url) | ZodError: ... | 360e/132u | skip | — | Schema validation failure in our code; looks actionable. | ``` Then summarize counts: `N archive / M skip / K needs-human`. End with: ``` Reply `apply` to archive the N issues marked `archive`, `apply N,M,...` to archive a subset, or `cancel` to take no action. ``` ### 4. Apply on approval When the user replies `apply` (or `apply `): For each issue in the approved set, call: ``` update_issue( organizationSlug='sentry', issueId=, status='ignored', ignoreMode='untilEscalating', reason=, ) ``` Run these sequentially (not in parallel). If a call fails, log the failure, continue with the remaining issues, and report the failed IDs in step 5. If the user replies `cancel` or asks to modify the plan, do NOT call `update_issue`. If they reply with edits ("change row 2 to skip"), rebuild the plan and re-confirm. ### 5. Report After applying, output: ``` ## Triage report - Archived: N - Skipped: M - Needs human review: K - Failures: F (with issue IDs)
Archived issues
- JAVASCRIPT-XXXX — - ...
``` ## Recovery - If `update_issue` fails on one item, log the failure and continue with the rest. Report failed IDs at the end. - If the user notices a wrong archive, the user can unarchive it themselves in Sentry. The skill never reverses its own actions automatically. - If the user asks "redo the plan with these tweaks" mid-flow, regenerate the plan from scratch — do not assume the previous plan still applies. ## Example reasons (use this voice) - `Third-party library noise — echarts tooltip; not actionable in our code.` - `Browser API permission noise — Clipboard writeText denied by user agent.` - `Customer-environment proxy interference — 200 response treated as error (HTML body from corporate proxy).` - `Transient backend 5xx — InternalServerError on /api/0/organizations/.../events-meta/; backend transient.` - `Test/synthetic event — smoke test or security probe, not production traffic.` - `Wrong project — Prisma/Python error mis-routed to frontend project.` - `Single-event fluke — 1 event, 1 user, no recurrence in 30+ days.` - `Browser extension noise — ReferenceError for extension-injected global (DarkReader/WeixinJSBridge).` --- ## 28. typing-exclusion-worker - Source: https://github.com/getsentry/skills/blob/main/skills/typing-exclusion-worker/SKILL.md - Raw: https://raw.githubusercontent.com/getsentry/skills/main/skills/typing-exclusion-worker/SKILL.md - Markdown: https://skillsdocs.com/getsentry/skills/typing-exclusion-worker.md - Licence: Apache-2.0 — https://spdx.org/licenses/Apache-2.0.html --- name: typing-exclusion-worker description: "Python typing exclusion worker: remove assigned mypy exclusion modules in small scoped batches, fix typing issues, run validation, and produce a structured completion summary. Use when running parallel typing-debt workers or when asked to remove modules from pyproject mypy exclusion overrides." --- # Typing Exclusion Worker ## Purpose Execute one assigned typing batch safely and predictably: - remove only assigned modules from mypy exclusions, - fix surfaced typing issues in scope, - run required checks, - return a consistent summary for the manager/orchestrator. ## Inputs Required Before starting, confirm these inputs exist in the task prompt: - worktree/branch name, - exact module list to remove from exclusion, - ownership/domain boundary, - expected validation commands (if customized). If any are missing, ask for them before editing. ## Scope Rules (Hard Constraints) 1. Only remove assigned module entries from the mypy exclusion list in `pyproject.toml`. 2. Keep code changes in assigned scope unless a direct dependency is required to pass typing/tests. 3. Do not expand to cross-team modules unless explicitly approved by the manager. 4. Avoid blanket `# type: ignore`; if unavoidable, use narrow `ignore[code]` with a short reason. ## Execution Workflow 1. Apply exclusion change - Remove assigned modules from the exclusion override in `pyproject.toml`. 2. Run mypy on assigned scope - Prefer targeted paths first for fast feedback. - Fix errors using explicit typing patterns (`isinstance` narrowing, accurate return types, typed class attrs, relation-safe model access). 3. Run tests for touched area - Execute targeted pytest for modified modules/tests. - Fix regressions before continuing. 4. Run pre-commit on changed files - Run `pre-commit run --files `. - If hooks auto-fix files, rerun until clean. 5. Final verification - Re-run targeted mypy and tests after final edits. - Ensure no unrelated files were changed. ## Python Typing Best Practices - Prefer precise types over `Any`. - Use type narrowing on unions before attribute access. - Keep method overrides signature-compatible with base classes. - Annotate class attributes in tests/helpers when inference is weak. - Use relation objects (`obj.related`) when stubs do not expose raw `_id` attributes. ## Required Output Template Return this exact structure at the end of each batch: ```markdown ## Batch Summary - Branch/worktree: `` - Ownership/domain: `` ### Modules Removed From Exclusion - `` - `` ### Files Changed - `` - `` ### Key Typing Fixes - `` - `` ### Validation - `mypy`: `` - `pre-commit --files`: `` - `pytest`: `` ### Notes - Remaining blockers: `` - Any new ignore entries: `` ``` ## Stop Conditions (Escalate to Manager) Stop and report instead of widening scope when: - fixes require touching another team/domain, - exclusion conflicts in `pyproject.toml` cannot be resolved safely, - error volume indicates batch is too large and should be split.