commit-helper

Generating Commit Messages

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "commit-helper" with this command: npx skills add butttons/dora/butttons-dora-commit-helper

Generating Commit Messages

Generate commit messages following the Conventional Commits specification.

Format

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Common Types

  • feat: New feature (correlates with MINOR in SemVer)

  • fix: Bug fix (correlates with PATCH in SemVer)

  • docs: Documentation changes

  • style: Code style changes (formatting, semicolons, etc.)

  • refactor: Code refactoring without changing behavior

  • perf: Performance improvements

  • test: Adding or updating tests

  • build: Build system or dependency changes

  • ci: CI/CD configuration changes

  • chore: Other changes that don't modify src or test files

Breaking Changes

Use ! after type/scope or add BREAKING CHANGE: footer:

feat!: redesign API response format

BREAKING CHANGE: Response format changed from array to object

Examples

Simple commit

docs: fix typo in README

With scope

feat(cli): add status command

With body

fix: prevent race condition in request handling

  • Introduce request ID tracking to dismiss stale responses.
  • Remove obsolete timeout-based mitigation.

Breaking change

feat(api)!: change authentication flow

BREAKING CHANGE: JWT tokens now required for all endpoints

Instructions

  • Run git diff --staged to see staged changes

  • Generate a commit message with:

  • Clear, concise header in present tense.

  • Optional body with bullet points for complex changes. Always use bullet points when adding a body.

  • Optional footer for breaking changes or references.

  • Show the proposed commit message to the user, by printing to stdout.

  • Ask the user for their approval using the AskUserQuestion tool.

  • If yes, commit the changes.

  • If no, incorporate the feedback and go back to step 2 to generate the correct message.

Best Practices

  • Use present tense ("add feature" not "added feature")

  • Keep header under 72 characters

  • Explain what and why, not how

  • Reference issues/PRs in footer when relevant (e.g., Refs: #123 )

  • Use body for complex changes, omit for simple ones

IMPORTANT: Be concise. Grammar does not matter as long as it's clear and concise. Try to keep the body within 2-3 bullet points with very concise sentences.

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

commit-helper

No summary provided by upstream source.

Repository SourceNeeds Review
General

commit-helper

No summary provided by upstream source.

Repository SourceNeeds Review
General

commit-helper

No summary provided by upstream source.

Repository SourceNeeds Review