From: Sasha Levin <sashal@kernel.org>
To: Kees Cook <kees@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
workflows@vger.kernel.org, ksummit@lists.linux.dev,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Mark Brown <broonie@kernel.org>, Theodore Ts'o <tytso@mit.edu>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Leon Romanovsky <leon@kernel.org>,
Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
Thorsten Leemhuis <linux@leemhuis.info>,
"Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH v2 0/5] agents: add skills for Fixes tags, stable tags, similar bugs, and commit messages
Date: Tue, 13 Oct 2026 07:22:29 -0400 [thread overview]
Message-ID: <as4UdYVO2JbSx9gn@laps> (raw)
In-Reply-To: <202610122047.A9E381A@keescook>
On Mon, Oct 12, 2026 at 08:48:48PM -0700, Kees Cook wrote:
>On Mon, Oct 12, 2026 at 04:47:14PM -0600, Jonathan Corbet wrote:
>> Sasha Levin <sashal@kernel.org> writes:
>>
>> > At the Maintainers Summit, Ted asked whether the stable trees have a way
>> > to deal with incorrect Fixes tags. Hannes estimated that 15-20% of them
>> > are wrong, often because the author ran git blame and took the first
>> > commit that touched the line [1]. We use LLM workflows to find the
>> > commit that actually introduced a bug, and others asked us to share
>> > them.
>> >
>> > This series adds them as agent skills under agents/skills/, together
>> > with a skill for writing commit messages:
>>
>> Time to argue for a more fuchsia shade of mauve without actually getting
>> into the substance of what you're doing...:)
>>
>> I wonder about the top-level agents/ directory. If we regard this
>> material as documentation, perhaps the "skills" should go there too? As
>> readable text, they might just help to improve human skills as well,
>> assuming we think we still need those. Under Documentation, they could
>> be built into the rendered docs and made more widely available.
>>
>> Otherwise, if this is primarily a development tool, perhaps under tools/
>> makes sense?
>>
>> I lack strong opinions here, but figured I would ask the question.
>
>I was expecting this to appear under Documentation/. The agents are
>designed to read human text, so let's make it at least passingly
>sensible for humans to read too. :)
What sucks here is that these prompts aren't very human readable. They are
overly verbose, they assume being able to remember a whole bunch of small
instructions, and target specific issues that we're observing with these
agents.
I get why Documentation/ makes sense (it's not code per-se), but I could also
argue similarily for tools/ :)
Either way, I don't really think it matters to me, and will happily move it to
Documentation/agents/ unless someone else chimes in with a reason NOT to...
--
Thanks,
Sasha
prev parent reply other threads:[~2026-10-13 11:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 21:34 [PATCH v2 0/5] agents: add skills for Fixes tags, stable tags, similar bugs, and commit messages Sasha Levin
2026-10-12 21:34 ` [PATCH v2 1/5] agents: add infrastructure for agent resources Sasha Levin
2026-10-12 21:34 ` [PATCH v2 2/5] agents: add a skill to determine Fixes tags Sasha Levin
2026-10-13 3:55 ` Kees Cook
2026-10-13 4:42 ` Michael S. Tsirkin
2026-10-12 21:34 ` [PATCH v2 3/5] agents: add a skill to determine stable tags Sasha Levin
2026-10-13 3:59 ` Kees Cook
2026-10-13 11:30 ` Sasha Levin
2026-10-12 21:34 ` [PATCH v2 4/5] agents: add a skill to find other instances of a fixed bug Sasha Levin
2026-10-13 4:02 ` Kees Cook
2026-10-13 11:14 ` Sasha Levin
2026-10-12 21:34 ` [PATCH v2 5/5] agents: add a skill to write commit messages Sasha Levin
2026-10-12 22:47 ` [PATCH v2 0/5] agents: add skills for Fixes tags, stable tags, similar bugs, and " Jonathan Corbet
2026-10-13 3:48 ` Kees Cook
2026-10-13 11:22 ` Sasha Levin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=as4UdYVO2JbSx9gn@laps \
--to=sashal@kernel.org \
--cc=broonie@kernel.org \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=kees@kernel.org \
--cc=konstantin@linuxfoundation.org \
--cc=ksummit@lists.linux.dev \
--cc=laurent.pinchart@ideasonboard.com \
--cc=leon@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=mst@redhat.com \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.org \
--cc=tytso@mit.edu \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.