commit
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.
When & Why to Use This Skill
This Claude skill automates the generation of standardized git commit messages following Sentry's specific conventions and the Conventional Commits specification. It helps developers maintain a professional, searchable git history by enforcing consistent types, scopes, and issue references (e.g., SENTRY, GitHub, Linear) while adhering to character limits and imperative mood requirements.
Use Cases
- Standardizing Bug Fixes: Automatically generate 'fix' commits that include the correct scope and link directly to Sentry issue IDs for better traceability.
- Documenting Breaking Changes: Formatting complex feature releases with 'BREAKING CHANGE' footers and detailed body explanations to notify team members of API shifts.
- Maintaining Clean Git History: Using the 'ref', 'chore', and 'style' types to distinguish non-functional changes from feature work, making code reviews more efficient.
- Automated Issue Linking: Streamlining project management by correctly formatting 'Fixes' or 'Refs' keywords for GitHub, Jira, or Linear in the commit footer.
| 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.
Format
<type>(<scope>): <subject>
<body>
<footer>
The header is required. Scope is optional. All lines must stay under 100 characters.
Commit Types
| Type | Purpose |
|---|---|
feat |
New feature |
fix |
Bug fix |
ref |
Refactoring (no behavior change) |
perf |
Performance improvement |
docs |
Documentation only |
test |
Test additions or corrections |
build |
Build system or dependencies |
ci |
CI configuration |
chore |
Maintenance tasks |
style |
Code formatting (no logic change) |
meta |
Repository metadata |
license |
License changes |
Subject Line Rules
- Use imperative, present tense: "Add feature" not "Added feature"
- Capitalize the first letter
- No period at the end
- Maximum 70 characters
Body Guidelines
- Explain what and why, not how
- Use imperative mood and present tense
- Include motivation for the change
- Contrast with previous behavior when relevant
Footer: Issue References
Reference issues in the footer using these patterns:
Fixes GH-1234
Fixes #1234
Fixes SENTRY-1234
Refs LINEAR-ABC-123
Fixescloses the issue when mergedRefslinks without closing
Examples
Simple fix
fix(api): Handle null response in user endpoint
The user API could return null for deleted accounts, causing a crash
in the dashboard. Add null check before accessing user properties.
Fixes SENTRY-5678
Feature with scope
feat(alerts): Add Slack thread replies for alert updates
When an alert is updated or resolved, post a reply to the original
Slack thread instead of creating a new message. This keeps related
notifications grouped together.
Refs GH-1234
Refactor
ref: Extract common validation logic to shared module
Move duplicate validation code from three endpoints into a shared
validator class. No behavior change.
Breaking change
feat(api)!: Remove deprecated v1 endpoints
Remove all v1 API endpoints that were deprecated in version 23.1.
Clients should migrate to v2 endpoints.
BREAKING CHANGE: v1 endpoints no longer available
Fixes SENTRY-9999
Revert Format
revert: feat(api): Add new endpoint
This reverts commit abc123def456.
Reason: Caused performance regression in production.
Principles
- Each commit should be a single, stable change
- Commits should be independently reviewable
- The repository should be in a working state after each commit