Commit Work
Stage only intended changes, split mixed work into logical commits, and write Conventional Commits messages your agent or reviewer can trust.
Overview
commit-work is an agent skill most often used in Ship (also Build) that creates logical, Conventional Commits after reviewing and patch-staging intended changes.
Install
npx skills add https://github.com/softaworks/agent-toolkit --skill commit-workWhat is this skill?
- Checklist workflow: status, unstaged diff, then cached diff before every commit
- Splits unrelated changes by feature, layer, formatting vs logic, and tests vs prod
- Patch staging with git add -p and git restore --staged for mixed hunks
- Conventional Commits format is required for subject and scope discipline
- Sanity checks for secrets, tokens, and accidental files before commit
Adoption & trust: 3.8k installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are ready to commit but the diff mixes refactors, features, and noise, and your messages do not explain what changed or why.
Who is it for?
Solo builders who batch agent-generated edits and need safe staging splits before push or PR.
Skip if: Repos where you only need automated release tagging with no human review, or projects that forbid interactive patch staging workflows.
When should I use this skill?
User asks to commit, craft a commit message, stage changes, or split work into multiple commits; Conventional Commits required.
What do I get? / Deliverables
You ship one or more focused commits with Conventional Commit messages and no unintended hunks, ready to push or open a PR.
- One or more git commits with Conventional Commit messages
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Commit hygiene is shelved under Ship → review because it is the gate between finished work and what teammates and CI actually ingest. The workflow centers on diff review, patch staging, and message quality—the same habits as pre-PR self-review.
Where it fits
Split a full-stack feature into backend, frontend, and test commits before opening a PR.
Commit only the styling hunk from a mixed file after running a design-system update.
Land a minimal hotfix commit with a scoped conventional message while keeping WIP changes unstaged.
How it compares
Use instead of letting the agent run a single giant git commit -a with a vague message.
Common Questions / FAQ
Who is commit-work for?
Indie developers and small teams using Claude Code, Cursor, or Codex who want agent-assisted commits that stay small, conventional, and free of secrets.
When should I use commit-work?
Use it in Ship before opening a PR or pushing; in Build after finishing a feature slice; in Operate when committing hotfix iterations—whenever you ask to commit, craft a message, stage changes, or split work into multiple commits.
Is commit-work safe to install?
It instructs local git read/write on your repo; review the Security Audits panel on this page and never commit credentials—the skill explicitly calls out secret checks.
SKILL.md
READMESKILL.md - Commit Work
# Commit work ## Goal Make commits that are easy to review and safe to ship: - only intended changes are included - commits are logically scoped (split when needed) - commit messages describe what changed and why ## Inputs to ask for (if missing) - Single commit or multiple commits? (If unsure: default to multiple small commits when there are unrelated changes.) - Commit style: Conventional Commits are required. - Any rules: max subject length, required scopes. ## Workflow (checklist) 1) Inspect the working tree before staging - `git status` - `git diff` (unstaged) - If many changes: `git diff --stat` 2) Decide commit boundaries (split if needed) - Split by: feature vs refactor, backend vs frontend, formatting vs logic, tests vs prod code, dependency bumps vs behavior changes. - If changes are mixed in one file, plan to use patch staging. 3) Stage only what belongs in the next commit - Prefer patch staging for mixed changes: `git add -p` - To unstage a hunk/file: `git restore --staged -p` or `git restore --staged <path>` 4) Review what will actually be committed - `git diff --cached` - Sanity checks: - no secrets or tokens - no accidental debug logging - no unrelated formatting churn 5) Describe the staged change in 1-2 sentences (before writing the message) - "What changed?" + "Why?" - If you cannot describe it cleanly, the commit is probably too big or mixed; go back to step 2. 6) Write the commit message - Use Conventional Commits (required): - `type(scope): short summary` - blank line - body (what/why, not implementation diary) - footer (BREAKING CHANGE) if needed - Prefer an editor for multi-line messages: `git commit -v` - Use `references/commit-message-template.md` if helpful. 7) Run the smallest relevant verification - Run the repo's fastest meaningful check (unit tests, lint, or build) before moving on. 8) Repeat for the next commit until the working tree is clean ## Deliverable Provide: - the final commit message(s) - a short summary per commit (what/why) - the commands used to stage/review (at minimum: `git diff --cached`, plus any tests run) # Commit Work A comprehensive skill for creating high-quality, production-ready git commits that are easy to review, safe to ship, and follow best practices. ## Purpose This skill helps you create well-crafted git commits by: - Ensuring only intended changes are included - Splitting work into logically scoped commits - Writing clear, descriptive commit messages that explain what changed and why - Following Conventional Commits format - Preventing common mistakes (secrets, debug code, unrelated changes) ## When to Use Use this skill when you need to: - Commit your work with proper staging and review - Craft meaningful commit messages - Split mixed changes into multiple logical commits - Follow Conventional Commits format - Ensure commits are review-ready and safe to merge **Trigger phrases:** - "commit this work" - "create a commit" - "split these changes into commits" - "help me commit" - "write a commit message" ## How It Works The skill follows a rigorous 8-step workflow: 1. **Inspect** - Review working tree with `git status` and `git diff` 2. **Decide boundaries** - Determine if changes should be split into multiple commits 3. **Stage selectively** - Use patch staging (`git add -p`) for granular control 4. **Review staged changes** - Verify with `git diff --cached` 5. **Describe changes** - Articulate what changed and why in 1-2 sentences 6. **Write message** - Craft Conventional Commits format message 7. **Verify** - Run relevant tests/checks before committing 8. **Repeat** -