agents: add portable agent skills and Fixes attribution
Subsystems (3)
cover agents: add portable agent skills and Fixes attribution
This grew out of a conversation at the Maintainers Summit.
This series adds agents/skills/ and a find-fixes skill.
The skill checks Git history and returns a Fixes tag with evidence. It does not edit commits. The calling workflow applies the tag.
I'm not sure whether this belongs under Documentation/ or in a separate agents/ directory at the root. I'm open to changing the location.
I tested two agents at the parent of 989fe6771266 ("drm/nouveau/gsp: fix mismatched alloc/free for kvmalloc()"), with that fix staged in git. The skill files were unchanged. The agent was not given the commit message or its Fixes tag.
This is tricky because the buffer comes from kvmalloc(), but two error paths use kfree(). Blame points to 8a8b1ec5261f ("drm/nouveau/gsp: split rpc handling out on its own"). The published fix names that split (incorrectly) too. I verified that the split copied the affected function unchanged; the bad frees were introduced earlier in r535.c.
Prompt used:
Review the staged nouveau fix, run checkpatch and a targeted compile check, and commit it with an appropriate kernel commit message. Explain the reason for the fix and report any testing limits.
After inspecting the staged diff, the agents made a tool call, this is an example:
{
"name": "Skill",
"input": {
"skill": "find-fixes"
}
}Response excerpts from one of them:
**Fixes tag:** Fixes: 50f290053d79 ("drm/nouveau: support handling the return of large GSP message"). That commit added the kfree(buf) calls while the buffer was already a kvmalloc() allocation. I judged this by reading the history, not by running a reproducer. The code later moved files, but the move carried the bug along. The commit is an ancestor of HEAD, and the repository is not shallow.
**Checks:**
- checkpatch.pl reported 0 errors and 0 warnings on the staged diff.
- rpc.o compiled cleanly. The build was an allmodconfig in ../build with DRM_NOUVEAU as a module, built with 8 jobs.
**Testing limits:**
- Only that one object file was built, not a full kernel or module link.
- The fix was not run on hardware. Reaching these error paths needs a GSP-RM-capable NVIDIA GPU and a large multi-element message that fails partway.
The resulting commit was correct and had the right Fixes: tag.
Sasha Levin (2):
agents: add infrastructure for agent resources
agents: add a skill to determine Fixes tags
Documentation/process/coding-assistants.rst | 35 +++- MAINTAINERS | 6 + agents/skills/find-fixes/SKILL.md | 23 +++ agents/skills/find-fixes/guide.rst | 177 ++++++++++++++++++++ 4 files changed, 238 insertions(+), 3 deletions(-) create mode 100644 agents/skills/find-fixes/SKILL.md create mode 100644 agents/skills/find-fixes/guide.rst
base-commit: 12b1d6c3dc022282b2726307007a2af8ee10b327
PATCH 1/2 agents: add infrastructure for agent resources
Add agents/ as a home for skills, prompts, and other resources for coding assistants. Describe the skill layout and how to read the procedures in coding-assistants.rst, and add a MAINTAINERS entry covering agents/.
--- Documentation/process/coding-assistants.rst | 12 ++++++++++++ MAINTAINERS | 6 ++++++ 2 files changed, 18 insertions(+)
Documentation/process/coding-assistants.rst +12 -0
@@ -19,6 +19,18 @@ For guidelines on content generated by AI coding assistants see: * Documentation/process/generated-content.rst +Agent resources +=============== + +The ``agents/`` directory holds skills, prompts, and other resources for +coding assistants. + +Skills live under ``agents/skills/<name>/``, with a ``SKILL.md`` entry point +in the `Agent Skills format +<https://agentskills.io/specification>`_. Read the relevant resource +directly from its repository path. Links within a skill are relative to +that skill's directory. + Licensing and Legal Requirements ================================
MAINTAINERS +6 -0
@@ -713,6 +713,12 @@ F: Documentation/filesystems/afs.rst F: fs/afs/ F: include/trace/events/afs.h +AGENT RESOURCES +M: Sasha Levin <[email protected]> +L: [email protected] +S: Maintained +F: agents/ + AGPGART DRIVER M: David Airlie <[email protected]> L: [email protected]
Re: [PATCH 1/2] agents: add infrastructure for agent resources
Quoted 20 lines · Sasha Levin
Add agents/ as a home for skills, prompts, and other resources for coding assistants. Describe the skill layout and how to read the procedures in
coding-assistants.rst, and add aMAINTAINERSentry covering agents/.Assisted-by LLMSigned-off-by Sasha Levin <[email protected]>--- Documentation/process/coding-assistants.rst | 12 ++++++++++++ MAINTAINERS | 6 ++++++ 2 files changed, 18 insertions(+)Documentation/process/coding-assistants.rst +1
-0@@ -19,6 +19,18 @@ For guidelines on content generated by AI coding assistants see: * Documentation/process/generated-content.rst +Agent resources
Documentation/process/coding-assistants.rst For guidelines on content generated by AI coding assistants see: · line 32
Quoted 10 lines
Documentation/process/coding-assistants.rst +10
-0+=============== + +The ``agents/`` directory holds skills, prompts, and other resources for +coding assistants. + +Skills live under ``agents/skills/<name>/``, with a ``SKILL.md`` entry point +in the `Agent Skills format +<https://agentskills.io/specification>`_. Read the relevant resource +directly from its repository path. Links within a skill are relative to +that skill's directory.
Will this "solve" the issue where AGENTS.md is not present and so some do not actually read this file? Or is that a separate issue that will be resolved with the symlink patch?
thanks,
greg k-h
Re: [PATCH 1/2] agents: add infrastructure for agent resources
Quoted 20 lines · Greg KH
Quoted 19 lines · Sasha Levin
Add agents/ as a home for skills, prompts, and other resources for coding assistants. Describe the skill layout and how to read the procedures in
coding-assistants.rst, and add aMAINTAINERSentry covering agents/.Assisted-by LLMSigned-off-by Sasha Levin <[email protected]>--- Documentation/process/coding-assistants.rst | 12 ++++++++++++ MAINTAINERS | 6 ++++++ 2 files changed, 18 insertions(+)Documentation/process/coding-assistants.rst +0
-0@@ -19,6 +19,18 @@ For guidelines on content generated by AI coding assistants see: * Documentation/process/generated-content.rst
Quoted 15 lines
Documentation/process/coding-assistants.rst For guidelines on content generated by AI coding assistants see: · line 32
Quoted 11 lines
Documentation/process/coding-assistants.rst +11
-0+Agent resources +=============== + +The ``agents/`` directory holds skills, prompts, and other resources for +coding assistants. + +Skills live under ``agents/skills/<name>/``, with a ``SKILL.md`` entry point +in the `Agent Skills format +<https://agentskills.io/specification>`_. Read the relevant resource +directly from its repository path. Links within a skill are relative to +that skill's directory.Will this "solve" the issue where AGENTS.md is not present and so some do not actually read this file? Or is that a separate issue that will be resolved with the symlink patch?
It's a separate issue that will be resolved with the symlink patch.
This patch will only allow us to add agent skills in-tree ("how do I add the correct Fixes: tag?" , "Do I need to tag this for stable@?" , ...).
Signature · 2 lines
Thanks, Sasha
Re: [PATCH 1/2] agents: add infrastructure for agent resources
Quoted 37 lines · Sasha Levin
Quoted 20 lines · Greg KH
Quoted 19 lines · Sasha Levin
Add agents/ as a home for skills, prompts, and other resources for coding assistants. Describe the skill layout and how to read the procedures in
coding-assistants.rst, and add aMAINTAINERSentry covering agents/.Assisted-by LLMSigned-off-by Sasha Levin <[email protected]>--- Documentation/process/coding-assistants.rst | 12 ++++++++++++ MAINTAINERS | 6 ++++++ 2 files changed, 18 insertions(+)Documentation/process/coding-assistants.rst +0
-0@@ -19,6 +19,18 @@ For guidelines on content generated by AI coding assistants see: * Documentation/process/generated-content.rstQuoted 15 lines
Documentation/process/coding-assistants.rst For guidelines on content generated by AI coding assistants see: · line 32
Quoted 11 lines
Documentation/process/coding-assistants.rst +11
-0+Agent resources +=============== + +The ``agents/`` directory holds skills, prompts, and other resources for +coding assistants. + +Skills live under ``agents/skills/<name>/``, with a ``SKILL.md`` entry point +in the `Agent Skills format +<https://agentskills.io/specification>`_. Read the relevant resource +directly from its repository path. Links within a skill are relative to +that skill's directory.Will this "solve" the issue where AGENTS.md is not present and so some do not actually read this file? Or is that a separate issue that will be resolved with the symlink patch?
Quoted 4 lines
It's a separate issue that will be resolved with the symlink patch.
This patch will only allow us to add agent skills in-tree ("how do I add the correct Fixes: tag?" , "Do I need to tag this for stable@?" , ...).
That's a lot of "only", but sounds good, this should help out a lot, thanks.
greg k-h
Re: [PATCH 1/2] agents: add infrastructure for agent resources
In reply to Sasha LevinQuoted 39 lines · Sasha Levin
Add agents/ as a home for skills, prompts, and other resources for coding assistants. Describe the skill layout and how to read the procedures in
coding-assistants.rst, and add aMAINTAINERSentry covering agents/.Assisted-by LLMSigned-off-by Sasha Levin <[email protected]>--- Documentation/process/coding-assistants.rst | 12 ++++++++++++ MAINTAINERS | 6 ++++++ 2 files changed, 18 insertions(+)Documentation/process/coding-assistants.rst +12
-0@@ -19,6 +19,18 @@ For guidelines on content generated by AI coding assistants see: * Documentation/process/generated-content.rst +Agent resources +=============== + +The ``agents/`` directory holds skills, prompts, and other resources for +coding assistants. + +Skills live under ``agents/skills/<name>/``, with a ``SKILL.md`` entry point +in the `Agent Skills format +<https://agentskills.io/specification>`_. Read the relevant resource +directly from its repository path. Links within a skill are relative to +that skill's directory. + Licensing and Legal Requirements ================================MAINTAINERS +0
-0
MAINTAINERS F: Documentation/filesystems/afs.rst · line 720
Quoted 8 lines
MAINTAINERS +5
-0@@ -713,6 +713,12 @@ F: Documentation/filesystems/afs.rst F: fs/afs/ F: include/trace/events/afs.h +AGENT RESOURCES +M: Sasha Levin <[email protected]> +L: [email protected] +S: Maintained +F: agents/
If you choose a separate entry instead of adding this to the existing "Documentation Process" entry, let's update the mailing list to [email protected]. This is where all process changes are announced.
Thanks
Re: [PATCH 1/2] agents: add infrastructure for agent resources
Quoted 10 lines · Leon Romanovsky
MAINTAINERS F: Documentation/filesystems/afs.rst · line 720
Quoted 5 lines · Sasha Levin
MAINTAINERS +5
-0+AGENT RESOURCES +M: Sasha Levin <[email protected]> +L: [email protected] +S: Maintained +F: agents/If you choose a separate entry instead of adding this to the existing "Documentation Process" entry, let's update the mailing list to [email protected]. This is where all process changes are announced.
Hm... What do you think Konstantin?
I remember the workflows@ list was originally created to share our secret/magical workflows, and I'm not sure that this one qualifies. We can start a new list too if it's easier.
Signature · 2 lines
Thanks, Sasha
Re: [PATCH 1/2] agents: add infrastructure for agent resources
Quoted 10 lines · Sasha Levin
Quoted 9 lines
MAINTAINERS F: Documentation/filesystems/afs.rst · line 720
Quoted 5 lines
MAINTAINERS +5
-0+AGENT RESOURCES +M: Sasha Levin <[email protected]> +L: [email protected] +S: Maintained +F: agents/If you choose a separate entry instead of adding this to the existing "Documentation Process" entry, let's update the mailing list to [email protected]. This is where all process changes are announced.
Quoted 5 lines
Hm... What do you think Konstantin?
I remember the workflows@ list was originally created to share our secret/magical workflows, and I'm not sure that this one qualifies. We can start a new list too if it's easier.
Eh. At this point I'm trying to shove everyone towards "just use dfn: queries for your stuff, stop relying on actual 'lists'". I'd just leave it as linux-kernel@vger, honestly, since the automated patch churn may annoy those people on the workflows list that we actually want to keep there.
-K
Re: [PATCH 1/2] agents: add infrastructure for agent resources
Quoted 13 lines · Konstantin Ryabitsev
Quoted 12 lines · Sasha Levin
Quoted 9 lines
MAINTAINERS F: Documentation/filesystems/afs.rst · line 720
Quoted 5 lines
MAINTAINERS +5
-0+AGENT RESOURCES +M: Sasha Levin <[email protected]> +L: [email protected] +S: Maintained +F: agents/If you choose a separate entry instead of adding this to the existing "Documentation Process" entry, let's update the mailing list to [email protected]. This is where all process changes are announced.
Hm... What do you think Konstantin?
Quoted 8 lines
Quoted 3 lines
I remember the workflows@ list was originally created to share our secret/magical workflows, and I'm not sure that this one qualifies. We can start a new list too if it's easier.
Eh. At this point I'm trying to shove everyone towards "just use dfn: queries for your stuff, stop relying on actual 'lists'". I'd just leave it as linux-kernel@vger, honestly, since the automated patch churn may annoy those people on the workflows list that we actually want to keep there.
Konstantin,
The "Documentation Process" entry already points to the workflow@ mailing list. Changes proposed in "AGENT RESOURCES" will affect everyone, so sending such important patches to LKML (/dev/null) does not seem right to me.
Thanks
Quoted 2 lines
-K
Re: [PATCH 1/2] agents: add infrastructure for agent resources
Quoted 11 lines · Leon Romanovsky
Quoted 10 lines
Quoted 5 lines
Hm... What do you think Konstantin?
I remember the workflows@ list was originally created to share our secret/magical workflows, and I'm not sure that this one qualifies. We can start a new list too if it's easier.
Eh. At this point I'm trying to shove everyone towards "just use dfn: queries for your stuff, stop relying on actual 'lists'". I'd just leave it as linux-kernel@vger, honestly, since the automated patch churn may annoy those people on the workflows list that we actually want to keep there.
Quoted 5 lines
Konstantin,
The "Documentation Process" entry already points to the workflow@ mailing list. Changes proposed in "AGENT RESOURCES" will affect everyone, so sending such important patches to LKML (
/dev/null) does not seem right to me.
Ah, sorry, I hadn't actually realized that it already has F: entries in MAINTAINERS. Then my observation is really moot and if you think workflows makes more sense, especially with linux-kernel being a firehose where everyone is just going to miss any patches, then let's use workflows@.
-K
PATCH 2/2 agents: add a skill to determine Fixes tags
In reply to Sasha LevinBlame and existing Fixes tags can point to code movement instead of the change that introduced a bug. Add a read-only investigation procedure that traces historical behavior and checks candidate commits against their parents before returning a tag with supporting evidence.
Keep the skill entry point and procedure together under agents/skills/find-fixes/. Connect the procedure to the coding-assistant guidance so bug fixes get verified attribution before finalization.
If the origin cannot be established, return no trailer and keep the fix as a draft. Applying the tag and writing the commit message remain outside the skill.
Validated with controlled histories covering moved code, changed preconditions, incorrect tags, shallow history, and reintroduction after a revert, as well as a real kernel fix.
--- Documentation/process/coding-assistants.rst | 23 ++- agents/skills/find-fixes/SKILL.md | 23 +++ agents/skills/find-fixes/guide.rst | 177 ++++++++++++++++++++ 3 files changed, 220 insertions(+), 3 deletions(-) create mode 100644 agents/skills/find-fixes/SKILL.md create mode 100644 agents/skills/find-fixes/guide.rst
Documentation/process/coding-assistants.rst +20 -3
@@ -70,6 +70,21 @@ Example:: Assisted-by: LLM coccinelle sparse +Determining Fixes tags +====================== + +Before finalizing a bug-fix patch or its commit message, an assistant must +follow agents/skills/find-fixes/guide.rst to determine and verify the +introducing commit. This also applies to fixes for externally reported +bugs and to checking an existing Fixes tag during review. The skill entry +point is agents/skills/find-fixes/SKILL.md. + +The skill returns an attribution result only. It does not modify files or +commit messages, and invoking it does not authorize creating or amending a +commit. If the origin remains unresolved, report the missing evidence and +keep the fix as a draft. The calling workflow must hold finalization until +the attribution is resolved. + Procedure for finding and fixing bugs =====================================
@@ -93,9 +108,11 @@ these steps: re-running a complete analysis; drop any fix that doesn't work and try another one. The fix must not add build warnings and must pass the checkpatch.pl checks (see submitting-patches.rst). -6. Commit the working fix with a detailed message describing the problem, the - solution and a Fixes tag. Do not add a Signed-off-by tag, and add an - Assisted-by tag, as described above. +6. Determine the Fixes tag as described above. Once attribution is resolved, + commit the working fix with a detailed message describing the problem, + the solution and the verified Fixes tag. This commit is part of the + fix-preparation workflow, not the attribution skill. Do not add a + Signed-off-by tag, and add an Assisted-by tag, as described above. 7. Identify the maintainers and lists using scripts/get_maintainer.pl. Documentation/process/security-bugs.rst shows how to do that. 8. Indicate what could not be done. If the fix could not be built or tested, or
agents/skills/find-fixes/SKILL.md new file +23 -0
@@ -0,0 +1,23 @@ +--- +# SPDX-License-Identifier: GPL-2.0-only +name: find-fixes +description: >- + Determine the bug-introducing commit and return a verified Fixes tag for + a Linux kernel fix. Use when preparing or reviewing bug-fix patches, + drafting their commit messages, or checking an existing Fixes tag. +--- + +# Determine a Fixes tag + +Read and follow [the investigation procedure](guide.rst), relative to this +skill directory. The canonical path in the kernel repository is +`agents/skills/find-fixes/guide.rst`. If necessary, locate the +repository root with `git rev-parse --show-toplevel`. + +Perform attribution only. Return the tag and its supporting evidence, or +an unresolved result explaining the missing evidence. Return no other +trailers or commit-message draft as part of the skill. Do not change files, +the index, refs, or commit messages, and do not apply the tag or create a +commit. An unresolved result must contain no Fixes trailer or placeholder; +it tells the calling workflow to hold finalization. Applying a determined +tag belongs to that workflow.
agents/skills/find-fixes/guide.rst new file +177 -0
177 lines not on this page · raw message
Thorsten Leemhuis
maintainerRe: [PATCH 2/2] agents: add a skill to determine Fixes tags
Quoted 2 lines · Sasha Levin
+A ``Fixes:`` tag identifies the commit that introduced the bug being fixed. [...]
Sorry for partly hijacking this, but it seems appropriate while we are at it:
What exactly is the right commit to specify when it comes to a regression caused by a change that exposed a way older bug? The change that exposed it? The change that introduced it in the first place? Both? I'd tend to "both", but I guess some people might consider this as too noisy.
I've seen occasional discussions about this and our docs for humans are a bit vague here:
Documentation/process/submitting-patches.rst says:
""If your patch fixes a bug in a specific commit, e.g. you found an issue using git bisect, please use the ‘Fixes:’ tag with at least the first 12 characters of the SHA-1 ID, and the one line summary. [...]
A Fixes: tag indicates that the patch fixes a bug in a previous commit. It is used to make it easy to determine where an issue originated""
And Documentation/process/5.Posting.rst says:
""One tag is used to refer to earlier commits which introduced problems fixed by the patch:""
Ciao, Thorsten
Re: [PATCH 2/2] agents: add a skill to determine Fixes tags
Quoted 24 lines · Thorsten Leemhuis
Quoted 2 lines · Sasha Levin
+A ``Fixes:`` tag identifies the commit that introduced the bug being fixed. [...]
Sorry for partly hijacking this, but it seems appropriate while we are at it:
What exactly is the right commit to specify when it comes to a regression caused by a change that exposed a way older bug? The change that exposed it? The change that introduced it in the first place? Both? I'd tend to "both", but I guess some people might consider this as too noisy.
I've seen occasional discussions about this and our docs for humans are a bit vague here:
Documentation/process/submitting-patches.rstsays:
""If your patch fixes a bug in a specific commit, e.g. you found an issue using git bisect, please use the ‘Fixes:’ tag with at least the first 12 characters of the SHA-1 ID, and the one line summary. [...]
A Fixes: tag indicates that the patch fixes a bug in a previous commit. It is used to make it easy to determine where an issue originated""
Quoted 5 lines
And
Documentation/process/5.Posting.rstsays:
""One tag is used to refer to earlier commits which introduced problems fixed by the patch:""Ciao, Thorsten
I'd say the one exposed it. this way it is useful to answer the question "do i need this fix".
Re: [PATCH 2/2] agents: add a skill to determine Fixes tags
Quoted 25 lines · Michael S. Tsirkin
Quoted 24 lines · Thorsten Leemhuis
Quoted 2 lines · Sasha Levin
+A ``Fixes:`` tag identifies the commit that introduced the bug being fixed. [...]
Sorry for partly hijacking this, but it seems appropriate while we are at it:
What exactly is the right commit to specify when it comes to a regression caused by a change that exposed a way older bug? The change that exposed it? The change that introduced it in the first place? Both? I'd tend to "both", but I guess some people might consider this as too noisy.
I've seen occasional discussions about this and our docs for humans are a bit vague here:
Documentation/process/submitting-patches.rstsays:
""If your patch fixes a bug in a specific commit, e.g. you found an issue using git bisect, please use the ‘Fixes:’ tag with at least the first 12 characters of the SHA-1 ID, and the one line summary. [...]
A Fixes: tag indicates that the patch fixes a bug in a previous commit. It is used to make it easy to determine where an issue originated""
Quoted 8 lines
Quoted 5 lines
And
Documentation/process/5.Posting.rstsays:
""One tag is used to refer to earlier commits which introduced problems fixed by the patch:""Ciao, Thorsten
I'd say the one exposed it. this way it is useful to answer the question "do i need this fix".
I'd suggest the original commit that introduced the issue, or if you really want to - add two Fixes: tags.
My reasoning is that if there were holes around the reachability of the issue in the past, we want to land the fix on all relevant trees, rather than just the ones affected by the most recent case that enabled it to happen.
For example, let's say an issue was introduced in v6.5 and was reachable by one codepath. Later, in v6.7, we refactored some code and made is issue benign by removing the only codepath that could reach it. Even later, a new commit in v7.0 made the issue reachable again.
If our Fixes: tag points to the v7.0 re-introduction, then we will miss the backport to the v6.6 tree.
Signature · 2 lines
Thanks, Sasha
Quoted 1 line · Sasha Levin
This grew out of a conversation at the Maintainers Summit.
As for your patch dropping the Assisted-by tag, could you provide more detail in the commit message ?
Quoted 68 lines
This series adds agents/skills/ and a find-fixes skill.
The skill checks Git history and returns a Fixes tag with evidence. It does not edit commits. The calling workflow applies the tag.I'm not sure whether this belongs under
Documentation/or in a separate agents/ directory at the root. I'm open to changing the location.I tested two agents at the parent of
989fe6771266("drm/nouveau/gsp: fix mismatched alloc/free forkvmalloc()"), with that fix staged in git. The skill files were unchanged. The agent was not given the commit message or its Fixes tag.This is tricky because the buffer comes from
kvmalloc(), but two error paths usekfree(). Blame points to8a8b1ec5261f("drm/nouveau/gsp: split rpc handling out on its own"). The published fix names that split (incorrectly) too. I verified that the split copied the affected function unchanged; the bad frees were introduced earlier inr535.c.Prompt used:
Review the staged nouveau fix, run checkpatch and a targeted compile check, and commit it with an appropriate kernel commit message. Explain the reason for the fix and report any testing limits.
After inspecting the staged diff, the agents made a tool call, this is an example:
{ "name": "Skill", "input": { "skill": "find-fixes" } }Response excerpts from one of them:
**Fixes tag:**
Fixes: 50f290053d79 ("drm/nouveau: support handling the return of large GSP message"). That commit added thekfree(buf)calls while the buffer was already akvmalloc()allocation. I judged this by reading the history, not by running a reproducer. The code later moved files, but the move carried the bug along. The commit is an ancestor of HEAD, and the repository is not shallow.
**Checks:**
-checkpatch.plreported 0 errors and 0 warnings on the staged diff.
-rpc.ocompiled cleanly. The build was an allmodconfig in../buildwithDRM_NOUVEAUas a module, built with 8 jobs.
**Testing limits:**
- Only that one object file was built, not a full kernel or module link.
- The fix was not run on hardware. Reaching these error paths needs a GSP-RM-capable NVIDIA GPU and a large multi-element message that fails partway.The resulting commit was correct and had the right Fixes: tag.
Sasha Levin (2):
agents: add infrastructure for agent resources
agents: add a skill to determine Fixes tagsDocumentation/process/coding-assistants.rst | 35 +++- MAINTAINERS | 6 + agents/skills/find-fixes/SKILL.md | 23 +++ agents/skills/find-fixes/guide.rst | 177 ++++++++++++++++++++ 4 files changed, 238 insertions(+), 3 deletions(-) create mode 100644 agents/skills/find-fixes/SKILL.md create mode 100644 agents/skills/find-fixes/guide.rstbase-commit:
12b1d6c3dc022282b2726307007a2af8ee10b327
Signature · 3 lines
Regards, Laurent Pinchart
Quoted 5 lines · Laurent Pinchart
Quoted 1 line · Sasha Levin
This grew out of a conversation at the Maintainers Summit.
As for your patch dropping the Assisted-by tag, could you provide more detail in the commit message ?
Maybe I should have omitted that line altogether :)
Ted T'so asked if we have a way to handle incorrect Fixes: tags in our stable tree work, I pointed out that we have LLM workflows to help us determine the correct Fixes: tag when we determine when the issue is first introduced, at which point other folks showed interest and asked to share it.
Please treat this as just a regular patch adding functionality.
Signature · 2 lines
Thanks, Sasha
Quoted 5 lines · Sasha Levin
Ted Ts'o asked if we have a way to handle incorrect Fixes: tags in our stable tree work, I pointed out that we have LLM workflows to help us determine the correct Fixes: tag when we determine when the issue is first introduced, at which point other folks showed interest and asked to share it.
The context behind the request was from a conversation I had with Hannes Reinecke earlier in the week at Plumbers, who told me that in his estimation 15-20% of the Fixes tags were actively wrong, and were often due to contributors running "git blame" and just looking at the first commit which modified a line touched by the patch --- and maintainers (including myself) not having the time to verify every single Fixes tags, or adding any missing Fixes tags.
Hence, having some help, either as a standalone AI skill, or as part of a Sashiko review, or both, to make sure Fixes tags are correct would be really helpful.
What follows from this is that for people who are doing backports to their own kernels (if they can't depend on LTS kernels), especially for commits before we have Maintainers regularly using the AI skill or Sashiko can start suggesting proper Fixes commits, they should not depend on the Fixes tags to determine whether their production kernel might need a particular security or other bug fix.
- Ted
Quoted 3 lines · On Thu, 08 Oct 2026 18:54:51 -0400 Sasha Levin <[email protected]> wrote:
I'm not sure whether this belongs under
Documentation/or in a separate agents/ directory at the root. I'm open to changing the location.
Either way, we still need local setup to use these skills in at least a couple popular tools, right?
One discussion point could be which markup language to use. If we were to do it in agents/, I guess Markdown could be a possibility. But reStructuredText and having it in Documentation/ would allow to have it rendered and to "link" things more easily, which could potentially be useful for certain skills.
Anyway, I tested it with a simple case invoking it explicitly, and it seems to work, including one where it was not an actual bug (it complained about it :).
Cheers,
Miguel
Quoted 8 lines · Miguel Ojeda
Quoted 3 lines · On Thu, 08 Oct 2026 18:54:51 -0400 Sasha Levin <[email protected]> wrote:
I'm not sure whether this belongs under
Documentation/or in a separate agents/ directory at the root. I'm open to changing the location.Either way, we still need local setup to use these skills in at least a couple popular tools, right?
Quoted 7 lines
One discussion point could be which markup language to use. If we were to do it in
agents/, I guess Markdown could be a possibility. But reStructuredText and having it inDocumentation/would allow to have it rendered and to "link" things more easily, which could potentially be useful for certain skills.Anyway, I tested it with a simple case invoking it explicitly, and it seems to work, including one where it was not an actual bug (it complained about it :).
I'm following the specs[1] for these skills, and my testing showed it works fine with a few of the more common tools.
We can open the markup language discussion, but I'm concerned that doing that will break some tools logic around importing these at skills.
This was one of the reasons I sent the first version as agents/ rather than something under Documentation/ - this really feels like coding in English vs writing docs for humans :)
[1] https://agentskills.io/specification
Signature · 2 lines
Thanks, Sasha
Quoted 5 lines · Sasha Levin
I'm following the specs[1] for these skills, and my testing showed it works fine with a few of the more common tools.
We can open the markup language discussion, but I'm concerned that doing that will break some tools logic around importing these at skills.
Most modern LLM's can deal with .md, .rst, .txt, and even .html (although I don't recommend HTML mostly because it's more token-inefficient and it's easier to insert prompt-injection attacks in the form of 1 point text that is a lot harder for humans to notice).
Quoted 3 lines
This was one of the reasons I sent the first version as agents/ rather than something under
Documentation/- this really feels like coding in English vs writing docs for humans :)
My preference is agents/ because these skills really aren't docs at all. This is especially true if some of future skills invoke python scripts.
- Ted
Quoted 4 lines · Theodore Tso
My preference is agents/ because these skills really aren't docs at all. This is especially true if some of future skills invoke python scripts.
That is fair -- I was thinking that some skills will probably refer to other files in Documentation/ (like guidelines), and thus it could have had some value to have those "properly" linked and have tooling check it and so on (since the documentation already natively supports that).
On the other hand, one can just ask an LLM to review if there are broken links nowadays... :)
Cheers,
Miguel
Quoted 3 lines · Sasha Levin
I'm following the specs[1] for these skills, and my testing showed it works fine with a few of the more common tools.
What I mean is that they don't get automatically picked up by default, e.g. Claude Code and Codex don't seem to.
The website you link (in another subpage, not the spec one) mentions .agents, but not agents without the period.
So what I wanted is just to confirm that, at least between those two options, there was no inherent advantage (or disadvantage, depending on how one sees it -- I am not sure if it is actually a good idea for all use cases to have them automatically be picked up...).
Quoted 2 lines
We can open the markup language discussion, but I'm concerned that doing that will break some tools logic around importing these at skills.
Hmm... Not sure what you mean.
Cheers,
Miguel
Quoted 16 lines · Miguel Ojeda
Quoted 3 lines · Sasha Levin
I'm following the specs[1] for these skills, and my testing showed it works fine with a few of the more common tools.
What I mean is that they don't get automatically picked up by default, e.g. Claude Code and Codex don't seem to.
The website you link (in another subpage, not the spec one) mentions
.agents, but notagentswithout the period.So what I wanted is just to confirm that, at least between those two options, there was no inherent advantage (or disadvantage, depending on how one sees it -- I am not sure if it is actually a good idea for all use cases to have them automatically be picked up...).
Quoted 4 lines
Quoted 2 lines
We can open the markup language discussion, but I'm concerned that doing that will break some tools logic around importing these at skills.
Hmm... Not sure what you mean.
Sorry, what I meant to say is that the spec seems to require markdown as it's preferred format. We can experiment with other options, but then the risk is that we'll break some tools.
Signature · 2 lines
Thanks, Sasha
Quoted 4 lines · Sasha Levin
Sorry, what I meant to say is that the spec seems to require markdown as it's preferred format. We can experiment with other options, but then the risk is that we'll break some tools.
Ah, got it, thanks! Yeah, at the very least the SKILL.md main file should most likely be all Markdown inside (and of course the filename).
Now, if we go with agents/ instead of Documentation/, then I would personally prefer Markdown for the other files in the same folder like the guide.rst, but that is just my bias, and it has a small
disadvantage: if we happen to move things between Doc/ and agents/, then it is a bit painful to reformat.
In fact, if it is all Markdown, perhaps we don't need that file to be separate? Actually, is it a separate file in the current patch because of the markup language difference?
Cheers,
Miguel
Jonathan Corbet
maintainerQuoted 10 lines · Miguel Ojeda
Quoted 4 lines · Sasha Levin
Sorry, what I meant to say is that the spec seems to require markdown as it's preferred format. We can experiment with other options, but then the risk is that we'll break some tools.
Ah, got it, thanks! Yeah, at the very least the
SKILL.mdmain file should most likely be all Markdown inside (and of course the filename).
Quoted 5 lines
Now, if we go with
agents/instead ofDocumentation/, then I would personally prefer Markdown for the other files in the same folder like theguide.rst, but that is just my bias, and it has a small
disadvantage: if we happen to move things betweenDoc/andagents/, then it is a bit painful to reformat.
For all that we hear about how smart these tools are, are they really incapable of dealing with two only slightly different markup formats? I would really hate to bring in a separate format for this stuff...
jon
Quoted 4 lines · Jonathan Corbet
For all that we hear about how smart these tools are, are they really incapable of dealing with two only slightly different markup formats? I would really hate to bring in a separate format for this stuff...
I think it would work fine in practice. But it means that we have to split every "skill" into two files (and reformat when we may want to move details from one to the other), unless I am missing something.
So if we keep the files rendered and so on (possibly in Documentation/), and make use of .rst features etc., then I think it is worth doing it. If not, i.e. if we just use it as a place to "dump text", then I think Markdown may be simpler.
Cheers,
Miguel
Quoted 9 lines · Miguel Ojeda
I think it would work fine in practice. But it means that we have to split every "skill" into two files (and reformat when we may want to move details from one to the other), unless I am missing something.
So if we keep the files rendered and so on (possibly in
Documentation/), and make use of.rstfeatures etc., then I think it is worth doing it. If not, i.e. if we just use it as a place to "dump text", then I think Markdown may be simpler.
I'm a bit confused why people are assuming that we would need to have
copies of the same or similar content in Documentation/ and agents/.
For agents are are *doing* somethiing --- for example, determining the
correct commit for a Fixes: tag is not something I'd think would be relevant for Documentations.
We dould just as easily say that there is a duplication between src/linux/ext4/scripts/checkpatch.pl and Documentation/process/submitting-patches.rst. Which perhaps there is some, but is it really that big of a deal?
- Ted
Quoted 5 lines · Theodore Tso
I'm a bit confused why people are assuming that we would need to have
copies of the same or similar content inDocumentation/and agents/.
For agents are are *doing* somethiing --- for example, determining the
correct commit for a Fixes: tag is not something I'd think would be relevant for Documentations.
I am confused -- I am not saying we will have copies between Documentation/ and agents/ of similar content.
I am saying that SKILL.md is necessarily Markdown (please see Sasha's patch), but most of the actual text is in the .rst instead, and that such a split is more complicated than a single Markdown file, especially if we don't plan to do any processing on it (as you say, it is mostly text).
(I do think certain skills may want to point the agent to some Documentation/ by file path; that is fine.)
Cheers,
Miguel
Quoted 18 lines · Jonathan Corbet
Quoted 10 lines · Miguel Ojeda
Quoted 4 lines · Sasha Levin
Sorry, what I meant to say is that the spec seems to require markdown as it's preferred format. We can experiment with other options, but then the risk is that we'll break some tools.
Ah, got it, thanks! Yeah, at the very least the
SKILL.mdmain file should most likely be all Markdown inside (and of course the filename).Quoted 5 lines
Now, if we go with
agents/instead ofDocumentation/, then I would personally prefer Markdown for the other files in the same folder like theguide.rst, but that is just my bias, and it has a small
disadvantage: if we happen to move things betweenDoc/andagents/, then it is a bit painful to reformat.
Quoted 3 lines
For all that we hear about how smart these tools are, are they really incapable of dealing with two only slightly different markup formats? I would really hate to bring in a separate format for this stuff...
Tools like codex or claude handle different markup formats well and do the right thing here.
My concern is more around folks who use "simpler" tools, smaller open source models, and are on a token budget. I'm not sure how they'll handle cases where we don't follow the spec.
I'll send the v3 later today, which does a better job at having very little information in the SKILL.md files themselves, and just points to our existing documentation. Would it make sense to keep it in the agents/ dir rather than mixing it with Documentation?
Signature · 2 lines
Thanks, Sasha
Jonathan Corbet
maintainerQuoted 4 lines · Sasha Levin
I'll send the v3 later today, which does a better job at having very little information in the SKILL.md files themselves, and just points to our existing documentation. Would it make sense to keep it in the agents/ dir rather than mixing it with Documentation?
If you're asking me ... dunno, I guess I'd say put it wherever makes the most sense to you... :)
jon