On Wed, Sep 02, 2026 at 02:42:15PM +0100, Alex Bennée wrote:
> Paolo Bonzini <[email protected]> writes:
> 
> > Humans seem to be extremely unreliable in following rules around this,
> > even after being told directly and repeatedly. Telling agents what to
> > do seems to yield better results.
> >
> > This document is based on GStreamer's AGENTS.md file, as of its commit
> > d08375499c279a56c0e77c928fbeae0d80cdf937.  However, GStreamer's agent
> > instructions are "effective" enough to require an explicit carve-out
> > for maintainers.  I actually believe that such a carve-out is a sign of
> > going too far, especially given the good quality of some suspected-AI
> > contributions we've received.
> >
> <snip>
> > diff --git a/AGENTS.md b/AGENTS.md
> > new file mode 100644
> > index 00000000000..8fb96ebfc38
> > --- /dev/null
> > +++ b/AGENTS.md
> > @@ -0,0 +1,100 @@
> > +# Agent Guidelines for the QEMU Project
> > +
> > +QEMU is a cross-platform emulator and virtualizer. Due to the complexity
> > +of the domain and codebase, and the interactions therein, the QEMU
> > +project relies extensively on the effort of **human reviewers**, which
> > +is **a scarce resource**.
> > +
> > +There are strictly-enforced rules for you, the agent, to participate in the
> > +project.
> > +
> > +## Interactions with maintainers must be human-human
> > +
> > +The QEMU project has strict rules on what AI-generated material can
> > +reach the maintainers.
> > +
> > +### No automated posting
> > +
> > +- Agents **must not** use any API, CLI, or web UI automation to:
> > +  - Interact with the QEMU mailing lists
> > +  - Create, edit, or close **issues ("work items")**
> 
> The others I'm fine with but I currently use an agent to do triage on
> un-tagged issues. It only updates labels and occasionally posts a
> comment when more information or a human input is required.

Yes, me too.


I think it's mostly writing the text of the issue that we are concerned
about?

So just limit creating issues?


> That said with a minimal patch to agents to inform it of the
> qemu-issue-triage skill Gemini didn't stop itself:
> 
>   The `qemu-issue-triage` skill is now loaded. Please let me know how you 
> would like me to assist with triaging QEMU GitLab issues, keeping in mind 
> that all triage tasks must be performed by spawning dedicated sub-agents as 
> per the QEMU project's strict rules.
>   triage 4930, 4391, 4392, 4393, 4394, 4395
> 
>   qemu-helper-agent: triage issue 4930 (2 steps, 21.7K / 1M) ✅ 8s
> 
>   qemu-helper-agent: triage issue 4391 (6 steps, 31.9K / 1M) ✅ 30s
> 
>   qemu-helper-agent: triage issue 4392 (5 steps, 27K / 1M) ✅ 35s
> 
>   qemu-helper-agent: triage issue 4393 (5 steps, 27.5K / 1M) ✅ 47s
> 
>   qemu-helper-agent: triage issue 4394 (5 steps, 26K / 1M) ✅ 51s
> 
>   qemu-helper-agent: triage issue 4395 (4 steps, 25.7K / 1M) ✅ 15s
> 
>   The requested GitLab issues have been triaged using parallel sub-agents. 
> Here is a summary of the outcomes:
> 
>   *   **#4930**: Not found (404).
>   *   **#4391**: Triaged and labeled as `Kind::Bug`, `Workflow::Triaged`, 
> `Binary ➤ qemu-img`, `Storage`, `HostArch ➤ 32bit`, `TestCase`.
>   *   **#4392**: Triaged and labeled as `Kind::Security`, `Device ➤ USB`, 
> `Migration`, `TestCase`, `Workflow::Triaged`.
>   *   **#4393**: Triaged and labeled as `Kind::Security`, `Device ➤ VirtIO`, 
> `Device ➤ Network`, `Audit Tooling::Sanitizer`, `TestCase`, 
> `Workflow::Triaged`.
>   *   **#4394**: Triaged and labeled as `Kind::Bug`, `Target ➤ X86`, 
> `HostArch ➤ AArch64`, `TestCase`, `Workflow::Triaged`.
>   *   **#4395**: Triaged and labeled as `Kind::Bug`, `Workflow::Triaged`, 
> `Emulation ➤ Softfloat`, `Target ➤ X86`, `HostArch ➤ AArch64`, `TestCase`.
> 
>   All issues (excluding the non-existent one) have been successfully 
> processed, labeled according to project standards, and verified as complete. 
> No further actions are required at this time.
> 
> I guess arguably it is hard for a random to use the API anyway as we
> control who has API keys for the project.
> 
> > +  - Post **comments** on merge requests, issues or commits
> > +  - Open or update **merge requests (MRs)**.  QEMU does not use merge 
> > requests anyway.
> > +
> <snip>
> 
> -- 
> Alex Bennée
> Virtualisation Tech Lead @ Linaro


Reply via email to