What would end up in it, though? The kernel has a lot of conventions that are enforced by reviewers rather than written down anywhere. An AGENTS.md that only restates the documented ones saves nobody anything. I doubt the maintainers want to write down the stuff they currently catch by instinct, like which subsystem takes which kind of patch. If they don’t, the file becomes a style guide nobody reads, same as the coding style doc is for most first-time contributors.
An AGENTS.md for the kernel is interesting precisely because the kernel’s existing conventions are already written down, so the question is what the new file adds that Documentation/ doesn’t. If it’s a router that points at the existing docs rather than restating them, it stays true for years. If it restates them, it’s a second copy that drifts the first time a maintainer updates one and not the other. So what goes in it that isn’t already in Documentation/process?
deleted by creator
deleted by creator
I would not count on the kernel tree being the right home at all. Reviewer attention was always the thing this project ran short of first. I doubt a directory of agent skills sitting next to drivers would ever get the attention it needs. For that to hold you’d need the skills to be something a subsystem maintainer would ever want to read.