Commit

by getsentryd18b7aa8ba87No license1K starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 5 days ago

Use for every request to commit changes or draft a commit message. Creates Sentry-style conventional commits with issue references.

Instructions onlySoftware Development

AI-generated overview

Guides the agent in drafting Sentry-style conventional commit messages and creating git commits safely.

What it does: This skill provides instructions for preparing and creating git commits. It tells the agent to check the current branch and avoid committing directly to main or master, to keep each commit to one coherent change, and to write messages in a conventional format with type, optional scope, subject, body and footers. It defines allowed types, subject and line-length rules, issue-reference footers such as Fixes and Refs, and privacy rules that exclude customer names, emails, ticket contents, secrets and PII. It also specifies using separate -m arguments rather than literal newline sequences or an interactive editor.
When to use it: Use it whenever a request involves committing changes or drafting a commit message. It fits workflows where commits should follow a conventional, Sentry-style format with issue references and where direct commits to main or master should be avoided.
Requirements: Requires a git repository and the ability to run git commands such as git branch --show-current and git commit. No scripts, packages, credentials or network access are included beyond git itself.

Sentry Commit Messages

Before Committing

If the branch is main or master, create a feature branch unless the user explicitly requested a direct commit. Re-check the branch and stop if it is still main or master.

Commit one coherent, independently reviewable change at a time.

Message Rules

Use:

Scope is optional. Add ! before : for a breaking change.
Write the subject in imperative, present tense; capitalize it, omit the trailing period, and keep it at 70 characters or fewer.
Keep every line under 100 characters.
Use the body only when useful. Explain what changed and why, including previous behavior or motivation when it helps.
Never include customer or organization names, user emails, support ticket contents, secrets, or PII. Describe the technical symptom instead.

Allowed types: feat, fix, ref, perf, docs, test, build, ci, chore, style, meta, license, and revert.

Use ref for refactoring without behavior changes, style for formatting without logic changes, and meta for repository metadata.

Footers

Fixes <issue> closes an issue when merged.
Refs <issue> links an issue without closing it.
For breaking changes, add BREAKING CHANGE: <impact>.

Creating the Commit

Use separate -m arguments for paragraphs and footers. Never put literal \n sequences in a commit message or open an interactive editor.

bash

git commit -m "fix(api): Handle null response in user endpoint" \  -m "Return 404 when the user API finds a deleted account." \  -m "Fixes SENTRY-5678"

git commit -m "fix(api): Handle null response in user endpoint" \  -m "Return 404 when the user API finds a deleted account." \  -m "Fixes SENTRY-5678"

Source and attribution

Source:getsentry/skillsinskills/commitat commitd18b7aa

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

Commit

Sentry Commit Messages

Before Committing

Message Rules

Footers

Creating the Commit

Source and attribution

More from getsentry/skills

Typing Exclusion Worker

Triage Frontend Issues

Sred Work Summary

Sred Project Organizer

Presentation Creator

Pr Writer

More in Software Development

Playground

M5 Onboard

Cardputer Buddy

Dpop Adoption

Gemini Live Api

Gemini Api