Kernel developers draft AI skills for Fixes tags and stable backports
Sasha Levin and Ted Ts'o want coding assistants to report, not guess, while Andrew Morton asks that the same docs force a plain account of who a bug hurts.
Linux kernel developers are proposing a home in the tree for instructions that coding assistants must follow when they help with bug fixes. The series, mostly from stable maintainer Sasha Levin and updated by ext4 maintainer Theodore Ts'o, adds skills for choosing a Fixes tag, deciding whether a fix belongs in stable, hunting for the same defect elsewhere, and writing the commit message. Ts'o also added a skill for writing KUnit tests, which he has been using to cover ext4, and asked how well the prompts hold up on Claude Code after trying them with Gemini.
The point is to stop assistants from inventing the parts of kernel process they routinely get wrong. Blame and an existing Fixes tag can point at a move or a refactor rather than the change that introduced the bug. Stable tags are often omitted or aimed too broadly. Left alone, an assistant will try to audit the whole tree by reading it, and commit text tends to run long. Linus Torvalds has already asked that LLM-written pull-request text be shorter and written in the imperative. The skills point at the existing process documents and add the checks models skip. If the origin of a bug, or the stable decision, cannot be established, the skill returns no tag rather than a guess. They inspect and report: they do not change files, create commits, or send mail, except where the task itself is to write code or tests. References to an Assisted-by trailer were dropped after the Maintainers Summit.
Review turned up the same class of problem the skills are meant to catch. Andrew Morton spotted a swapped-argument example in the KUnit skill that an LLM had produced. Mauro Carvalho Chehab asked that the testing guidance also cover the kernel's Python documentation tests, which exist to stop kernel-doc regex changes from silently breaking the docs build.
The sharper exchange was about stable. Morton wants every fix to say, in plain terms, what a user can actually observe when the bug hits, and he wants that rule written where an LLM will read it. Levin agreed, and offered to put the same sentence in the human patch-submission guide. He also explained why automated fixers have been leaving off the stable tag: until recently the rules treated a bug as theoretical unless someone could show a real hit or a reproduction, which most bots cannot do even when the defect clearly affects users. That wording has been dropped. Morton's reply was that humans do not read the documents either, but a written rule at least gives him something to point them at, and something for a downstream maintainer staring at a screen of generated text when deciding whether a backport is worth taking.