From hal-skills
Stages and commits git changes atomically with conventional messages. Analyzes status and diffs, groups into logical units (structural, behavioral, docs, config) without modifying code.
npx claudepluginhub vinta/hal-9000 --plugin hal-skillsThis skill is limited to using the following tools:
Commit all changes in the working tree. Run `git status` and `git diff`, then stage and commit with conventional commit messages. One logical change per commit.
Stages all changes, analyzes git diff to generate conventional commit message (feat, fix, etc.), and creates commit. Handles pre-commit hooks. Use when user says commit changes or save changes.
Stages intended Git changes, avoiding secrets, and commits with clear Conventional Commit messages. Use when work is ready and diff is understood.
Creates local Git commits with conventional messages and GitHub issue references. Handles staging, pre-commit hooks, and automatic issue detection from changes.
Share bugs, ideas, or general feedback.
Commit all changes in the working tree. Run git status and git diff, then stage and commit with conventional commit messages. One logical change per commit.
You are a committer, not a coder. The user or another agent wrote this code deliberately — modifying it during the commit would silently alter reviewed work without the author's knowledge.
Your only job: stage the exact working tree state and write a commit message that captures why the change was made.
You see a typo in a variable name while reviewing the diff. Correct behavior: 1. Stage and commit the file as-is 2. After committing, say: "I noticed `reuslt` appears to be a typo for `result` in utils.py:42"Incorrect behavior: editing the file to fix the typo before or during staging — even a "safe" fix silently changes reviewed work.
cd to the project root before git commands instead of using git -C, which obscures working directory state. Execute git commands directly without explanatory preamble. Commit immediately without confirmation prompts (interactive mode is not supported).
Analyze Changes: Use git status and git diff to understand all modifications in the working directory. Categorize changes by:
Group Logically: Organize changes into logical units where each unit:
Stage Changes: Use appropriate staging strategy:
git add <file>git diff <file> > /tmp/${CLAUDE_SESSION_ID}-patch.diff, edit the patch to keep only specific hunks, then git apply --cached /tmp/${CLAUDE_SESSION_ID}-patch.diffgit restore --staged (not git reset --hard, which discards work)git apply --cached fails (malformed patch), stage the whole file with git add <file> insteadHandle Pre-commit Hooks: If hooks complain about unstaged changes:
git stash push -p -m "temp: unstaged changes" (select hunks to stash)git stash push --keep-index -m "temp: unstaged changes"git stash popCreate Atomic Commits: For each logical group:
git commit -m "message" directly — never use $() or heredoc subshells in git commands, as they break allowed-tools pattern matchingInclude a Co-Authored-By footer in every commit message:
If you're an Anthropic Claude model:
Co-Authored-By: Claude <noreply@anthropic.com>
If you're a Google Gemini model:
Co-Authored-By: Gemini <gemini-code-assistant@google.com>
Skip if you're not one of the above models.
plans/, specs/, or similar directories are working documents — staging them silently pollutes the commit with artifacts the user may not want tracked.git apply --cached fails on malformed patches. Hunks extracted manually often have broken headers or trailing whitespace. Fallback: stage the whole file with git add instead of retrying the patch.$() or heredoc subshells in git commit -m. The allowed-tools pattern matching treats the entire command as a string — subshells produce commands that don't match any allowed pattern and get blocked.git reset --hard to unstage. It destroys working tree changes. Use git restore --staged to unstage without losing anything.git stash push --keep-index to isolate unstaged work, commit, then git stash pop. Forgetting the pop leaves work stranded in the stash.git status showing "no changes added to commit" does NOT mean the working tree is clean. It means nothing is staged yet. Your job is to stage and commit those changes, not report "nothing to commit."