How strict is the Conventional Commits rule?

Conventional Commits are required for this skill; format messages as type(scope): short summary and include a body if needed.

What if I cannot describe the change clearly?

Split the work into smaller commits until each one is describable; if still unclear, re-evaluate boundaries in step 2.

Should I always run tests before committing?

Run the smallest relevant verification (unit tests, lint, or build) to catch obvious issues before moving on.

commit-work

Scanned

npx machina-cli add skill softaworks/agent-toolkit/commit-work --openclaw

Files (1)

SKILL.md

2.4 KB

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)

Inspect the working tree before staging
- git status
- git diff (unstaged)
- If many changes: git diff --stat
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.
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>
Review what will actually be committed
- git diff --cached
- Sanity checks:
  - no secrets or tokens
  - no accidental debug logging
  - no unrelated formatting churn
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.
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.
Run the smallest relevant verification
- Run the repo's fastest meaningful check (unit tests, lint, or build) before moving on.
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)

Source

git clone https://github.com/softaworks/agent-toolkit/blob/main/skills/commit-work/SKILL.mdView on GitHub

Overview

This skill guides you to create high-quality git commits by reviewing intended changes, splitting work into logical commits, and writing clear messages using Conventional Commits. It emphasizes describing what changed and why, while keeping commits focused and safe to ship.

How This Skill Works

First, inspect the working tree with git status and git diff to understand changes. Then decide commit boundaries and stage only what belongs in the next commit (prefer patch staging with git add -p). Finally, describe the change in 1-2 sentences and craft a Conventional Commit message (type(scope): short summary) before running lightweight verification.

When to Use It

You are asked to commit changes to a feature or bug fix.
Changes are mixed across files and need to be split into logical commits.
You must follow Conventional Commits for your project.
You want to ship safely by ensuring no secrets/logs and no debugging chatter in commits.
You are preparing commits for review or a pull request and need precise messages and boundaries.

Quick Start

Step 1: Inspect the working tree with git status and git diff to understand changes.
Step 2: Stage changes incrementally (git add -p) to keep each commit focused.
Step 3: Write a Conventional Commit message (type(scope): short summary) and run a quick check with git diff --cached before committing.

Best Practices

Always inspect with git status and git diff before staging.
Plan commit boundaries by feature/logic/refactor, backend/frontend, or tests vs prod code.
Use patch staging (git add -p) to isolate changes and avoid mixing unrelated edits.
Write a 1-2 sentence description (what changed; why) and a Conventional Commit message (type(scope): short summary).
Verify with the repo’s fastest check (unit tests, lint, or build) and review the staged changes with git diff --cached.

Example Use Cases

feat(auth): add login endpoint and update unit tests
refactor(ui): extract and reuse a shared Button component
fix(security): remove hard-coded API key; rotate credentials
style: format codebase with Prettier; no functional changes
chore(deps): bump dependencies and update lockfile

Frequently Asked Questions

Add this skill to your agents