Agent skill

commit

Use when making any git commit. All git add and commit operations must go through this skill, including from subagents and other skills. Always pass a brief description of what changed as the argument

Stars 113
Forks 20

Install this agent skill to your Project

npx add-skill https://github.com/vinta/hal-9000/tree/main/plugins/hal-skills/skills/commit

SKILL.md

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.

Critical Rule

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.

Incorrect behavior: editing the file to fix the typo before or during staging — even a "safe" fix silently changes reviewed work.

Workflow

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).

  1. Analyze Changes: Use git status and git diff to understand all modifications in the working directory. Categorize changes by:

    • STRUCTURAL: Code reorganization, renaming, refactoring without behavior changes
    • BEHAVIORAL: New features, bug fixes, functionality changes
    • DOCUMENTATION: README updates, comment changes, documentation files
    • CONFIGURATION: Build files, dependencies, environment settings
  2. Group Logically: Organize changes into logical units where each unit:

    • Addresses a single purpose or problem
    • Structure changes to be atomic and easily revertable for safe rollback
    • Would make sense to revert as a unit
  3. Stage Changes: Use appropriate staging strategy:

    • Whole file: git add <file>
    • Hunk-by-hunk: 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.diff
    • To unstage, use git restore --staged (not git reset --hard, which discards work)
    • Fallback: If git apply --cached fails (malformed patch), stage the whole file with git add <file> instead
  4. Handle Pre-commit Hooks: If hooks complain about unstaged changes:

    • Stash unstaged changes first: git stash push -p -m "temp: unstaged changes" (select hunks to stash)
    • Or stash all unstaged: git stash push --keep-index -m "temp: unstaged changes"
    • Commit, then restore: git stash pop
    • If hooks modify staged files (auto-formatting), re-add the modified files and retry the commit
  5. Create Atomic Commits: For each logical group:

    • Conventional commit format. Subject: what changed (≤72 chars). If the subject is self-explanatory, skip the body.
    • Commit the working tree state as-is — the user may have made manual edits outside this conversation
    • Use git commit -m "message" directly — never use $() or heredoc subshells in git commands, as they break allowed-tools pattern matching

Attribution

Include 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.

Gotchas

  • Never modify working tree files. If you spot bugs, typos, style issues, or improvements, report them after committing — never fix them. Your only job is staging and writing the commit message.
  • Don't commit plan or spec docs unless the user explicitly asked you to. Files under 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.
  • No $() 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.
  • Pre-commit hooks that auto-format staged files cause loops. The hook modifies the file, which un-stages the formatted version. Fix: re-add the modified files and retry the commit once. Don't retry indefinitely.
  • Never git reset --hard to unstage. It destroys working tree changes. Use git restore --staged to unstage without losing anything.
  • Stash before commit if hooks complain about unstaged changes. Use git stash push --keep-index to isolate unstaged work, commit, then git stash pop. Forgetting the pop leaves work stranded in the stash.
  • Unstaged changes are still changes. 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."

Expand your agent's capabilities with these related and highly-rated skills.

vinta/hal-9000

bump-plugin-version

(project) Use when editing any file under plugins/hal-skills/ or plugins/hal-voice/ to bump the plugin version before committing

113 20
Explore
vinta/hal-9000

update-allowed-tools

Use when creating or editing a skill that uses Bash commands, external tools, or skill invocations and the allowed-tools frontmatter may be incomplete

113 20
Explore
vinta/hal-9000

second-opinions

Use when wanting independent perspectives from external models (Codex, Gemini) on code, plans, docs, or any task — or when the user asks for a second opinion, codex review, or gemini review

113 20
Explore
vinta/hal-9000

magi

Use when brainstorming ideas, features, or directions for a project where independent perspectives from different model families (Claude/Codex/Gemini) would surface blind spots and spark creative options the user hasn't considered — especially "what cool things can I add", "what should I build next", "give me ideas for X"

113 20
Explore
davila7/claude-code-templates

verl-rl-training

Provides guidance for training LLMs with reinforcement learning using verl (Volcano Engine RL). Use when implementing RLHF, GRPO, PPO, or other RL algorithms for LLM post-training at scale with flexible infrastructure backends.

23,776 2,298
Explore
davila7/claude-code-templates

openrlhf-training

High-performance RLHF framework with Ray+vLLM acceleration. Use for PPO, GRPO, RLOO, DPO training of large models (7B-70B+). Built on Ray, vLLM, ZeRO-3. 2× faster than DeepSpeedChat with distributed architecture and GPU resource sharing.

23,776 2,298
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results