home / skills / zenobi-us / dotfiles / writing-git-commits

writing-git-commits skill

/ai/files/skills/devtools/writing-git-commits

This skill creates semantic git commits following Conventional Commits, improving traceability, reviews, and project history across features and fixes.

npx playbooks add skill zenobi-us/dotfiles --skill writing-git-commits

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

Files (1)
SKILL.md
3.7 KB
---
name: writing-git-commits
description: Create semantic git commits following best practices and Conventional Commits specification.
---

Create a semantic commit to accomodate user request. 

## Soft Validation

If any of these checks fail, check with the user before proceeding.

1. WARN_ON_DEFAULTBRANCH: !`[$(git branch --show-current) = $(gh repo view --json defaultBranchRef --jq .defaultBranchRef.name)] && echo 1 || echo 0` should equal 0
2. WARN_MERGECONFLICTS: !`git ls-files -u | wc -l` should equal 0
3. WARN_INVALIDBRANCHNAME: !`git branch --show-current` should match `^(feat|fix|docs|style|refactor|perf|test|chore)\/[a-z0-9\-]+$` (if not on default branch)

## Hard Validation

If any of these checks fail, fix the issue before proceeding. or Exit if human intervention is required.

1. on default branch, but it needs to be fastforwarded from remote.
2. uncommitted merge conflicts detected. Please resolve them before committing.

## Setup

1. Ensure git is installed and configured with user name and email.


## Execution Process

1. Analyse
2. Prepare
3. Commit
4. Sync


### 1. Analyse Changes

1. **Assess current state**:
   ```bash
   git status --porcelain
   git diff --stat
   git diff --cached --stat
   ```
   - Identify all modified, added, and deleted files
   - Check for any staged changes already in place
   - Note any untracked files that should be included

2. **Analyze changes by file**:
   ```bash
   git diff
   git diff --cached
   ```
   - Review the actual content of each change
   - Understand what each modification accomplishes
   - Identify related changes that belong together

### 2. Prepare Changes

1. **Group changes into logical commits**:
   - Each commit should represent ONE logical change (feature, fix, refactor, etc.)
   - Related files should be committed together
   - Avoid mixing unrelated changes in a single commit
   - Order commits logically (dependencies first, then dependents)

### 3. Commit Changes

4. **Create atomic commits**:
   For each logical group:
   ```bash
   git add <specific-files>
   git commit -m "<type>: <brief description>"
   ```

### 4. Push Process

1. determine default branch with the gh cli tool
2. fast forward the default branch from remote: ie: `git fetch origin master:master`
3. rebase the current branch onto the default branch: ie: `git rebase master`
4. push the current branch to remote: ie: `git push origin HEAD --force-with-lease`


## Guidance: Commit Message Writing

Use the `skills_superpowers_writing_git_commits` skill to guide you in writing great commit messages and body content following the Conventional Commits specification.

Otherwise:

1. Use conventional commit prefixes:
- `feat:` - New feature, functionality.
- `fix:` - Bug fix or refactoring.
- `docs:` - Documentation changes
- `style:` - Formatting, whitespace (no code change)
- `test:` - Adding or updating tests
- `chore:` - Maintenance tasks, dependencies, config

2. Commit Message format:
- 1st line: `<type>(scope): <subject>`
- Blank line
- Body: Detailed explanation of what and why (wrap at 72 chars)
  - Keep subject line under 72 characters
  - Use imperative mood ("add" not "added")
  - Be specific but concise
  - No period at the end of subject line

Examples:
- `feat: add user authentication endpoint`
- `fix(config): resolve null pointer in config parser`
- `feat(scope): extract validation logic to separate module`
- `docs(apiv2): update API documentation for v2 endpoints`
- `chore: update dependencies to latest versions`

## Content Guidelines

- Use direct, factual commit messages
- Avoid vague messages ("fix bug", "update code", "misc changes")
- No emojis unless project convention requires them
- Focus on WHAT changed and WHY (briefly)
- Group related changes even if in different files

Overview

This skill creates semantic git commits following Conventional Commits and best practices. It inspects the git working tree, validates branch and conflict status, guides splitting changes into logical commits, and prepares clear commit messages. The skill also assists with rebasing and pushing safely to the remote.

How this skill works

The skill runs lightweight validations (branch name, merge conflicts, default branch sync) and walks through an analysis → prepare → commit → sync workflow. It inspects git status, diffs (staged and unstaged), and groups related changes into atomic commits. It then generates Conventional Commit-formatted messages and provides the recommended commands to add, commit, rebase, and push.

When to use it

  • When you have multiple file changes that need logical grouping into commits
  • Before pushing a feature or fix to ensure commit messages follow Conventional Commits
  • When working on a non-default branch to validate branch naming and clean history
  • When preparing a pull request and you want clear, atomic commits
  • When resolving validation warnings before committing or syncing

Best practices

  • Run git status, git diff, and git diff --cached to fully understand changes before staging
  • Create one logical change per commit; group related files together and avoid mixing unrelated edits
  • Use Conventional Commits: type(scope): subject, then a blank line and a body wrapped at ~72 characters
  • Keep subject lines imperative, under 72 characters, and omit trailing periods
  • Validate you are not on the default branch or that the default branch is up-to-date before rebasing and pushing
  • Resolve any merge conflicts or uncommitted conflicts before creating commits

Example use cases

  • You updated config parsing across three modules — split into a refactor commit with scope and a test update commit
  • You fixed a null pointer in configuration loading — commit as fix(config): resolve null pointer in config parser
  • You added a new feature for provisioning — commit as feat(provisioning): add initial provisioning scripts and document usage
  • You adjusted formatting and linting — commit as style: apply code formatting rules and update linter config
  • You updated dependency versions and CI config — commit as chore(ci): bump dependencies and adjust CI pipeline

FAQ

What validation will stop a commit from being made?

Hard validations stop progress: if the default branch is behind remote or there are uncommitted merge conflicts. Those must be fixed before committing or syncing.

How should I name feature branches?

Use the pattern type/short-name, for example feat/new-provisioning, where type is one of feat, fix, docs, style, refactor, perf, test, chore.

Do I need the gh CLI to use this workflow?

gh is recommended to determine the repository default branch quickly, but the workflow can be followed using git fetch and inspecting remote branches if gh is not available.