home / skills / arjenschwarz / agentic-coding / commit

commit skill

/claude/skills/commit

This skill automates git commit preparation and changelog updates by inspecting changes, generating summaries, and composing detailed messages.

npx playbooks add skill arjenschwarz/agentic-coding --skill commit

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.9 KB
---
name: commit
description: Commits
---

# Commits

1. Use the command line to get an overview of the staged git changes. If no changes are staged, stage all files.
2. Determine if the changes include code files (not just documentation like .md files, comments, or config files). If code changes are present, run all formatting and test commands. If only documentation changes, skip tests and linting. If running the formatting resulted in unstaged changes to files, stage these as well. DO NOT revert code changes unless specifically asked to do so.
3. Create a concise, well-documented summary of the changes in the format as defined at keepachangelog.com, excluding any changes to the changelog file itself. Use proper formatting and be specific about the changes. Ignore the marking of tasks as complete.
4. Read the CHANGELOG.md file, if the file does not exist, create it.
5. Verify if the summary is already present in the changelog, if not add it to the top of the file.
6. Add the changelog to staged commits
7. Verify the current git branch using the git command.
8. Extract any ticket numbers from the branch, check for the below options based on what is likely.
    a. Extract the ticket number from the branch. The ticket number will be in the format ABC-123 and will be the combination of 1-5 letters or numbers, a -, and 1-5 numbers. This will be at the start of the branch name, possibly preceeded by something like feature/ or hotfix/.
    b. Check for a pure number, this would likely reflect a GitHub Issue.
9. If a ticket number was found, use this as the commit message prefix, otherwise use [feat] / [bug] / [doc] as appropriate based on any prefixes in the branchname and/or the code changes
10. Summarise the changes into a multi-line detailed commit message, prefixed with the commit message prefix and :. Do NOT include any co-authored-by information in the commit message.
11. Commit the code

Overview

This skill automates preparing, documenting, and committing code changes to a git repository. It stages changes, runs formatting and tests when appropriate, updates or creates a CHANGELOG.md entry in Keep a Changelog format, and generates a clear, ticket-aware commit message before committing. It enforces sensible rules to skip tests for documentation-only edits and keeps changelog entries deduplicated at the top of the file.

How this skill works

The skill inspects staged git changes and stages all files if nothing is staged. It detects whether changes include code files or only documentation/configuration, runs formatters and tests for code changes, and stages any formatting results. It reads or creates CHANGELOG.md, adds a concise Keep a Changelog-style entry if missing, derives a commit prefix from the branch or ticket number, composes a multi-line commit message, and performs the commit.

When to use it

  • Committing routine feature or bugfix branches with code changes
  • Making documentation-only edits where tests/linting should be skipped
  • When you want an automated changelog entry added or updated
  • Preparing commits that should reference a ticket number or issue
  • Ensuring formatting and tests run before committing code

Best practices

  • Stage only intended files before invoking the skill to avoid accidental commits
  • Keep branch names that start with ticket IDs (e.g., ABC-123) or clear prefixes (feature/, bugfix/) for accurate commit prefixes
  • Run the workflow on a clean working tree to make test results reliable
  • Review the generated changelog entry and commit message for accuracy before finalizing

Example use cases

  • Feature branch with code changes: runs formatters and tests, updates changelog, prefixes commit with ticket ID
  • Documentation-only PR: skips tests and linting, adds a changelog entry, commits with [doc] prefix
  • Hotfix branch: detects ticket or branch prefix, stages formatting results, creates a concise changelog note and commits
  • Small formatting-only change: formats, stages resulting edits, and commits with appropriate prefix

FAQ

How does it decide to run tests and linters?

If any non-documentation code files were changed, the skill runs configured formatters and test commands. If only docs or config files changed, it skips tests and linting.

How is the changelog entry framed?

It creates a concise Keep a Changelog-style entry summarizing the changes (excluding edits to the changelog itself) and inserts it at the top of CHANGELOG.md if that exact entry is not already present.