# Commit

> Create structured git commits. Groups related changes logically with clear, descriptive messages. Use when code changes are ready to commit.

- Skill: `juicesharp/commit-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add juicesharp/commit-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/juicesharp/commit-2/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: juicesharp (https://skillmd.com/u/juicesharp)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/juicesharp/commit-2

---


# Commit Changes

You are tasked with creating git commits for repository changes.

## Commit hint

If the user has already provided a specific commit hint or message, use it as guidance. Otherwise the user may have provided no hint — their input will appear as a follow-up paragraph after this skill body if they did.

## Context:
- **In-session**: If there's conversation history, use it to understand what was built/changed
- **Standalone**: If no context available, rely entirely on git state and file inspection

## Process:

0. **Check git availability:**
   - Run `git status --short` to determine whether the current directory is a git repository
   - If not a git repo, tell the user: "This directory is not a git repository. Run `git init` to initialize one."
   - Stop — do not proceed with commit.

1. **Think about what changed:**
   - **If in-session**: Review the conversation history to understand what was accomplished
   - **Always**: Run `git diff` to understand the modifications in detail
   - If needed, inspect file contents to understand purpose and scope
   - Consider whether changes should be one commit or multiple logical commits

2. **Plan your commit(s):**
   - Identify which files belong together
   - Draft clear, descriptive commit messages
   - Use imperative mood in commit messages
   - Focus on why the changes were made, not just what
   - Check for sensitive information (API keys, credentials) before committing

3. **Present your plan to the user:**
   - List the files you plan to add for each commit
   - Show the commit message(s) you'll use
   - Use the `ask_user_question` tool to confirm the commit plan. Question: "[N] commit(s) with [M] files. Proceed?". Header: "Commit". Options: "Commit (Recommended)" (Create the commit(s) as planned); "Adjust" (Change the grouping or commit messages); "Review files" (Show me the full diff before committing).

4. **Execute upon confirmation:**
   - Use `git add` with specific files (never use `-A` or `.`)
   - Create commits with your planned messages
   - Show the result with `git log --oneline -n X` (where X = number of commits you just created)

## Important:

- **NEVER add co-author information or Claude attribution**
- Commits should be authored solely by the user
- Do not include any "Generated with Claude" messages
- Do not add "Co-Authored-By" lines
- Write commit messages as if the user wrote them

## Remember:

- Adapt your approach: use conversation context if available, otherwise infer from git state
- In-session: you have full context of what was done; Standalone: infer from git analysis
- Group related changes by purpose (feature, fix, refactor, docs)
- Keep commits atomic: one logical change per commit
- Split into multiple commits if: different features, mixing bugs with features, or unrelated concerns
- The user trusts your judgment - they asked you to commit