domains / software-engineering / git-commit / commit

commit

Skill card

combined

The three copies overlap on the core task of creating a git commit, but they diverge on scope and constraints. getsentry/skills is a focused, Sentry-specific conventional-commit procedure. sickn33/agentic-awesome-skills is also Sentry-specific but adds branch-protection policy, AI attribution rules, and a broader set of examples. brycewang-stanford/Auto-Empirical-Research-Skills is a generic commit-PR-merge workflow that does not use Sentry conventions and includes PR creation and merge steps the others lack. Crowning one would hide the alternative generic workflow and the extra Sentry constraints.

Repositories

Other copies

Combined skill

---
name: commit
description: Create a git commit, optionally with Sentry-style conventional messages, and optionally continue to PR and merge.
---

# Commit

## Before Committing

1. Check the current branch:

```bash
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`.

2. Inspect the working tree:

```bash
git status --short
git diff --cached
git diff --stat
git log --oneline -5
```

Preserve unrelated staged or dirty work. Stage only the files relevant to the change. Do not use `git add -A`. Do not stage files containing secrets or local settings such as `.claude/settings.local.json`.

3. Read repository policy. If the default branch is PR-only, create an authorized topic branch and use the repository's native maintainer flow.

## Message Rules

If the repository uses Sentry-style conventional commits, use:

```text
<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.

If the repository does not use Sentry conventions, write a descriptive message that explains why the change was made, not just what was changed.

## Footers

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

## AI Attribution

Follow the repository's attribution policy. If the repository requires AI attribution, add a `Co-Authored-By` line identifying the actual agent. Do not add phrases like "Generated by AI" or "Written with Claude" in the subject, body, or anywhere else in the commit message.

## 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"
```

## Optional: Push, PR, and Merge

If the user requests a PR and merge:

1. Push the branch:

```bash
git push -u origin <branch-name>
```

2. Create a PR:

```bash
gh pr create --title "<short title>" --body "$(cat <<'EOF'
## Summary
<1-3 bullet points>

## Test plan
<checklist>
EOF
)"
```

3. Merge and clean up:

```bash
gh pr merge <pr-number> --merge --delete-branch
git checkout main
git pull
```

4. Report the PR URL and what was merged.

## Principles

- Each commit should be a single, stable, independently reviewable change.
- The repository should be in a working state after each commit.
- Direct-to-main instructions remain subordinate to server-side branch protection and required checks.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.