commit

name	commit
description	Create git commits for dotfiles changes, grouping by component with conventional prefix style

When the user asks you to commit changes in this dotfiles repo, follow these steps:

Important Context

• This is a stow-based dotfiles repo using git (not jj)
• Changes are organized by component directories: emacs/, zsh/, home-manager/, scripts/, etc.
• Commits follow the format: [component] brief description
• Each component's changes should be a separate commit
• Do NOT add Co-Authored-By lines unless the user asks for it

Steps

1. Understand Current State

Run these in parallel:

git status
git diff --staged
git diff
git log --oneline -10

2. Group Changes by Component

• Look at modified file paths and group them by their top-level directory (e.g. emacs/, zsh/, home-manager/)
• Files in the same component that are part of the same logical change go in one commit
• If a component has unrelated changes, split into separate commits

3. Draft Commit Messages

For each group, draft a message following the existing style:

• Format: [component] brief-area: what changed
• Examples from this repo:
  • [emacs] fix dired block brackets
  • [zsh] tweak how reporoot and gitroot is set
  • [scripts] ,markdown-to-pdf: use gfm input format and fix parameter handling
  • [home-manager] add emacs-lsp-booster package
• Use a sub-area (e.g. utils:, web:) when it clarifies which part of the component changed
• Keep the first line short and lowercase
• Add a detailed body (separated by blank line) when the reasoning behind the change is not obvious from the diff

4. Create Commits

For each group, stage the relevant files and commit:

git add <specific-files> && git commit -m "$(cat <<'EOF'
[component] brief description

Optional detailed explanation of why this change was made,
if not obvious from the diff itself.
EOF
)"

• Stage specific files — never use git add -A or git add .
• Issue all git add && git commit calls as parallel tool calls in a single response so the user can approve them all at once

5. Verify and Report

Run git log --oneline -5 to confirm all commits were created, then show the output to the user.

Guidelines

• Do NOT push unless explicitly requested
• Do NOT commit files containing secrets
• If the user has both staged and unstaged changes, ask which to include
• Prefer fewer commits when changes are closely related within a component
• Skip claude/.claude/settings.json model changes — the "model" field changes frequently and is not worth tracking; omit it from commits unless other meaningful settings changed alongside it
• Scope commits to what the user named — if the user says "commit the gptel changes", stage and commit only that file; don't expand to other changed files unless asked