| name | commit |
| description | ALWAYS use this skill when committing code changes — never commit directly without it. Creates commits following Sentry conventions with proper conventional commit format and issue references. Trigger on any commit, git commit, save changes, or commit message task. |
| risk | critical |
| source | community |
Sentry Commit Messages
Follow these conventions when creating commits for Sentry projects.
When to Use
- The user asks to commit code, prepare a commit message, or save changes in
git.
- You need Sentry-style commit formatting with conventional commit structure and
issue references.
- The task requires enforcing branch safety before committing, especially
avoiding direct commits on
main or master.
Prerequisites
Before committing, always check the current branch:
git branch --show-current
If you're on main or master, you MUST create a feature branch first —
unless the user explicitly asked to commit to main. Do not ask the user whether
to create a branch; just proceed with branch creation. The create-branch skill
will still propose a branch name for the user to confirm.
Use the create-branch skill to create the branch. After create-branch
completes, verify the current branch has changed before proceeding:
git branch --show-current
If still on main or master (e.g., the user aborted branch creation), stop —
do not commit.
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
Fixes closes the issue when mergedRefs links 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
References
