formatting-commits
Scannednpx machina-cli add skill lijinnair/claude-code-skillforge/formatting-commits --openclawGit Commit Formatting SOP
Execution Steps
Step 1: Gather Staged Changes
If the user has not provided a description, run:
!`git diff --staged`
to capture the actual code changes as context.
Step 2: Classify the Change Type
Determine the correct Conventional Commits type based on the diff or description:
feat— A new featurefix— A bug fixdocs— Documentation only changesstyle— Formatting, missing semi-colons, etc.refactor— Code change that is neither a fix nor a featurechore— Build process, dependency updatestest— Adding or fixing tests
Step 3: Extract Scope
Identify the affected module, component, or file area (e.g., auth, api, ui). Use (scope) in the commit header.
Step 4: Write the Commit Message
Compose the full commit message following this structure:
<type>(<scope>): <short imperative summary under 72 chars>
<optional body: what changed and why, not how>
<optional footer: BREAKING CHANGE: ... or Closes #issue>
Examples:
Input: Added user authentication with JWT tokens Output:
feat(auth): implement JWT-based authentication
Add login endpoint and token validation middleware
Input: Fixed bug where dates displayed incorrectly in reports Output:
fix(reports): correct date formatting in timezone conversion
Use UTC timestamps consistently across report generation
Input: Updated dependencies and refactored error handling Output:
chore: update dependencies and refactor error handling
- Upgrade lodash to 4.17.21
- Standardize error response format across endpoints
Step 5: Deliver
Output the final commit message in a single code block, ready to copy-paste into the terminal.
Source
git clone https://github.com/lijinnair/claude-code-skillforge/blob/main/examples/formatting-commits/SKILL.mdView on GitHub Overview
This skill creates a properly formatted commit message following the Conventional Commits spec, based on your staged changes or a brief description. It guides you through determining type, scope, and content, and outputs a ready-to-paste message.
How This Skill Works
It first gathers changes (via staged diffs if no description is provided), classifies the change type (feat, fix, docs, style, refactor, chore, test), and extracts an optional scope. It then composes the message as <type>(<scope>): <summary>, with an optional body and footer, and delivers the final text ready to copy.
When to Use It
- When you want to add a new feature and tag it with feat
- When you fix a bug and tag it with fix
- When you update documentation and tag it with docs
- When you format code or adjust styling with style
- When you update dependencies or perform build-related changes with chore or refactor
Quick Start
- Step 1: Provide a description or stage your changes. If you have no description, gather staged changes with git diff --staged.
- Step 2: The tool classifies the type, extracts the scope, and formats the message as <type>(<scope>): <summary> with optional body/footer.
- Step 3: Copy the generated commit message from the output and paste it into your terminal.
Best Practices
- Choose the correct type (feat, fix, docs, style, refactor, chore, test) for clarity
- Specify a meaningful scope like a module or file (e.g., auth, api, ui)
- Keep the subject under 72 characters; include a brief, imperative summary
- Provide a brief body explaining what changed and why, not how
- Add a BREAKING CHANGE footer if the change is not backward compatible
Example Use Cases
- feat(auth): implement JWT-based authentication
- fix(reports): correct date formatting in timezone conversion
- chore: update dependencies and refactor error handling
- style(ui): fix alignment and trailing whitespace
- test(api): add tests for endpoint validation
