Prompt file imported from knative/func (.claude/commands/func-commit-message.md). Fill in {{arguments}} before use. Copyright stays with the author.

Git Commit Message Guidelines

Name: func-commit-message
Author: knative

Create a git commit message following these rules:

The Seven Rules

Separate subject from body with a blank line
Limit the subject line to 50 characters
Use conventional commit spec for subject line
Do not end the subject line with a period
Use the imperative mood in the subject line
Wrap the body at 72 characters
Use the body to explain what and why vs. how

Format

<type>: <subject - max 50 chars total, imperative mood, conventional commit spec> <Body - wrapped at 72 chars, explains what and why> <Optional bullet points for clarity> <Optional "Issue {{arguments}}" if provided>

Conventional Commits

Use conventional commits spec with types: feat, fix, refactor, docs, test, chore, style, perf, ci, build
Format: <type>: <description>
Examples: "feat: add user authentication", "fix: resolve memory leak in cache"
Use "feat" only on user-facing changes

Subject Line

Write as if completing: "If applied, this commit will..."
Include type prefix (conventional commits)
Total length max 50 chars including type
Examples: "refactor: simplify cache handling", "fix: prevent race condition"
NOT: "refactored cache", "fixed the race"

Body

Explain the motivation for the change
Explain the "what" and "why" vs. "how" which means:
- the way things worked before the change (and what was wrong with that),
- the way they work now,
- and why the contributor decided to solve it the way they did,
- and if you're not sure about the "why" then ask the contributor.
Focus on context, not implementation details
Find a balance for message length, i.e. analyze the diff and decide if a shorter message is enough or more explanation is needed
Don't overuse bullet points (-, *, +), add them only in bigger commits if (and only if) they are helpful
Keep it short if there aren't many changes

Example

Here is a good example from a commit to the Bitcoin core.

   refactor: simplify serialize.h's exception handling

   Remove the 'state' and 'exceptmask' from serialize.h's stream
   implementations, as well as related methods.

   As exceptmask always included 'failbit', and setstate was always
   called with bits = failbit, all it did was immediately raise an
   exception. Get rid of those variables, and replace the setstate
   with direct exception throwing (which also removes some dead
   code).

   As a result, good() is never reached after a failure (there are
   only 2 calls, one of which is in tests), and can just be replaced
   by !eof().

   fail(), clear(n) and exceptions() are just never called. Delete
   them.

Context

Current git status: !git status
Current git diff (staged and unstaged changes): !git diff HEAD
Current branch: !git branch --show-current

Task

Analyze the staged changes from git diff
New added features and fixes are more important than other types like refactoring, etc.
Draft a commit message following all seven rules
Use conventional commits spec
If {{arguments}} is provided, add "Issue {{arguments}}" at the bottom
Show me the final message - DO NOT commit it

# Git Commit Message Guidelines Create a git commit message following these rules: ## The Seven Rules 1. Separate subject from body with a blank line 2. Limit the subject line to 50 characters 3. Use conventional commit spec for subject line 4. Do not end the subject line with a period 5. Use the imperative mood in the subject line 6. Wrap the body at 72 characters 7. Use the body to explain what and why vs. how ## Format ```txt <type>: <subject - max 50 chars total, imperative mood, conventional commit spec> <Body - wrapped at 72 chars, explains what and why> <Optional bullet points for clarity> <Optional "Issue {{arguments}}" if provided> ``` ## Conventional Commits - Use conventional commits spec with types: feat, fix, refactor, docs, test, chore, style, perf, ci, build - Format: `<type>: <description>` - Examples: "feat: add user authentication", "fix: resolve memory leak in cache" - Use "feat" only on user-facing changes ## Subject Line - Write as if completing: "If applied, this commit will..." - Include type prefix (conventional commits) - Total length max 50 chars including type - Examples: "refactor: simplify cache handling", "fix: prevent race condition" - NOT: "refactored cache", "fixed the race" ## Body - Explain the motivation for the change - Explain the "what" and "why" vs. "how" which means: - the way things worked before the change (and what was wrong with that), - the way they work now, - and why the contributor decided to solve it the way they did, - and if you're not sure about the "why" then ask the contributor. - Focus on context, not implementation details - Find a balance for message length, i.e. analyze the diff and decide if a shorter message is enough or more explanation is needed - Don't overuse bullet points (-, \*, +), add them only in bigger commits if (and only if) they are helpful - Keep it short if there aren't many changes ### Example Here is a good example from a [commit to the Bitcoin core](https://github.com/bitcoin/bitcoin/commit/eb0b56b19017ab5c16c745e6da39c53126924ed6). ```txt refactor: simplify serialize.h's exception handling Remove the 'state' and 'exceptmask' from serialize.h's stream implementations, as well as related methods. As exceptmask always included 'failbit', and setstate was always called with bits = failbit, all it did was immediately raise an exception. Get rid of those variables, and replace the setstate with direct exception throwing (which also removes some dead code). As a result, good() is never reached after a failure (there are only 2 calls, one of which is in tests), and can just be replaced by !eof(). fail(), clear(n) and exceptions() are just never called. Delete them. ``` ## Context - Current git status: !`git status` - Current git diff (staged and unstaged changes): !`git diff HEAD` - Current branch: !`git branch --show-current` ## Task 1. Analyze the staged changes from git diff 2. New added features and fixes are more important than other types like refactoring, etc. 3. Draft a commit message following all seven rules 4. Use conventional commits spec 5. If {{arguments}} is provided, add "Issue {{arguments}}" at the bottom 6. Show me the final message - DO NOT commit it

{ "prompt": "# Git Commit Message Guidelines\n\nCreate a git commit message following these rules:\n\n## The Seven Rules\n\n1. Separate subject from body with a blank line\n2. Limit the subject line to 50 characters\n3. Use conventional commit spec for subject line\n4. Do not end the subject line with a period\n5. Use the imperative mood in the subject line\n6. Wrap the body at 72 characters\n7. Use the body to explain what and why vs. how\n\n## Format\n\n```txt\n<type>: <subject - max 50 chars total, imperative mood, conventional commit spec> <Body - wrapped at 72 chars, explains what and why> <Optional bullet points for clarity> <Optional \"Issue {{arguments}}\" if provided>\n```\n\n## Conventional Commits\n\n- Use conventional commits spec with types: feat, fix, refactor, docs, test, chore, style, perf, ci, build\n- Format: `<type>: <description>`\n- Examples: \"feat: add user authentication\", \"fix: resolve memory leak in cache\"\n- Use \"feat\" only on user-facing changes\n\n## Subject Line\n\n- Write as if completing: \"If applied, this commit will...\"\n- Include type prefix (conventional commits)\n- Total length max 50 chars including type\n- Examples: \"refactor: simplify cache handling\", \"fix: prevent race condition\"\n- NOT: \"refactored cache\", \"fixed the race\"\n\n## Body\n\n- Explain the motivation for the change\n- Explain the \"what\" and \"why\" vs. \"how\" which means:\n - the way things worked before the change (and what was wrong with that),\n - the way they work now,\n - and why the contributor decided to solve it the way they did,\n - and if you're not sure about the \"why\" then ask the contributor.\n- Focus on context, not implementation details\n- Find a balance for message length, i.e. analyze the diff and decide if a shorter message is enough or more explanation is needed\n- Don't overuse bullet points (-, \\*, +), add them only in bigger commits if (and only if) they are helpful\n- Keep it short if there aren't many changes\n\n### Example\n\nHere is a good example from a [commit to the Bitcoin core](https://github.com/bitcoin/bitcoin/commit/eb0b56b19017ab5c16c745e6da39c53126924ed6).\n\n```txt\n refactor: simplify serialize.h's exception handling\n\n Remove the 'state' and 'exceptmask' from serialize.h's stream\n implementations, as well as related methods.\n\n As exceptmask always included 'failbit', and setstate was always\n called with bits = failbit, all it did was immediately raise an\n exception. Get rid of those variables, and replace the setstate\n with direct exception throwing (which also removes some dead\n code).\n\n As a result, good() is never reached after a failure (there are\n only 2 calls, one of which is in tests), and can just be replaced\n by !eof().\n\n fail(), clear(n) and exceptions() are just never called. Delete\n them.\n```\n\n## Context\n\n- Current git status: !`git status`\n- Current git diff (staged and unstaged changes): !`git diff HEAD`\n- Current branch: !`git branch --show-current`\n\n## Task\n\n1. Analyze the staged changes from git diff\n2. New added features and fixes are more important than other types like refactoring, etc.\n3. Draft a commit message following all seven rules\n4. Use conventional commits spec\n5. If {{arguments}} is provided, add \"Issue {{arguments}}\" at the bottom\n6. Show me the final message - DO NOT commit it", "variables": [ "arguments" ], "notes": "Create a git commit Tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git log:*), Bash(git diff:*), Bash(git branch:*).", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/knative/func", "path": ".claude/commands/func-commit-message.md", "ref": "f363f4e790807c32fe653aec18249bb8686b8d6d", "url": "https://github.com/knative/func/blob/f363f4e790807c32fe653aec18249bb8686b8d6d/.claude/commands/func-commit-message.md", "key": "knative/func/.claude/commands/func-commit-message.md" } } }

func-commit-message

About

Git Commit Message Guidelines

The Seven Rules

Format

Conventional Commits

Subject Line

Body

Example

Context

Task

Use it

Manifest

Reviews