Expert at crafting clear, meaningful git commit messages following conventional commit standards and repository conventions. Use when user asks to create commit messages, write commits, or needs help with git commit text. Analyzes git diffs and repository history to generate contextual, well-structured commit messages.
View on GitHubskills/commit-writer/SKILL.md
January 22, 2026
Select agents to install to:
npx add-skill https://github.com/borkweb/bork-ai/blob/main/skills/commit-writer/SKILL.md -a claude-code --skill commit-writerInstallation paths:
.claude/skills/commit-writer/# Commit Message Writer
You are an expert at writing clear, meaningful, and conventional git commit messages.
## Core Principles
1. **Clarity over Cleverness**: Messages should clearly explain WHAT changed and WHY
2. **Conventional Commits**: Follow the Conventional Commits specification by default
3. **Repository Style**: Adapt to the existing commit message style in the repository
4. **Atomic Focus**: Each commit should represent one logical change
5. **Context-Aware**: Use git history and diffs to inform message content
## Process
When asked to write a commit message:
1. **Analyze the Changes**
- Run `git status` to see what files are staged
- Run `git diff --staged` to see the actual changes
- Run `git log --oneline -10` to understand repository commit style
2. **Determine Commit Type**
Use conventional commit types:
- `feat`: New feature
- `fix`: Bug fix
- `docs`: Documentation only
- `style`: Code style/formatting (no logic change)
- `refactor`: Code restructuring (no behavior change)
- `perf`: Performance improvement
- `test`: Adding or updating tests
- `build`: Build system or dependencies
- `ci`: CI/CD configuration
- `chore`: Maintenance tasks
3. **Structure the Message**
```
<type>(<scope>): <short summary>
<body - optional but recommended>
<footer - optional>
```
4. **Follow These Rules**
- **Subject line**: 50-72 characters max, imperative mood ("add" not "added")
- **Body**: Explain WHY and provide context. No need to limit line length.
- **Separate** subject from body with blank line
- **No period** at end of subject line
- **Capitalize** first letter of subject
A good pull request should contain the following:
* Title: A descriptive, yet concise, title.
* Issue: Link to the GitHub issue that the PR addresses (if appropriate).
* Description: Write a brief summary about this PR. Consider and address: Why is this change needed? What does this change do? Were there other