commit-work

The commit-work skill enforces disciplined version control by treating commits as meaningful units of history rather than mere save points. Instead of dumping all changes at once, the agent parses the working tree to isolate logical groupings, ensuring every commit adheres to Conventional Commits standards. It rigorously verifies the state of the repository before finalization, performing differential checks against the index to prevent the inclusion of debugging artifacts, secrets, or unintentional formatting noise. By enforcing a strict workflow that requires human-readable justifications for every hunk, it keeps repository history clean and navigable. This approach transforms a messy working directory into a sequence of atomic, reviewable updates, which minimizes merge conflicts and accelerates peer review for maintainers.

When to Use This Skill

• •Separating feature implementation from dependency updates in a single session
• •Refactoring code while ensuring tests remain in a separate, valid commit
• •Cleaning up a cluttered working tree after a long prototyping phase
• •Preparing an atomic set of commits for a complex pull request

How to Invoke This Skill

Example prompts that trigger this skill in Claude Code, Cursor, or Antigravity:

• “Commit my recent changes to the repository
• “Prepare these file modifications for a clean commit
• “Help me split my current work into logical conventional commits
• “Review and commit my current progress following standard conventions
• “Finalize the changes in my staging area with proper messages

Pro Tips

• 💡Always use `git diff --cached` to review exactly what will be committed, ensuring no unintended changes or sensitive information slips into your repository.
• 💡Leverage patch staging (`git add -p`) extensively when changes are mixed within files. This allows for creating highly atomic commits that are much easier to revert or cherry-pick.
• 💡Beyond just adhering to Conventional Commits, consider adding a brief 'why' in your commit body. Explaining the reasoning behind a change significantly enhances future understanding and debugging.

What this skill does

• •Performs granular staging using patch-based selection
• •Validates commit messages against Conventional Commits formatting
• •Identifies and isolates unrelated modifications into distinct logical commits
• •Runs automated verification checks prior to finalizing commit operations
• •Detects potential security risks or unintended debug logs in staged changes

When not to use it

• ✕When working in a throwaway exploration branch where history cleanliness is irrelevant
• ✕When an immediate emergency hotfix requires skipping verification steps

Example workflow

1. Execute git status and diff to audit modified files
2. Apply git add -p to separate distinct logical changes
3. Review changes using git diff --cached to confirm content
4. Compose a Conventional Commit message detailing the intent
5. Run relevant linting or unit tests to verify the commit state
6. Finalize the commit and repeat for remaining unstaged hunks

Prerequisites

• –Git repository initialized locally
• –Repository guidelines for scopes and types defined

Pitfalls & limitations

• !Over-splitting commits can lead to unnecessarily verbose git logs
• !Ignoring test failures during the verification step can break build pipelines
• !Misinterpreting complex hunk overlaps may result in partial code logic

FAQ

How it compares

Unlike a standard 'git commit -am' which ignores structure, this skill mandates intentional staging and schema validation to ensure long-term maintainability.

Source & trust

Recommended Rules

Recommended Workflows

Recommended MCP Servers