commit

Write Git commit messages following the Conventional Commits specification.

1|Updated Aug 18, 2026
One-click install
npx skills add https://github.com/davidsneighbour/clerkwork --skill commit-davidsneighbour
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: commit
Source: https://github.com/davidsneighbour/clerkwork/tree/main/skills/commit
Command: npx skills add https://github.com/davidsneighbour/clerkwork --skill commit-davidsneighbour

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Inconsistent or vague commit messages make project history hard to read and break automation like changelog generation and semantic releases. This Skill enforces the Conventional Commits v1.0.0 specification so every commit is structured, machine-readable, and consistent. ## Core Features & Use Cases - Structured Message Format: Applies the type(scope): description pattern with optional body and footers, covering all standard types (feat, fix, docs, style, refactor, perf, test, chore, build, ci, revert). - Breaking Changes & Footers: Handles BREAKING CHANGE footers, issue references (Closes #123), and co-author attribution correctly. - Review Workflow: Guides inspection of git status and git diff before drafting, so messages reflect actual changes rather than guesses. - Use Case: After staging a bug fix in the authentication module, ask for a commit message and receive something like "fix(auth): resolve session timeout bug" with a proper footer referencing the issue. ## Quick Start Use the commit skill to write a Conventional Commits message for my currently staged Git changes.

Frequently Asked Questions about commit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a Conventional Commits message?▼

Use the format type(scope): description, where type is one of feat, fix, docs, style, refactor, perf, test, chore, build, ci, or revert. Write the description in imperative present tense, lowercase, without a trailing period, and keep it under 72 characters.

How to mark a breaking change in a commit message?▼

Add an exclamation mark after the type or scope, like feat(api)!: remove deprecated endpoint, or include a BREAKING CHANGE: footer in the commit body explaining what changed and any migration steps required.

What commit types does Conventional Commits support?▼

The standard types are feat, fix, docs, style, refactor, perf, test, chore, build, ci, and revert. Use chore only when no more specific type applies to the change being committed.

Should I review the diff before writing a commit message?▼

Yes, run git status and git diff or git diff --cached before drafting the message. Never guess the message from the file list alone, since the actual changes determine the correct type, scope, and description.

When should a commit message include a body or footer?▼

Include a body for complex changes, non-obvious design decisions, or migration instructions, explaining why rather than what. Use footers for breaking changes, issue references like Closes #123, and co-author attribution.