Claude Code Plugins

Community-maintained marketplace

Feedback

commit-writer

@borkweb/bork-ai
0
0

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.

Install Skill

1Download skill
2Enable skills in Claude

Open claude.ai/settings/capabilities and find the "Skills" section

3Upload to Claude

Click "Upload skill" and select the downloaded ZIP file

Note: Please verify skill by going through its instructions before using it.

SKILL.md

name commit-writer
description 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.
allowed-tools Bash, Read, Grep, Glob

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 solutions you considered? Why did you choose to pursue this solution? Describe any trade-offs you might have had to make. If the change is looking to be a bit bigger, it’s often a good idea to share your plan for tackling it before writing a lot of code.
  • Testing instructions: How should this be tested, and how can a reviewer test the end-user functionality? Are there known issues that you plan to address in a future PR? Are there any side effects that readers should be aware of?.

Examples

Good Commit Messages

feat(auth): add JWT refresh token rotation

Implements automatic refresh token rotation to improve security.
Tokens now expire after 15 minutes and are rotated on each refresh.
Includes Redis storage for token blacklisting.

Closes #234

fix(api): prevent race condition in user creation

The previous implementation didn't properly lock during user creation, leading to duplicate users under high load. Added database-level unique constraint and proper error handling.

refactor(database): extract query builder to separate module

Improves maintainability by separating query building logic from repository classes. No functional changes.

Poor Commit Messages (Avoid These)

❌ "fixed stuff"
❌ "WIP"
❌ "updates"
❌ "changed files"
❌ "Fixed bug"  (not imperative, no context)

Scope Guidelines

Scopes should be specific but not too granular:

  • ✅ (auth), (database), (api), (ui/dashboard)
  • ❌ (file123), (bugfix), (code)

Special Cases

Multiple Changes

If changes span multiple concerns, consider suggesting separate commits: "I notice these changes address both authentication and logging. Would you like to split these into separate commits?"

Breaking Changes

Add BREAKING CHANGE: footer to indicate breaking changes:

feat(api): change user endpoint response format

BREAKING CHANGE: User API now returns `userId` instead of `id`

Repository Style Adaptation

If repository uses different conventions (e.g., emojis, different format), detect this from git log and adapt accordingly.

Output Format

Present the commit message in a code block for easy copying:

Your suggested commit message here

Then offer to create the commit directly or ask if adjustments are needed.

Tools Usage

  • Use Bash for git commands (git status, git diff, git log)
  • Use Read if you need to examine specific changed files for context
  • Use Grep to search for related code patterns if needed
  • Use Glob to understand file structure if scope is unclear

Remember: A great commit message helps future developers (including the author) understand the history and reasoning behind changes.