A Tag Problem Worth Solving
Kernel maintainers rely on `Fixes:` tags to trace which commit introduced a bug, and those tags routinely point to the wrong place. Stable and long-term support co-maintainer Sasha Levin has flagged the issue, and Ted Ts’o has raised similar concerns. Hannes Reinecke puts the error rate at 15 to 20 percent of all `Fixes:` tags, which is high enough that fixes can land on the wrong branches or bugs can go unpatched entirely.
Levin’s proposed fix is a new `agents/` directory that would store skills, prompts, and other resources built specifically for AI coding assistants, submitted to mailing lists as a two-patch series. The structure is deliberately rigid:
- Each skill gets its own folder under agents/skills/
- A SKILL.md file defines the skill’s entry point, following the Agent Skills format
- Internal links within a skill stay relative to its own folder
- The skill’s layout and usage get documented in the kernel’s coding assistants document
A new MAINTAINERS entry would cover the directory, and assistants would read these resources directly from their repository path rather than from an external source.
How the First Skill Would Work
The proposal’s test case is a skill called `find-fixes`, which verifies which commit actually introduced a bug and returns a proposed `Fixes:` tag with supporting evidence, leaving the commit itself untouched. Its logic, laid out in a guide.rst file, is more involved than a simple git blame. The agent traces candidate commits, compares each against its parent, and tries to separate the code addition from the actual defect and from any later change that merely exposed it. For backported fixes, it also checks whether the bug originated in the original change or crept in during adaptation to an older kernel, while accounting for merges, reverts, and incomplete history. When the origin isn’t clear, it returns no tag at all, just a list of candidates and what’s missing, and the fix stays a draft until someone resolves it.
Still an Open Question
The `agents/` directory proposal remains under discussion, and it follows Levin’s earlier work on a kernel-wide AI coding assistants policy and a proposed killswitch for AI tooling. Even the basic location is unsettled, with Levin unsure whether these files belong under Documentation or a standalone agents/ directory at the root. Greg Kroah-Hartman pushed on a more fundamental point: nothing in the proposal stops a tool from simply ignoring the guidance. Levin agreed and said that enforcement would need a separate symlink patch to address.
Structure Without Enforcement
A well-organized skills directory is useful, but it solves a documentation problem, not a compliance one. Nothing in this proposal requires any AI tool to actually read `agents/skills/`, and Kroah-Hartman’s question about tools skipping kernel guidance went unanswered within the thread itself. Compare that to how enterprise AI agent adoption numbers get reported elsewhere, usually as a straightforward usage percentage with little scrutiny of whether the tools are actually following the rules set for them. The kernel community’s instinct to treat “will the agent comply” as a separate, unsolved problem is the more honest framing, and one other industries adopting AI tooling would do well to borrow.
Follow Hashlytics on Bluesky, Facebook, LinkedIn, Telegram and X to Get Instant Updates
