git-commit-linux-style

name	git-commit-linux-style
description	Create a well formatted and useful commit message

git commit, but as if Linus Torvalds would read your commit

Draft or create a Git commit using a proper an descriptive commit message as if the point of the commit was to send it to the Linux mailing list. (Spoiler: it will not be sent to the Linux mailing list, but the idea is to apply the same quality rules and conventions).

When to use this skill

• You have been requested to draft or create a commit message.
• You are iteratively working on a checkpoint commit during a long work session.
• The user says something like "draft a commit".

Unless the user specifically asks to make the commit imperatively, assume that the skill is running in dry run mode, where you will only draft the commit message but not actually perform the commit.

If the user says "make a commit message", then use this skill without dry run mode, actually making the commit.

Forbidden actions

• You will NOT update the staging area.
• You will NOT git push on your own.

Additionally, if you are in dry-run mode, you will NOT actually perform the commit, just draft the contents and generate it as output, wrapped in a Markdown code block to make it easy to copy.

How to pick the commit message

Run git status --short to see if there are any actual staged changes. If there are no staged changes, just report an error and bail out, because there is nothing to commit.

Under no circumstances you should assume that anything not in the staging area, even if the workdir is dirty, is part of the following commit. It is good to point out that there are unstaged changes, including when nothing is staged or if the Git repository is clean and not modified.

When there are actual changes, run git diff --staged and make a small analysis to see what the diff actually does.

Commit conventions

Follow the conventions described in the chapter 'Posting patches' of the Linux Kernel Guide for Kernel Development. Here are some quotes of the chapter with additional comments made by me:

Each patch needs to be formatted into a message which quickly and clearly communicates its purpose to the rest of the world. To that end, each patch will be composed of the following.

That is the intention. Sounds correct.

A one-line description of what the patch does. This message should be enough for a reader who sees it with no other context to figure out the scope of the patch; it is the line that will show up in the “short form” changelogs. This message is usually formatted with the relevant subsystem name first, followed by the purpose of the patch. For example:

gpio: fix build on CONFIG_GPIO_SYSFS=n

Clearly they are talking about the first line of the commit message. According to the standard conventions, this line should have no more than 50 characters.

Do not add a subsystem name first, unless clearly the project we are working in has things that look like subsystems.

A blank line followed by a detailed description of the contents of the patch. This description can be as long as is required; it should say what the patch does and why it should be applied to the kernel.

Following the conventions, the rest of the commit message must always be formatted so that lines are wrapped to 71 characters.

The summary line should describe the effects of and motivation for the change as well as possible given the one-line constraint. The detailed description can then amplify on those topics and provide any needed additional information. If the patch fixes a bug, cite the commit which introduced the bug if possible (and please provide both the commit ID and the title when citing commits).

That is correct. A good commit message will help anyone going bug hunting. This includes LLMs when they have to look for non-existant context. Still, should be helpful and readable, so apply sensible criteria to allow humans with less capabilities to also understand the changelog without having to actually read line by line the patch.

Co-authoring

Always add one trailing line in your commit message to co-author the LLM who wrote the code, separated by a blank line. For example:

Co-authored-by: Codex <[e-mail]>
Co-authored-by: Cursor <[e-mail]>
Co-authored-by: Claude Sonnet <[e-mail]>

Or, if you know exactly which model you are, or you can infer it from your harness, you can use it as the exact author name:

Co-authored-by: openai/gpt-5.5-high <[e-mail]>
Co-authored-by: cursor/kimi-k2.5 <[e-mail]>