agentleFS
Sign inStart free
redai-infraredai-infra/Relax/skills/git-commit/SKILL.md

git-commit

Skill647 starsChanged 59 days agoApache-2.0View on GitHub

Creates git commits following Conventional Commits with an optional scope and explanatory bodies for non-trivial commits. Use when user wants to commit changes, create commit, save work, or stage and commit. Verifies intended staged changes and pre-commit checks before creating local commits.

We split this skill into the rules it gives an agent

15 rules. 0 are common, 10 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 123 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Treat the index as the source of truth for the commit.

    line 41
  2. Very specific:

    Do not infer commit contents from memory, git diff alone, or previous discussion.

    line 42
  3. Distinctive:

    Leave unrelated untracked files and unrelated unstaged edits alone unless the user explicitly asks to include them.

    line 43
  4. Distinctive:

    Do not use broad git add .

    line 44
  5. Distinctive:

    After pre-commit, re-check both staged and unstaged diffs.

    line 45
  6. Very specific:

    If git commit fails with .git/index.lock: Operation not permitted in a sandboxed environment, do not restage or modify files.

    line 46
  7. Very specific:

    Use a scope when it helps identify the affected area.

    line 56
  8. Distinctive:

    Multi-type commits: Use the primary type in the subject.

    line 85
  9. Very specific:

    ALWAYS: run pre-commit run --all-files --show-diff-on-failure before git commit, then git add again to stage any auto-fixed changes

    line 148
  10. Distinctive:

    ALWAYS: verify staged contents with git diff --cached --stat before committing

    line 149
  11. Distinctive:

    Prefer a kebab-case scope in parentheses when it adds useful context

    line 150
  12. Distinctive:

    ALWAYS: use present tense imperative verb for the subject

    line 151
  13. Very specific:

    ALWAYS: prefer git commit -F <tmpfile> for commits with markdown body

    line 153
  14. Distinctive:

    Prefer a concise subject without shortening it at the expense of clarity

    line 156
  15. Distinctive:

    NEVER: use generic messages ("update code", "fix bug", "changes")

    line 157

“Common” is measured: kept by at least 6 in 10 of the 123 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Git commit

Creates git commits following Conventional Commits. Read AGENTS.md for project constraints.

Recent project commits

!git log --oneline -5 2>/dev/null

Quick start

# 0. Inspect current state
git status -sb
git diff --cached --stat
git diff --stat

# 1. Stage only the intended changes
git add <files>
git diff --cached --stat

# 2. Run pre-commit checks (MUST do before committing)
pre-commit run --all-files --show-diff-on-failure
# If it fails or auto-fixes files: re-stage with git add, then re-run until clean

# 3. Re-stage intended files (pre-commit may have modified files), then verify index
git add <files>
git diff --cached --stat
git diff --stat

# 4. Create commit from the prepared message
git commit -F /tmp/commitmsg.txt

Staging discipline

  • Treat the index as the source of truth for the commit. Use git diff --cached --stat and git diff --cached --name-status before writing the message.
  • Do not infer commit contents from memory, git diff alone, or previous discussion. If git diff --stat is empty but git status -sb shows M <file>, the changes are staged.
  • Leave unrelated untracked files and unrelated unstaged edits alone unless the user explicitly asks to include them.
  • Do not use broad git add . when unrelated untracked files exist. Stage explicit paths.
  • After pre-commit, re-check both staged and unstaged diffs. If hooks changed files, stage only the intended paths and rerun pre-commit until clean.
  • If git commit fails with .git/index.lock: Operation not permitted in a sandboxed environment, do not restage or modify files. Rerun only git commit -F /tmp/commitmsg.txt with the required sandbox escalation, then remove the temp file after success.

Commit message structure

1. Subject line (first line)

<type>[optional scope]: <description>

Use a scope when it helps identify the affected area. Both fix: handle empty batches and fix(rollout): handle empty batches are valid. Prefer a concise, imperative subject; about 50 characters is a writing guideline, not a hard limit. Use the same format for PR titles, which become squash commit subjects.

Project types are feat, fix, docs, style, perf, refactor, test, ci, build, and chore.

2. Blank line

Separate the subject from an optional body or footer with a blank line.

3. Body for non-trivial commits

Include a body for non-trivial commits to explain the motivation, design choices, or validation. Plain paragraphs or bullet points are sufficient. Prefer Markdown headings when they help organize a longer body; emoji are optional formatting examples.

Choose optional emoji headings using Gitmoji meanings. The table gives examples: 🎨 for formatting, 👷 for CI, 🔧 for configuration, and 📦️ for package changes; dependency upgrades can use ⬆️.

Optional type-to-emoji examples:

TypeEmojiHeading Format
feat✨# ✨ Feature
fix🐛# 🐛 Bug Fix
refactor♻️# ♻️ Refactor
perf⚡️# ⚡️ Performance
test✅# ✅ Tests
docs📝# 📝 Documentation
ci👷# 👷 CI/CD
chore🔧# 🔧 Chore
style🎨# 🎨 Style
build📦️# 📦️ Build

Multi-type commits: Use the primary type in the subject. A longer body can group related details by change type.

Multi-type body example:

# 🐛 Bug Fix

## Fix token expiration check

- Fix token expiration check that always returned false

---

# ♻️ Refactor

## Simplify validation logic

- Refactor auth middleware to use early return pattern

---

# ✅ Tests

## Add auth unit tests

- Add unit tests for edge cases
- Test token refresh flow

Single-type body example:

# ✨ Feature

## Add user endpoints

- Implement GET /users/{id} endpoint
- Add POST /users for creating new users
- Include input validation middleware

Full example

printf 'feat(skills): add code-review skill with checklists

# ✨ Feature

## Add code-review skill with reference documentation

- SOLID principles checklist
- Python/ML best practices
- Security review guidelines
' > /tmp/commitmsg.txt
git commit -F /tmp/commitmsg.txt
rm /tmp/commitmsg.txt

Note: HEREDOC with git commit -m can fail with emoji/unicode. Prefer printf ... > /tmp/commitmsg.txt, git commit -F /tmp/commitmsg.txt, and rm /tmp/commitmsg.txt as separate commands so failures are easy to recover from.

Important rules

  • ALWAYS run pre-commit run --all-files --show-diff-on-failure before git commit, then git add again to stage any auto-fixed changes
  • ALWAYS verify staged contents with git diff --cached --stat before committing
  • Prefer a kebab-case scope in parentheses when it adds useful context
  • ALWAYS use present tense imperative verb for the subject
  • Include a body for non-trivial commits; prefer Markdown headings when they improve readability
  • ALWAYS prefer git commit -F <tmpfile> for commits with markdown body
  • NEVER stage unrelated untracked files or unstaged edits while creating a commit
  • NEVER end subject with a period
  • Prefer a concise subject without shortening it at the expense of clarity
  • NEVER use generic messages ("update code", "fix bug", "changes")
  • By default, only create local commits. When the user authorizes pushing or creating a PR, follow Relax GitHub workflow for publication.

Download now (ZIP)

  • Other versions161 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 161

    1. github/awesome-copilot★ 41ksame name
    2. doocs/leetcode★ 37ksame name
    3. tisfeng/Easydict★ 15ksame name
    4. doocs/md★ 13ksame name
    5. spinabot/brigade★ 11ksame name
    6. GitTools/GitVersion★ 3.1ksame name
    7. igorescodro/alkaa★ 1.6ksame name
    8. microsoft/hve-core★ 1.6ksame name
    9. rohaquinlop/complexipy★ 890same name
    10. decebals/claude-code-java★ 763same name

    151 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use git-pr, github-pr-create and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • klauswgSkill

      git-pr

      Prepare, review, publish, or update a complete GitHub pull request for the current repository, including local commit readiness, safe push strategy, semantic title validation, repository-native PR templates, issue linking, and checks verification. Use when the user asks to draft, create, submit, publish, open, or update a pull request. Always require the user to review and explicitly approve the exact final PR before any push or GitHub write.

      Also in 8 projects that use this

    • mjun0812Skill

      github-pr-create

      Pull Requestを作成するSkill。現在のbranchからpull requestを作成する。言語指定可能。 ユーザーが「PR作って」「pull request作成して」のように依頼したら使うこと。

      Also in 3 projects that use this

    • MicrosoftSkill

      git-branch

      Branch management for implementation. Use when you need to create a branch, switch branches, checkout, or verify branching strategy before implementing code. Do not use for commits (use git-commit), pull requests (use pull-request), or advanced git operations (rebase, merge).

      Also in 4 projects that use this

    • klauswgSkill

      git-issue

      Prepare, review, create, or update evidence-based GitHub issues for the current repository with duplicate detection, repository-native templates, valid labels, and post-publication verification. Use when the user asks to draft, file, submit, publish, edit, or refine a GitHub issue, bug report, feature request, performance issue, or technical proposal. Always require the user to review and explicitly approve the exact final issue before any GitHub write.

      Also in 3 projects that use this

    • MicrosoftSkill

      git-merge

      Integrate branches with merge or rebase, resolve conflicts, and execute an ordinary push when explicitly authorized. Use for guided integration with optional conflict-review pauses.

      Also in 3 projects that use this

    • gologo13Skill

      git-push

      Push current branch to origin and sync with remote updates; keywords: git, rebase. Use only on explicit request; before execution, review diffs and list impact scope.

      Also in 4 projects that use this

  • In this repository20 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free