Re: [PATCH 2/4] AGENTS.md: Let agents know what the participation rules are

["Alex Bennée" <alex.bennee@linaro.org>]

Paolo Bonzini <pbonzini@redhat.com> 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.

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