skills/git-commit/SKILL.md
Use when creating Git commits.
npx skillsauth add LandonSchropp/agent-toolkit skills/git-commitInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Run git status to see what changes are staged for commit. If there are no staged changes, stage all modified files.
Create a clear, succinct title that explains what the commit accomplishes. Brief - only the essentials.
Use imperative mood: "Add feature" not "Added feature" or "Adds feature"
Good examples:
Avoid overly detailed titles and phrases like "This commit..." or "Changes to..."
MOST COMMITS SHOULD HAVE NO BODY. DO NOT ADD A BODY UNLESS ABSOLUTELY NECESSARY. A title-only commit is almost always better.
Before adding a body, ask yourself: Does this body add information that isn't obvious from the title? If the body just expands on what the title already says, delete it.
Bad example:
Add writing-markdown skill
- Add SKILL.md with instructions
- Add scripts/resource-paths script
The body just restates "Add writing-markdown skill" in more words. Delete the body.
Only add a body when the title genuinely can't capture important context. The body must contain non-redundant detail that adds real value.
Write bodies in markdown. Use markdown formatting for lists, emphasis, code, etc.
Common patterns (only when a body is truly necessary):
The title says "what" - the body explains "why" or provides specific details
Create the commit using a heredoc to preserve formatting:
git commit -m "$(cat <<'EOF'
Commit title here
Optional body here.
EOF
)"
| Thought | Reality | | ---------------------------------- | --------------------------------- | | "I'll provide multiple versions" | Draft ONE commit message | | "I should explain the format" | Start with the title directly | | "I'll introduce the message" | NO introductory text whatsoever | | "This simple change needs context" | Simple changes rarely need bodies |
REQUIRED: See references/examples.md for correct formatting.
tools
Use when working with a stack of GitHub pull requests — creating branches, keeping the stack in sync, or merging in order. Covers Git Town setup, PR targeting, rebasing, and landing the stack.
tools
Use when writing or modifying tests in a Bun project
tools
Use when publishing or releasing a new version of an npm/pnpm/yarn/bun package to the registry. Covers package-manager detection, semver bump selection, tagging, pushing, scoped-package access, authentication, and one-time passwords (OTP).
tools
Use when a finished worktree's branch has been reviewed and committed and needs to land. Rebases onto the latest default branch, then either fast-forwards it into the default branch (personal direct-to-main repos) or pushes it for a pull request (shared feature-branch repos).