Adopt Apache Magpie (agent-assisted maintainer workflows) + JMeter config

[milamberspace]

What

Adopts the Apache Magpie framework of
agent skills into JMeter, plus the JMeter-specific configuration, so
maintainers can run structured, auditable workflows (PR triage, issue
triage, stats dashboards, security-issue and release helpers) from their
own AI coding agent.

Draft / for discussion. Opened against my fork's trunk so the diff
and committed footprint are reviewable. It is not proposed to
apache/jmeter yet — see the dev@ DISCUSS thread.
Nothing is merged or run automatically.

Committed footprint (the important part)

21 files. The split:

• ~550 lines of JMeter-specific config + wiring: project.md, the
  pr-management-* config, .gitignore, a short README/AGENTS
  section, .claude/settings.json, two relay symlinks, .apache-magpie.lock.
• The one committed magpie-setup bootstrap skill (~4.7k lines of
  Markdown docs, not code) — required so a fresh clone can re-fetch the
  framework.
• Not committed: the other 68 skills. They live in a gitignored
  snapshot (.apache-magpie/), fetched on demand. They never land in
  git and never sit in the agent's context window (skills load on demand;
  only a one-line description per skill is indexed).

Full removal is a single command: /magpie-setup unadopt.

What's wired for JMeter

• Families enabled: pr-management, issue, security. release-*
  is intentionally not wired yet.
• Config adapted to JMeter reality: no area:* labels (area grouping
  disabled), no GitHub security tracker / Projects board (those panels are
  N/A), real CI-check names mapped (Validation, Error Prone, the JDK ×
  vendor × OS test matrix), longer grace windows for our slow triage
  cadence.
• Backends: GitHub Issues, dev@/private@ via the ASF PonyMail
  archive, ASF Vulnogram CVE tooling.

How it stays low-risk

• Human-in-the-loop: every skill only proposes; a human confirms
  before any comment, label, merge, or commit. No bots posting on their
  own, no CI automation.
• Local & credential-scoped: runs in each maintainer's own agent under
  their own credentials. No shared service; no project data leaves the
  maintainer's control.
• Deterministic guardrails: a committed PreToolUse hook blocks
  premature "ready", maintainer pings, and Co-Authored-By trailers.

Example output (read-only, nothing posted)

PR-backlog dashboard generated from our 70 open PRs by the
pr-management-stats skill:
https://gistpreview.github.io/?b22eb23da618ff3b17a4e4e921375d72

Commits

• Add Apache Magpie (snapshot + committed magpie-setup)
• Finish apache-magpie adoption (locks, symlinks, overrides, hook, docs)
• Add Apache JMeter project manifest
• Add pr-management-triage config for JMeter

🤖 Generated with Claude Code

[vlsi]

What is this? Why creating a hook without agent-guard.py?

[milamberspace]

Good catch. Two parts, then the fix.

What it is: .claude/settings.json wires Magpie's deterministic agent-guard — a Claude Code PreToolUse hook that blocks risky gh/git commands before they run (a commit carrying a Co-Authored-By trailer, an @-mention that would ping a maintainer, marking a PR "ready" while CI is still pending, force-pushing an empty PR…). It's a safety rail, not project logic.

Why agent-guard.py isn't in the PR: same rule as the 68 skills — it's framework code, gitignored on purpose, synced from the Magpie snapshot by /magpie-setup (re-collected on upgrade). We don't vendor it into JMeter's history; only magpie-setup + config are committed.

But your underlying point is valid: the committed wiring referenced a script that isn't there until /magpie-setup runs, so on a fresh clone the hook would try to exec a missing file on every Bash call — and a PreToolUse error can block the tool. That's a footgun.

Fixed in 6ec2d88: the committed command is now a no-op until the script exists —

[ -f "$CLAUDE_PROJECT_DIR/.claude/hooks/agent-guard.py" ] && python3 "$CLAUDE_PROJECT_DIR/.claude/hooks/agent-guard.py" || true

I'll also upstream this to apache/magpie (via setup-upstream-fix), since it affects every adopter. If you'd rather not commit the wiring at all, the alternative is to let /magpie-setup write it into the gitignored settings.local.json instead — happy to switch to that if you prefer.

[milamberspace]

Upstreamed: the guard is now proposed for every adopter in apache/magpie#786 — it updates the committed hook snippet in skills/setup/adopt.md and tools/agent-guard/README.md to the same [ -f … ] && … || true form. Once that merges and we /magpie-setup upgrade, our local 6ec2d88 becomes redundant and can be dropped. Thanks again for catching it.

[vlsi]

Who and what keeps this up to date?

[milamberspace]

Fair question — same one you raised on dev@, so here it is inline too.

These are slow-moving facts (upstream repo, default branch, mailing lists, label names, CI-check names) — a label rename or a new CI job touches one line. Keeping them current isn't a separate chore:

• /magpie-setup upgrade reconciles these overrides against framework changes and surfaces any drift for review, and setup-upstream-fix pushes our own fixes back upstream.
• When JMeter itself changes something referenced here (renames a label, adds a CI check), whoever makes that change updates the one line — exactly like .asf.yaml or CODEOWNERS.
• The skills read this file at runtime, so an obviously-stale value surfaces on the next run.

So: "who" = the maintainers who use the skills, like any config; "what" = reconcile-on-upgrade plus normal review. Not a standing maintenance burden.

[vlsi]

The CI matrix changes very often. The stale context is worse than no context.

whoever makes that change updates the one line — exactly like .asf.yaml

I would prefer Magpie to source information from .asf.yaml rather than forcing everybody to duplicate the info.