commit

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