playbooks

home / skills / windmill-labs / windmill / commit

commit skill

/.claude/skills/commit

This skill creates a focused, single-line conventional commit by analyzing changes and staging files individually for precise commits

npx playbooks add skill windmill-labs/windmill --skill commit

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.8 KB
---
name: commit
user_invocable: true
description: Create a git commit with conventional commit format. MUST use anytime you want to commit changes.
---

# Git Commit Skill

Create a focused, single-line commit following conventional commit conventions.

## Instructions

1. **Analyze changes**: Run `git status` and `git diff` to understand what was modified
2. **Stage only modified files**: Add files individually by name. NEVER use `git add -A` or `git add .`
3. **Write commit message**: Follow the conventional commit format as a single line

## Conventional Commit Format

```
<type>: <description>
```

### Types
- `feat`: New feature or capability
- `fix`: Bug fix
- `refactor`: Code change that neither fixes a bug nor adds a feature
- `docs`: Documentation only changes
- `style`: Formatting, missing semicolons, etc (no code change)
- `test`: Adding or correcting tests
- `chore`: Maintenance tasks, dependency updates, etc
- `perf`: Performance improvement

### Rules
- Message MUST be a single line (no multi-line messages)
- Description should be lowercase, imperative mood ("add" not "added")
- No period at the end
- Keep under 72 characters total

### Examples
```
feat: add token usage tracking for AI providers
fix: resolve null pointer in job executor
refactor: extract common validation logic
docs: update API endpoint documentation
chore: upgrade sqlx to 0.7
```

## Execution Steps

1. Run `git status` to see all changes
2. Run `git diff` to understand the changes in detail
3. Run `git log --oneline -5` to see recent commit style
4. Stage ONLY the modified/relevant files: `git add <file1> <file2> ...`
5. Create the commit with conventional format:
   ```bash
   git commit -m "<type>: <description>

   Co-Authored-By: Claude Opus 4.5 <[email protected]>"
   ```
6. Run `git status` to verify the commit succeeded

Overview

This skill creates focused, single-line git commits following the Conventional Commits format. Use it anytime you want to commit changes to ensure consistent history and easy changelog generation. It enforces staging only the modified files and keeping messages concise and actionable.

How this skill works

The skill inspects the working tree and diffs to determine what changed, then guides you to stage only the relevant files by name. It constructs a single-line commit message using a verified Conventional Commit type and a lowercase, imperative description under 72 characters. Finally, it runs the commit and verifies the result in git status.

When to use it

  • Committing any code or documentation change to the repository
  • Preparing a commit that should be clearly categorized for changelogs
  • When you want to avoid noisy commits that stage unrelated files
  • Enforcing team commit style during reviews or CI checks
  • Creating small, focused commits for easier code bisecting

Best practices

  • Run git status and git diff first to understand modifications
  • Stage files individually with git add <file> — never use git add -A or git add .
  • Use a single-line message: <type>: <description>, lowercase and imperative
  • Keep the message under 72 characters and omit a trailing period
  • Choose the correct type (feat, fix, refactor, docs, style, test, chore, perf)

Example use cases

  • Add a new API endpoint: feat: add webhook trigger for job runs
  • Fix a runtime error: fix: prevent null pointer in task runner
  • Update docs: docs: clarify installation steps for self-hosting
  • Refactor logic: refactor: extract sql connection helper
  • Upgrade dependency: chore: bump postgres driver to latest

FAQ

What if I need multi-line context in a commit?

The skill mandates a single-line Conventional Commit for the summary. Put longer context in the body only if your workflow allows multi-line commits, but prefer separate follow-up commits for extra detail.

Can I stage multiple files?

Yes, stage multiple specific files by name (git add file1 file2). Do not use broad adds that capture unrelated changes.

Which commit type should I pick for small fixes?

Use fix for bug fixes, chore for maintenance, and refactor for restructuring without feature or bug implications.