commit

Name: commit
Availability: InStock
Author: getsentry

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

view source

installs

stars

karma

view original SKILL.md from skills.shclick to expand

Sentry Commit Messages

Before Committing

git branch --show-current

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:
<type>(<scope>): <subject>

<optional body>

<optional footer>

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.

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"

don't have the plugin yet? install it then click "run inline in claude" again.

added explicit inputs section covering branch state and message components, expanded procedure with detailed step-by-step commit execution including body sanitization and footer formatting, added decision points for branch safety, type validation, character limits, pii filtering, and ai attribution, and included comprehensive output contract and outcome signal sections.

intent

use this skill every time you commit code changes to a sentry project. it enforces conventional commit format, prevents accidental commits to main/master, and ensures commit messages include proper scope, type, subject line, body explanation, and issue references. run this instead of committing directly.

inputs

git repository state:

current branch name (retrieved via git branch --show-current)
staged changes (must exist before running this skill)
git config for user.name and user.email (for commit attribution)

commit message components:

type: one of feat, fix, ref, perf, docs, test, build, ci, chore, style, meta, license
scope: optional, describes which part of codebase (e.g., api, alerts, auth)
subject: imperative mood, present tense, 1-70 characters
body: optional but recommended for non-trivial changes, explains what and why
footer: optional, issue references and co-author attribution

external context:

issue tracker references (github, sentry internal, linear, etc.)
co-author identity if this is ai-generated code (name and email)

procedure

verify branch safety: run git branch --show-current. if output is "main" or "master", proceed to step 2. otherwise skip to step 3.
- input: current branch name
- output: branch status (safe or unsafe)
create feature branch if needed: if on main or master, create a new branch via git checkout -b feature/<descriptive-name>. re-run git branch --show-current to confirm you are off main/master. if still on main or master after branch creation, stop and alert the user.
- input: none (uses current main/master state)
- output: new branch created and checked out, or error if still on main/master
validate commit type: confirm the type is one of: feat, fix, ref, perf, docs, test, build, ci, chore, style, meta, license. if not, reject and ask user to pick a valid type.
- input: type parameter
- output: validated type, or error
format subject line: take the subject and ensure it is in imperative mood, present tense, starts with capital letter, has no period, and is under 70 characters. if it exceeds 70 characters, truncate or ask user to rewrite.
- input: raw subject string
- output: formatted subject (max 70 chars)
build commit header: format as <type>(<scope>): <subject>. if scope is empty, format as <type>: <subject>. verify header is under 100 characters.
- input: type, scope (optional), subject
- output: commit header string
compose commit body (if needed): if body text is provided, format it with real line breaks (not literal \n). ensure body explains what and why, not how. check for customer/org names, user emails, support ticket contents, or pii. if found, remove or replace with technical symptom + internal ticket reference (e.g., Fixes SENTRY-1234).
- input: raw body text, list of issue references
- output: sanitized body with real line breaks
add footer references: format issue references as Fixes GH-1234, Fixes #1234, Fixes SENTRY-1234, or Refs LINEAR-ABC-123. if this is ai-generated code, add Co-Authored-By: noreply@example.com. do not add phrases like "Generated by AI" or "Written with Claude" anywhere.
- input: issue tracker references, co-author identity (if applicable)
- output: formatted footer block
execute git commit: if body and footer are provided, use multi-line -m pattern:
```
git commit -m "type(scope): subject" \
  -m "body paragraph 1.

body paragraph 2.

Footer references here"
```
if only header + footer, use single -m + footer. if only header, use git commit -m "type(scope): subject". do not embed escaped newlines like \n inside -m strings.
- input: formatted header, body, footer
- output: commit object created in git history
verify commit: run git log -1 --pretty=format:"%H %s" to confirm the commit was created and the subject line is correct.
- input: none (queries git history)
- output: commit hash and subject line, or error if commit failed

decision points

if on main or master branch: create a feature branch first (step 2). do not ask the user; just proceed. re-check after creation. if still on main/master, stop and do not commit.
if commit type is invalid: reject and ask user to select from the valid type list.
if subject exceeds 70 characters: either truncate (if safe) or ask user to rewrite.
if body contains customer/org names, user emails, pii, or support ticket contents: remove or replace with technical symptom + internal ticket reference (e.g., Fixes SENTRY-1234). do not commit with customer data exposed.
if this is ai-generated code: include Co-Authored-By footer. do not add "Generated by AI" or similar markers in subject or body.
if body text has escaped newlines (\n) instead of real line breaks: reformat using real line breaks before commit.
if multiple issues are referenced: include all in footer using Fixes or Refs patterns. use Fixes only if the commit actually closes the issue.
if scope is omitted: format header as <type>: <subject> instead of <type>(): <subject>.

output contract

successful commit output:

git commit object created in repository history
commit message follows format: <type>(<scope>): <subject> with optional body and footer
subject under 70 characters, header under 100 characters
body uses real line breaks, explains what and why
footer includes issue references (Fixes / Refs) and co-author attribution if applicable
no customer/org names, user emails, or pii in any part of the message
commit is on a non-main/non-master branch (or user explicitly approved main commit)

returned to user:

confirmation line showing git log -1 output (hash + subject)
or error message if commit failed (e.g., "still on main branch", "invalid type", "subject too long")

outcome signal

the user knows the commit succeeded when:

git log -1 --pretty=format:"%H %s" displays the correct commit hash and subject line
git status shows "nothing to commit" (staged changes were consumed by the commit)
git branch --show-current shows a non-main/non-master branch
the commit message is visible in the repo history with proper type, scope, subject, body, and footer formatting

if any step fails (e.g., invalid type, still on main after branch creation, body contains pii), the skill stops with an error message describing what went wrong and what to fix.