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?

:(

What does the file change for an agent that already reads the tree? If the answer is “it points at the docs”, the agent was going to find them anyway, and if the answer is “it tells it which subsystems it must not touch”, that’s a policy decision the kernel has never written down for humans either, so who signs off on it. What happens when AGENTS.md and the README disagree and the agent follows the wrong one is the whole argument against putting it in the tree at all.

Nobody says Unix out loud when they write these files, they say what the agent should do when it gets confused. Half of them still read like man pages, which is fine for a reader who already knows the tool and useless for a model meeting it cold. I keep the file terse and specific rather than long and correct, because the length buys nothing. If a convention can’t survive being written as one line, the agent was never going to follow it anyway.

deleted by creator

deleted by creator