version: "1.0.0" name: commit-message description: Generate a repository-conformant commit message for the currently staged changes disable-model-invocation: true

Suggest a Commit Message

Generate a commit message for the currently staged changes only. Do not stage, commit, amend, or push anything — only produce the message text for the user to use.

Consider only what is in the staging area (the index). Ignore unstaged and working-tree changes entirely. If nothing is staged, say so and stop without producing a message.

Steps

1. Inspect staged changes with git diff --cached --stat first to see scope, then

git diff --cached for detail. Do not paste the full diff back into the chat — read it, then write the message.

• Work from the diff hunks alone when they provide enough context. Do not read

whole source files merely to restate what changed.

• Only if a hunk is genuinely ambiguous, inspect at most one or two files and

only the relevant ranges.

1. Discover the repository's commit-message conventions from explicit contributor

guidance, templates, hooks, lint configuration, and other repository-local rules, then inspect recent commit history for established style. Exclude merge commits and automation-authored commits, such as github-actions[bot] baseline updates, from that evidence. Do not assume any file location, language, package manager, hook path, lint tool, subject format, scope vocabulary, or length limit. Do not use unstaged file contents as evidence.

1. Prefer enforceable configuration over documentation and documentation over recent

history. Treat history as a convention only when recent human-authored commits follow it consistently; when it is mixed, follow the style of commits already on the current branch, if any. Resolve the staged change's intent, then write a message that follows the discovered format and style. Use the fallback rules below only when the repository provides no convention.

1. Output the final message inside one fenced ```text block so it can be copied as-is.

Subject Line

• Follow the repository's required subject structure, capitalization, punctuation,

scope or type vocabulary, and length limit exactly.

• Include a type, scope, issue key, or other prefix only when repository rules or

established history support it. Never invent a scope or tag.

• If no convention exists, use a concise imperative summary in sentence case with no

trailing period. Keep it to 72 characters when practical.

• Describe the dominant purpose and observable effect of the staged changes. Do not

combine unrelated subjects or mention unstaged work.

Body

• Include a body when repository rules require one or when it adds important context.

Separate it from the subject with one blank line.

• Explain what changed and why, emphasizing behavior and intent rather than

restating the diff. Match the repository's prose, wrapping, bullet, and footer style; if none exists, wrap prose at about 72 columns.

• Group details only when that improves clarity for a multi-part change.
• Reference issues, pull requests, breaking changes, co-authors, or other metadata only

when justified by the staged diff, explicit user input, or your own contribution to the staged changes in the current session, and use the repository's established syntax. For example, add an assistant co-author trailer, spelled exactly as recent human-authored commits spell it, only when you helped produce the staged changes. Never fabricate identifiers or trailers.

• Mention validation commands only when evidenced and useful to future readers.

Fallback Example

Fix stale cache entries after updates
 
Invalidate affected entries when source records change so subsequent reads
return current data.

Rules

• Read the diff; do not echo it back.
• Consider only staged changes; never describe unstaged or working-tree changes.
• If nothing is staged, report that and stop; do not produce a message.
• Use repository-specific conventions only when supported by repository evidence.
• Do not infer motivation, issue references, validation results, or compatibility

effects that the staged diff and explicit user input do not establish.

• Never add CI-control directives such as [skip ci] unless the user explicitly asks.
• Do not run any mutating git command. Output the message and stop.