writing-git-commits

Draft conventional git commit messages with type, scope, and summary.

2|Updated May 15, 2015
One-click install
npx skills add https://github.com/stephendolan/dotfiles --skill writing-git-commits
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: writing-git-commits
Source: https://github.com/stephendolan/dotfiles/tree/main/claude/skills/writing-git-commits
Command: npx skills add https://github.com/stephendolan/dotfiles --skill writing-git-commits

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill guides creating conventional commits that communicate intent, scope, and rationale effectively.

Core Features & Use Cases

  • Imperative Mood & Scope: Ensure summaries start with a verb and include a scoped description.
  • Body & Footer: When to add reasoning, breaking changes, and issue references.
  • Patterns & Examples: Concrete templates for common change types.

Quick Start

Generate a commit with type feat, scope auth, and a concise summary: "feat(auth): add OAuth2 provider".

Frequently Asked Questions about writing-git-commits

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

FAQPage Schema
How do I write conventional commits that follow the standard format?

Conventional commits use the <type>(<scope>): <summary> structure. Type describes the change category (feat, fix, refactor, docs, chore), scope specifies the affected area, and summary states the change in imperative mood under 72 characters. For example: feat(auth): add OAuth2 provider.

What's the difference between imperative mood and past tense in commit messages?

Imperative mood uses action verbs as if issuing a command: 'add feature' not 'added feature'. This style matches git's built-in messages and creates consistency across commit history, making it easier to scan what each commit does.

When should I include a commit body and footer?

Add a body to explain reasoning, context, or implementation details when the summary alone doesn't convey the change's full impact. Use footers to reference breaking changes, issue numbers, or related tickets that connect the commit to your workflow.

Can I use conventional commits across different project types?

Yes, conventional commits apply across any git repository—web apps, libraries, infrastructure code, documentation projects. The format remains consistent regardless of language or framework, helping teams standardize commit practices.

How do I choose the right scope for my commit?

Scope identifies the specific component, module, or feature affected: auth, api, ui, database. Keep it concise and meaningful to your codebase structure so readers immediately understand what area changed without reading the full diff.

What counts as a breaking change in commit footers?

A breaking change alters the public API, removes functionality, or modifies behavior users depend on. Mark it with BREAKING CHANGE: in the footer so tools and maintainers can flag major version bumps and alert consumers of the repository.