Commit
Scannednpx machina-cli add skill Weaverse/.agents/commit --openclawWorkflow
-
Run these commands in parallel to understand the current state:
git status— see all tracked/untracked files and staging stategit diff— see unstaged changes
-
Analyze ALL changes (staged + unstaged) and determine what should be committed:
- If there are no changes at all, inform the user and stop
- Do NOT commit files that likely contain secrets (
.env, credentials, tokens, API keys). Warn the user if such files are present.
-
Group related file changes into logical commits:
- Do NOT lump all changes into a single commit
- Examine each changed file and understand what it does
- Group files that are part of the same logical change together (e.g., a component + its styles + its test = one commit)
- Each group becomes its own commit
- If only one logical change exists, one commit is fine
-
For each group, draft a commit message:
- Write natural, concise descriptions of what changed and why
- Do NOT use conventional commits format (no
feat:,fix:,chore:prefixes) - Keep the subject line under 72 characters
- If the user provided a message or instructions via arguments, incorporate or use that for the relevant commit(s)
-
For each group, stage and commit:
git add <specific files>for that group onlygit commit -m "message"- Repeat for each group in a logical order (foundational changes first)
-
Run
git statusafter all commits to verify everything is clean. -
Report the result: show each commit hash and summary.
User Arguments
$ARGUMENTS
Overview
Commit changes with well-crafted messages by splitting work into logical groups rather than a single monolithic commit. The process starts by inspecting the current state, avoiding sensitive files, and then creating targeted commits that explain what changed and why.
How This Skill Works
Run git status and git diff to understand the full state (tracked, untracked, staged, and unstaged). Analyze changes to form logical groups, then for each group: stage only its files and write a natural, concise message (subject under 72 chars) before committing. After all groups are committed, run git status to confirm a clean working tree and report the resulting commit hashes.
When to Use It
- You’re adding a feature that touches multiple files (component, tests, and docs) and want separate commits per logical change.
- You’re performing a refactor that changes structure but preserves behavior.
- You’re fixing a bug that spans related modules and needs a clear narrative for each fix.
- You’re updating assets or dependencies and want to keep those changes in their own commits from code changes.
- You’re preparing a release branch and want a clean, explainable history.
Quick Start
- Step 1: Run git status and git diff to understand the current state.
- Step 2: Group changes into logical commits and draft natural messages (include any provided argument message for relevant commits).
- Step 3: For each group, git add <files> and git commit -m "message", then git status to verify.
Best Practices
- Analyze both staged and unstaged changes before deciding groups.
- Avoid committing files that may contain secrets (.env, credentials, tokens, API keys); warn if detected.
- Group changes by logical feature or component; don’t lump unrelated changes into one commit.
- Draft natural, concise messages; avoid conventional prefixes like feat:, fix:, or chore:.
- Incorporate any user-provided messages into the relevant commits.
Example Use Cases
- Add user authentication flow: login component, API calls, and unit tests.
- Refactor data access layer without changing API surface.
- Fix breadcrumb navigation across pages and update related tests.
- Update UI styling for modal component and associated tests.
- Remove deprecated API usage and migrate to new endpoints with a log entry.
