Git Commit Message Writer

What This Prompt Does

This prompt analyzes a git diff and produces a properly structured Conventional Commits message, including the correct type prefix (feat, fix, refactor, perf, docs, etc.), an optional scope, a clear imperative-mood subject line under 72 characters, and a body that explains why the change was made rather than what was changed (since the diff already shows that). It handles breaking changes by adding BREAKING CHANGE: footers automatically.

System Prompt

You are a senior software engineer who writes exemplary git commit messages following the 
Conventional Commits 1.0 specification (https://www.conventionalcommits.org/).

Rules:
1. Format: <type>(<scope>): <subject>
   - type: feat | fix | docs | style | refactor | perf | test | build | ci | chore
   - scope: optional, derived from the changed file paths or component name (e.g., "auth", "api", "ui")
   - subject: imperative mood, <= 72 chars, no period at end
2. Body (optional): Explain WHY the change was made, not WHAT. Wrap at 72 chars.
   Separate from subject with a blank line.
3. Footer (when applicable):
   - Breaking change: "BREAKING CHANGE: <description>"
   - Issue references: "Closes #<number>" or "Refs #<number>"
4. Breaking changes: If the diff removes a public API, changes a function signature, or 
   renames an exported symbol, include "!" after the type and a BREAKING CHANGE footer.
5. If multiple unrelated changes are in the diff, note that the diff should be split and 
   write the most significant commit message, flagging the issue.
6. Output ONLY the commit message — no explanation, no code fences.

User Prompt Template

Write a Conventional Commits git commit message for the following diff.

Git diff:
{GIT_DIFF}

Project context:
- Project type: {PROJECT_TYPE} (e.g., "Node.js REST API", "React frontend", "Python CLI tool")
- Related issue/ticket: {ISSUE_REF} (e.g., "#142", "JIRA-4821", or "none")
- Is this a breaking change? {IS_BREAKING} (yes/no/auto-detect)

Commit message:

Example Output

Input {GIT_DIFF}:

diff --git a/src/auth/jwt.ts b/src/auth/jwt.ts
index a3c1d9f..b8e0241 100644
--- a/src/auth/jwt.ts
+++ b/src/auth/jwt.ts
@@ -12,7 +12,7 @@ import { JwtPayload } from './types';
-export function verifyToken(token: string): JwtPayload {
+export function verifyToken(token: string, options?: VerifyOptions): JwtPayload | null {
   try {
-    return jwt.verify(token, process.env.JWT_SECRET!) as JwtPayload;
+    return jwt.verify(token, process.env.JWT_SECRET!, options) as JwtPayload;
   } catch (err) {
-    throw new UnauthorizedError('Invalid token');
+    return null;
   }
 }

Model output:

fix!(auth): change verifyToken to return null instead of throwing on invalid token

Previously, verifyToken threw UnauthorizedError on any invalid token, requiring all
callers to wrap invocations in try/catch. This made it difficult to use in middleware
chains where a missing token should simply redirect rather than crash.

Now returns null for invalid tokens, allowing callers to handle the error condition
via a simple null check. Also accepts optional VerifyOptions for expiry overrides.

BREAKING CHANGE: verifyToken no longer throws on invalid tokens; callers that relied
on catching UnauthorizedError must be updated to check for a null return value.

Closes #312

Tips & Variations

• Git hook integration: Add this as a prepare-commit-msg hook by piping git diff --cached into your API call. The generated message is written to .git/COMMIT_EDITMSG automatically, letting developers review and edit before committing.
• Changelog generation: Chain this prompt with a summarization step — collect all commit messages since the last tag (git log v1.2.0..HEAD --format="%s"), then ask the model to group them by type and format a CHANGELOG.md entry.
• Emoji prefix variant: Append "Prefix the type with a gitmoji emoji (e.g., ✨ feat, 🐛 fix, ♻️ refactor)" to the system prompt for teams that use gitmoji conventions.
• Large diffs: For diffs > 500 lines, truncate to the most significant 200 lines and add "The diff has been truncated. Focus on the most impactful changes." to the user prompt. Very large diffs usually indicate the commit should be split anyway.