Sentry Skills /sentry-agents-md Source: ~/.claude/skills/sentry-agents-md/SKILL.md name: agents-md description: This skill should be used when the user asks to "create AGENTS.md", "update AGENTS.md", "maintain agent docs", "set up CLAUDE.md", or needs to keep agent instructions concise. Guides discovery of local skills and enforces minimal documentation style. Maintaining AGENTS.md AGENTS.md is the canonical agent-facing documentation. Keep it minimal—agents are capable and don't need hand-holding. File Setup Create AGENTS.md at project root Create symlink: ln -s AGENTS.md CLAUDE.md Before Writing Discover local skills to reference: find .claude/skills -name "SKILL.md" 2>/dev/null ls plugins/*/skills/*/SKILL.md 2>/dev/null Read each skill's frontmatter to understand when to reference it. Writing Rules Headers + bullets - No paragraphs Code blocks - For commands and templates Reference, don't duplicate - Point to skills: "Use db-migrate skill. See .claude/skills/db-migrate/SKILL.md " No filler - No intros, conclusions, or pleasantries Trust capabilities - Omit obvious context Required Sections Package Manager Which tool and key commands only: ## Package Manager Use **pnpm**: `pnpm install`, `pnpm dev`, `pnpm test` Commit Attribution Always include this section. Agents should use their own identity: ## Commit Attribution AI commits MUST include: Co-Authored-By: (the agent model's name and attribution byline) Example: `Co-Authored-By: Claude Sonnet 4 ` Key Conventions Project-specific patterns agents must follow. Keep brief. Local Skills Reference each discovered skill: ## Database Use `db-migrate` skill for schema changes. See `.claude/skills/db-migrate/SKILL.md` ## Testing Use `write-tests` skill. See `.claude/skills/write-tests/SKILL.md` Optional Sections Add only if truly needed: API route patterns (show template, not explanation) CLI commands (table format) File naming conventions Anti-Patterns Omit these: "Welcome to..." or "This document explains..." "You should..." or "Remember to..." Content duplicated from skills (reference instead) Obvious instructions ("run tests", "write clean code") Explanations of why (just say what) Long prose paragraphs Example Structure # Agent Instructions ## Package Manager Use **pnpm**: `pnpm install`, `pnpm dev` ## Commit Attribution AI commits MUST include: Co-Authored-By: (the agent model's name and attribution byline) ## API Routes [Template code block] ## Database Use `db-migrate` skill. See `.claude/skills/db-migrate/SKILL.md` ## Testing Use `write-tests` skill. See `.claude/skills/write-tests/SKILL.md` ## CLI | Command | Description | |---------|-------------| | `pnpm cli sync` | Sync data | /sentry-brand-guidelines Source: ~/.claude/skills/sentry-brand-guidelines/SKILL.md name: brand-guidelines description: Write copy following Sentry brand guidelines. Use when writing UI text, error messages, empty states, onboarding flows, 404 pages, documentation, marketing copy, or any user-facing content. Covers both Plain Speech (default) and Sentry Voice tones. Brand Guidelines Write user-facing copy following Sentry's brand guidelines. Tone Selection Choose the appropriate tone based on context: Use Plain Speech Use Sentry Voice Product UI (buttons, labels, forms) 404 pages Documentation Empty states Error messages Onboarding flows Settings pages Loading states Transactional emails "What's New" announcements Help text Marketing copy Default to Plain Speech unless the context specifically calls for personality. Plain Speech (Default) Plain Speech is clear, direct, and functional. Use it for most UI elements. Rules Be concise - Use the fewest words needed Be direct - Tell users what to do, not what they can do Use active voice - "Save your changes" not "Your changes will be saved" Avoid jargon - Use simple words users understand Be specific - "3 errors found" not "Some errors found" Examples Instead of Write "Click here to save your changes" "Save" "You can filter results by date" "Filter by date" "An error has occurred" "Something went wrong" "Please enter a valid email address" "Enter a valid email" "Are you sure you want to delete?" "Delete this item?" Sentry Voice Sentry Voice adds personality in appropriate moments. It's empathetic, self-aware, and occasionally snarky. Principles Empathetic snark - Direct frustration at the situation, never the user Self-aware - Acknowledge the absurdity of software Fun but functional - Personality should enhance, not obscure meaning Earned moments - Only use when users have time to appreciate it Examples 404 Pages: "This page doesn't exist. Maybe it never did. Maybe it was a dream. Either way, let's get you back on track." Empty States: "No errors yet. Enjoy this moment of peace while it lasts." Onboarding: "Let's get your first error. Don't worry, it's not as scary as it sounds." Loading States: "Crunching the numbers..." "Fetching your data..." When NOT to Use Sentry Voice Error messages (users are frustrated) Settings pages (users are focused) Documentation (users need information) Billing/payment flows (users need trust) General Rules Spelling and Grammar Use American English spelling (color, not colour) Use Title Case for headings and page titles Use Sentence case for body text, buttons, and labels Punctuation No exclamation marks in UI text (exception: celebratory moments) No periods in short UI labels or button text Use periods in complete sentences and help text No ALL CAPS except for acronyms (API, SDK, URL) Word Choices Avoid Prefer Please (omit) Sorry (be specific about the problem) Error occurred Something went wrong Invalid (explain what's wrong) Success! (describe what happened) Oops (be specific) Dash Usage Type Use Example Hyphen (-) Compound words, ranges "real-time", "1-10" En-dash (--) Ranges, relationships "2023--2024", "parent--child" Em-dash (---) Interruption, emphasis "Errors---even small ones---matter" In most UI contexts, use hyphens. Reserve en-dashes for date ranges and em-dashes for longer prose. UI Element Guidelines Buttons Use action verbs: "Save", "Delete", "Create" Be specific: "Create Project" not just "Create" Max 2-3 words when possible No periods or exclamation marks Error Messages Say what happened Say why (if helpful) Say what to do next Good: "Could not save changes. Check your connection and try again." Bad: "Error: Save failed." Empty States Explain what would normally be here Provide a clear action to populate the state Sentry Voice is appropriate here Good: "No projects yet. Create your first project to start tracking errors." Confirmation Dialogs Make the action clear in the title Explain consequences if destructive Use specific button labels ("Delete Project", not "OK") Tooltips and Help Text Keep under 2 sentences Explain the "why", not just the "what" Link to docs for complex topics Anti-Patterns Avoid these common mistakes: Robot speak: "Item has been successfully deleted" -> "Deleted" Passive voice: "Changes were saved" -> "Changes saved" Unnecessary words: "In order to" -> "To" Hedging: "This might cause..." -> "This will cause..." Double negatives: "Not unlike..." -> "Similar to..." Marketing speak in UI: "Supercharge your workflow" -> "Speed up your workflow" References Sentry Voice Guidelines Sentry Frontend Handbook /sentry-claude-settings-audit Source: ~/.claude/skills/sentry-claude-settings-audit/SKILL.md name: claude-settings-audit description: Analyze a repository to generate recommended Claude Code settings.json permissions. Use when setting up a new project, auditing existing settings, or determining which read-only bash commands to allow. Detects tech stack, build tools, and monorepo structure. Claude Settings Audit Analyze this repository and generate recommended Claude Code settings.json permissions for read-only commands. Phase 1: Detect Tech Stack Run these commands to detect the repository structure: ls -la find . -maxdepth 2 \( -name "*.toml" -o -name "*.json" -o -name "*.lock" -o -name "*.yaml" -o -name "*.yml" -o -name "Makefile" -o -name "Dockerfile" -o -name "*.tf" \) 2>/dev/null | head -50 Check for these indicator files: Category Files to Check Python pyproject.toml , setup.py , requirements.txt , Pipfile , poetry.lock , uv.lock Node.js package.json , package-lock.json , yarn.lock , pnpm-lock.yaml Go go.mod , go.sum Rust Cargo.toml , Cargo.lock Ruby Gemfile , Gemfile.lock Java pom.xml , build.gradle , build.gradle.kts Build Makefile , Dockerfile , docker-compose.yml Infra *.tf files, kubernetes/ , helm/ Monorepo lerna.json , nx.json , turbo.json , pnpm-workspace.yaml Phase 2: Detect Services Check for service integrations: Service Detection Sentry sentry-sdk in deps, @sentry/* packages, .sentryclirc , sentry.properties Linear Linear config files, .linear/ directory Read dependency files to identify frameworks: package.json → check dependencies and devDependencies pyproject.toml → check [project.dependencies] or [tool.poetry.dependencies] Gemfile → check gem names Cargo.toml → check [dependencies] Phase 3: Check Existing Settings cat .claude/settings.json 2>/dev/null || echo "No existing settings" Phase 4: Generate Recommendations Build the allow list by combining: Baseline Commands (Always Include) [ "Bash(ls:*)", "Bash(pwd:*)", "Bash(find:*)", "Bash(file:*)", "Bash(stat:*)", "Bash(wc:*)", "Bash(head:*)", "Bash(tail:*)", "Bash(cat:*)", "Bash(tree:*)", "Bash(git status:*)", "Bash(git log:*)", "Bash(git diff:*)", "Bash(git show:*)", "Bash(git branch:*)", "Bash(git remote:*)", "Bash(git tag:*)", "Bash(git stash list:*)", "Bash(git rev-parse:*)", "Bash(gh pr view:*)", "Bash(gh pr list:*)", "Bash(gh pr checks:*)", "Bash(gh pr diff:*)", "Bash(gh issue view:*)", "Bash(gh issue list:*)", "Bash(gh run view:*)", "Bash(gh run list:*)", "Bash(gh run logs:*)", "Bash(gh repo view:*)", "Bash(gh api:*)" ] Stack-Specific Commands Only include commands for tools actually detected in the project. Python (if any Python files or config detected) If Detected Add These Commands Any Python python --version , python3 --version poetry.lock poetry show , poetry env info uv.lock uv pip list , uv tree Pipfile.lock pipenv graph requirements.txt (no other lock) pip list , pip show , pip freeze Node.js (if package.json detected) If Detected Add These Commands Any Node.js node --version pnpm-lock.yaml pnpm list , pnpm why yarn.lock yarn list , yarn info , yarn why package-lock.json npm list , npm view , npm outdated TypeScript ( tsconfig.json ) tsc --version Other Languages If Detected Add These Commands go.mod go version , go list , go mod graph , go env Cargo.toml rustc --version , cargo --version , cargo tree , cargo metadata Gemfile ruby --version , bundle list , bundle show pom.xml java --version , mvn --version , mvn dependency:tree build.gradle java --version , gradle --version , gradle dependencies Build Tools If Detected Add These Commands Dockerfile docker --version , docker ps , docker images docker-compose.yml docker-compose ps , docker-compose config *.tf files terraform --version , terraform providers , terraform state list Makefile make --version , make -n Skills (for Sentry Projects) If this is a Sentry project (or sentry-skills plugin is installed), include: [ "Skill(sentry-skills:commit)", "Skill(sentry-skills:create-pr)", "Skill(sentry-skills:code-review)", "Skill(sentry-skills:find-bugs)", "Skill(sentry-skills:iterate-pr)", "Skill(sentry-skills:claude-settings-audit)", "Skill(sentry-skills:agents-md)", "Skill(sentry-skills:brand-guidelines)", "Skill(sentry-skills:doc-coauthoring)", "Skill(sentry-skills:security-review)", "Skill(sentry-skills:django-perf-review)", "Skill(sentry-skills:code-simplifier)", "Skill(sentry-skills:skill-creator)", "Skill(sentry-skills:skill-scanner)" ] WebFetch Domains Always Include (Sentry Projects) [ "WebFetch(domain:docs.sentry.io)", "WebFetch(domain:develop.sentry.dev)", "WebFetch(domain:docs.github.com)", "WebFetch(domain:cli.github.com)" ] Framework-Specific If Detected Add Domains Django docs.djangoproject.com Flask flask.palletsprojects.com FastAPI fastapi.tiangolo.com React react.dev Next.js nextjs.org Vue vuejs.org Express expressjs.com Rails guides.rubyonrails.org , api.rubyonrails.org Go pkg.go.dev Rust docs.rs , doc.rust-lang.org Docker docs.docker.com Kubernetes kubernetes.io Terraform registry.terraform.io MCP Server Suggestions MCP servers are configured in .mcp.json (not settings.json ). Check for existing config: cat .mcp.json 2>/dev/null || echo "No existing .mcp.json" Sentry MCP (if Sentry SDK detected) Add to .mcp.json (replace {org-slug} and {project-slug} with your Sentry organization and project slugs): { "mcpServers": { "sentry": { "type": "http", "url": "https://mcp.sentry.dev/mcp/{org-slug}/{project-slug}" } } } Linear MCP (if Linear usage detected) Add to .mcp.json : { "mcpServers": { "linear": { "command": "npx", "args": ["-y", "@linear/mcp-server"], "env": { "LINEAR_API_KEY": "${LINEAR_API_KEY}" } } } } Note : Never suggest GitHub MCP. Always use gh CLI commands for GitHub. Output Format Present your findings as: Summary Table - What was detected Recommended settings.json - Complete JSON ready to copy MCP Suggestions - If applicable Merge Instructions - If existing settings found Example output structure: ## Detected Tech Stack | Category | Found | | --------------- | -------------- | | Languages | Python 3.x | | Package Manager | poetry | | Frameworks | Django, Celery | | Services | Sentry | | Build Tools | Docker, Make | ## Recommended .claude/settings.json \`\`\`json { "permissions": { "allow": [ // ... grouped by category with comments ], "deny": [] } } \`\`\` ## Recommended .mcp.json (if applicable) If you use Sentry or Linear, add the MCP config to `.mcp.json`... Important Rules What to Include Only READ-ONLY commands that cannot modify state Only tools that are actually used by the project (detected via lock files) Standard system commands (ls, cat, find, etc.) The :* suffix allows any arguments to the base command What to NEVER Include Absolute paths - Never include user-specific paths like /home/user/scripts/foo or /Users/name/bin/bar Custom scripts - Never include project scripts that may have side effects (e.g., ./scripts/deploy.sh ) Alternative package managers - If the project uses pnpm, do NOT include npm/yarn commands Commands that modify state - No install, build, run, write, or delete commands Package Manager Rules Only include the package manager actually used by the project: If Detected Include Do NOT Include pnpm-lock.yaml pnpm commands npm, yarn yarn.lock yarn commands npm, pnpm package-lock.json npm commands yarn, pnpm poetry.lock poetry commands pip (unless also has requirements.txt) uv.lock uv commands pip, poetry Pipfile.lock pipenv commands pip, poetry If multiple lock files exist, include only the commands for each detected manager. /sentry-code-review Source: ~/.claude/skills/sentry-code-review/SKILL.md name: code-review description: Perform code reviews following Sentry engineering practices. Use when reviewing pull requests, examining code changes, or providing feedback on code quality. Covers security, performance, testing, and design review. Sentry Code Review Follow these guidelines when reviewing code for Sentry projects. Review Checklist Identifying Problems Look for these issues in code changes: Runtime errors : Potential exceptions, null pointer issues, out-of-bounds access Performance : Unbounded O(n²) operations, N+1 queries, unnecessary allocations Side effects : Unintended behavioral changes affecting other components Backwards compatibility : Breaking API changes without migration path ORM queries : Complex Django ORM with unexpected query performance Security vulnerabilities : Injection, XSS, access control gaps, secrets exposure Design Assessment Do component interactions make logical sense? Does the change align with existing project architecture? Are there conflicts with current requirements or goals? Test Coverage Every PR should have appropriate test coverage: Functional tests for business logic Integration tests for component interactions End-to-end tests for critical user paths Verify tests cover actual requirements and edge cases. Avoid excessive branching or looping in test code. Long-Term Impact Flag for senior engineer review when changes involve: Database schema modifications API contract changes New framework or library adoption Performance-critical code paths Security-sensitive functionality Feedback Guidelines Tone Be polite and empathetic Provide actionable suggestions, not vague criticism Phrase as questions when uncertain: "Have you considered...?" Approval Approve when only minor issues remain Don't block PRs for stylistic preferences Remember: the goal is risk reduction, not perfect code Common Patterns to Flag Python/Django # Bad: N+1 query for user in users: print(user.profile.name) # Separate query per user # Good: Prefetch related users = User.objects.prefetch_related('profile') TypeScript/React // Bad: Missing dependency in useEffect useEffect(() => { fetchData(userId); }, []); // userId not in deps // Good: Include all dependencies useEffect(() => { fetchData(userId); }, [userId]); Security # Bad: SQL injection risk cursor.execute(f"SELECT * FROM users WHERE id = {user_id}") # Good: Parameterized query cursor.execute("SELECT * FROM users WHERE id = %s", [user_id]) References Sentry Code Review Guidelines /sentry-code-simplifier Source: ~/.claude/skills/sentry-code-simplifier/SKILL.md name: code-simplifier description: Simplifies and refines code for clarity, consistency, and maintainability while preserving all functionality. Use when asked to "simplify code", "clean up code", "refactor for clarity", "improve readability", or review recently modified code for elegance. Focuses on project-specific best practices. Code Simplifier You are an expert code simplification specialist focused on enhancing code clarity, consistency, and maintainability while preserving exact functionality. Your expertise lies in applying project-specific best practices to simplify and improve code without altering its behavior. You prioritize readable, explicit code over overly compact solutions. Refinement Principles 1. Preserve Functionality Never change what the code does - only how it does it. All original features, outputs, and behaviors must remain intact. 2. Apply Project Standards Follow the established coding standards from CLAUDE.md including: Use ES modules with proper import sorting and extensions Prefer function keyword over arrow functions Use explicit return type annotations for top-level functions Follow proper React component patterns with explicit Props types Use proper error handling patterns (avoid try/catch when possible) Maintain consistent naming conventions 3. Enhance Clarity Simplify code structure by: Reducing unnecessary complexity and nesting Eliminating redundant code and abstractions Improving readability through clear variable and function names Consolidating related logic Removing unnecessary comments that describe obvious code Avoiding nested ternary operators - prefer switch statements or if/else chains for multiple conditions Choosing clarity over brevity - explicit code is often better than overly compact code 4. Maintain Balance Avoid over-simplification that could: Reduce code clarity or maintainability Create overly clever solutions that are hard to understand Combine too many concerns into single functions or components Remove helpful abstractions that improve code organization Prioritize "fewer lines" over readability (e.g., nested ternaries, dense one-liners) Make the code harder to debug or extend 5. Focus Scope Only refine code that has been recently modified or touched in the current session, unless explicitly instructed to review a broader scope. Refinement Process Identify the recently modified code sections Analyze for opportunities to improve elegance and consistency Apply project-specific best practices and coding standards Ensure all functionality remains unchanged Verify the refined code is simpler and more maintainable Document only significant changes that affect understanding Examples Before: Nested Ternaries const status = isLoading ? 'loading' : hasError ? 'error' : isComplete ? 'complete' : 'idle'; After: Clear Switch Statement function getStatus(isLoading: boolean, hasError: boolean, isComplete: boolean): string { if (isLoading) return 'loading'; if (hasError) return 'error'; if (isComplete) return 'complete'; return 'idle'; } Before: Overly Compact const result = arr.filter(x => x > 0).map(x => x * 2).reduce((a, b) => a + b, 0); After: Clear Steps const positiveNumbers = arr.filter(x => x > 0); const doubled = positiveNumbers.map(x => x * 2); const sum = doubled.reduce((a, b) => a + b, 0); Before: Redundant Abstraction function isNotEmpty(arr: unknown[]): boolean { return arr.length > 0; } if (isNotEmpty(items)) { // ... } After: Direct Check if (items.length > 0) { // ... } /sentry-commit Source: ~/.claude/skills/sentry-commit/SKILL.md name: commit description: Create commit messages following Sentry conventions. Use when committing code changes, writing commit messages, or formatting git history. Follows conventional commits with Sentry-specific issue references. Sentry Commit Messages Follow these conventions when creating commits for Sentry projects. Prerequisites Before committing, ensure you're working on a feature branch, not the main branch. # Check current branch git branch --show-current If you're on main or master , create a new branch first: # Create and switch to a new branch git checkout -b / Branch naming should follow the pattern: / where type matches the commit type (e.g., feat/add-user-auth , fix/null-pointer-error , ref/extract-validation ). Format ():