Re: [PATCH v3 4/7] agents: add a skill to determine Fixes tags

[Bradley Morgan <brads@mainlining.org>]

On 16 October 2026 16:28:24 BST, Sasha Levin <sashal@kernel.org> wrote:
>Blame and existing Fixes tags can point to code movement instead of the
>change that introduced a bug. Add a skill that sends the agent to the
>description of the Fixes: tag in submitting-patches.rst, and adds the
>checks agents tend to skip: pinning down the bug before searching,
>following the code past moves and refactors, comparing each candidate
>with its parent, handling merges, reverts, backports and bugs older than
>the Git history, and taking the commit ID and subject from the commit
>rather than typing them.
>
>If the origin cannot be established, the skill returns no tag. Point the
>bug-fix procedure in coding-assistants.rst at the skill.

Reviewed-by: Bradley Morgan <brads@mainlining.org>


>
>Assisted-by: LLM
>Signed-off-by: Sasha Levin <sashal@kernel.org>
>---
> Documentation/process/coding-assistants.rst |  9 +++--
> agents/skills/find-fixes/SKILL.md           | 39 +++++++++++++++++++++
> 2 files changed, 46 insertions(+), 2 deletions(-)
> create mode 100644 agents/skills/find-fixes/SKILL.md
>
>diff --git a/Documentation/process/coding-assistants.rst b/Documentation/process/coding-assistants.rst
>index 1efc7b08f09f8..ddff951856dce 100644
>--- a/Documentation/process/coding-assistants.rst
>+++ b/Documentation/process/coding-assistants.rst
>@@ -33,6 +33,11 @@ or send mail. A skill returns its result with the evidence for it, or says what
> is missing. Do not fill a missing result with a guess or a placeholder,
> and do
> not finalize the work until it is resolved.
> 
>+The following skills are available:
>+
>+* agents/skills/find-fixes/SKILL.md determines the Fixes tag of a bug fix, or
>+  checks an existing one.
>+
> Licensing and Legal Requirements
> ================================
> 
>@@ -96,8 +101,8 @@ these steps:
>    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.
>+   solution and a Fixes tag determined with the find-fixes 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
>diff --git a/agents/skills/find-fixes/SKILL.md b/agents/skills/find-fixes/SKILL.md
>new file mode 100644
>index 0000000000000..b5dd51d66adb7
>--- /dev/null
>+++ b/agents/skills/find-fixes/SKILL.md
>@@ -0,0 +1,39 @@
>+---
>+# 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 the description of the Fixes: tag in
>+Documentation/process/submitting-patches.rst. It says which commit to name
>+and how to format the tag. Follow the rules for skills in
>+Documentation/process/coding-assistants.rst.
>+
>+- First establish exactly which bug the fix addresses: the failure, how it is
>+  triggered and the code involved. Trace only that bug. If the search leads
>+  to a different bug or subsystem, go back to the fix.
>+- Name a commit from the history of the tree the fix applies to. A stable
>+  backport of that commit, or a commit that exists only on another branch, is
>+  not a valid tag.
>+- Treat blame output, an existing Fixes tag and a bisection result as leads,
>+  not answers. Follow the code back through moves, renames, file splits and
>+  older implementations to the commit that made it wrong.
>+- For each candidate, compare the commit with its parent and explain why the
>+  code was correct before and wrong after. Keep apart the commit that added
>+  the code, the commit that made it wrong, and a later commit that only made
>+  the bug reachable.
>+- Check each parent of a merge, whether the bug was reverted and later
>+  reintroduced, and whether a backport differs from its upstream commit.
>+- If the bug is already present in the first commit of the Git history, name
>+  that commit: Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2"). Confirm that the bug
>+  exists there instead of using it as a default. A shallow clone boundary is
>+  not an introducing commit; report the limit instead.
>+
>+Take the commit ID and subject from the commit itself instead of typing them.
>+Return the tag with that explanation and the candidates you rejected. If the
>+origin cannot be established, return no tag and say what is missing.
>

--- Thanks!
"I'm not a very positive person" - Linus torvalds