Commit Changes

SkillDev tools

Create a commit following COMMIT_GUIDELINES.md

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Commit Changes skill

What this skill tells your AI

The instructions your AI receives, as published by gittower/git-flow-next in .claude/skills/commit/SKILL.md and read by ahel’s review.

Create a well-formatted commit following the project's COMMIT_GUIDELINES.md.

Instructions

  1. Read COMMIT_GUIDELINES.md for all formatting rules, commit types, and conventions

  2. Check Status

    • Run git status to see staged and unstaged changes
    • Run git diff --cached to see what will be committed
    • If nothing staged, ask user what to stage or stage all with git add -A
  3. Analyze Changes

    • Review the diff to understand what changed
    • Identify the appropriate commit type and scope per COMMIT_GUIDELINES.md
    • Choose the type based on what the change does, not what file extension it has — use the decision guide below
  4. Write Commit Message per COMMIT_GUIDELINES.md rules

  5. Create Commit using HEREDOC format for proper formatting:

    git commit -m "$(cat <<'EOF'
    <type>(<scope>): <subject>
    
    <body>
    
    <footer>
    EOF
    )"
    
  6. Verify — run git log -1 to check the message

Commit Type Decision Guide

Choose the type based on the purpose of the change, not the file type:

TypeUse when...Example
featAdding new user-facing functionalityNew CLI command, new flag, new config option
fixFixing a user-facing bugIncorrect merge behavior, wrong exit code
refactorRestructuring code without behavior changeExtract helper, rename internal function
testAdding/fixing tests (even if fixing a bug in a test)New test case, fix flaky test
docsChanging user-facing documentation contentUpdate README, manpage, ARCHITECTURE.md
ciChanging CI/CD, automation, review tooling, GitHub configWorkflows, Copilot/Claude instructions, skills, .github/ config
buildChanging build system or dependenciesgo.mod, build scripts, Makefile
styleCode formatting only, no logic changego fmt, whitespace fixes
choreMaintenance that doesn't fit aboveUpdate .gitignore, tool config

Common pitfalls

  • .md files are not always docs — a Markdown file that configures tool behavior (e.g., Copilot instructions, Claude skills, review criteria) is ci, not docs
  • fix is for user-facing bugs only — fixing a CI workflow is ci, fixing a test is test, fixing a build script is build
  • test covers test fixes too — use test: not fix: when correcting test code

Hard Wrapping Technique

When a guideline specifies a hard line wrap limit, write the text as continuous flowing prose first, then hard wrap at the specified character limit, filling each line as close to the limit as possible.

Example

git commit -m "$(cat <<'EOF'
feat(finish): Add squash merge strategy

Implements --squash flag for finish command that performs a squash merge
instead of a regular merge, creating a single commit with all branch
changes on the target branch.

- Add squash option to merge strategy enum
- Update finish command to handle squash flag
- Add configuration support for default squash behavior

Resolves #42
EOF
)"

Signals

GitHub stars
439
Forks
28
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
commit-gittower
Source
github.com/gittower/git-flow-next