Apache Magpie is a framework of agent-assisted workflows for maintaining Apache software projects, including issue triage, pull-request review, contributor mentoring, and security-report handling. Apache maintainers and developers use it to delegate repetitive project work to coding agents while retaining human review. Its catalogue entries are the skills, instructions, plugin, and settings that implement these workflows.
Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/apache/magpienpx agentmods add skills/apache/magpie/security-issue-syncWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/apache/magpie/security-issue-sync)<a href="https://agentmods.dev/skills/apache/magpie/security-issue-sync"><img src="https://agentmods.dev/badge/skills/apache/magpie/security-issue-sync.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00103 | $0.09090 |
| Opus 5 | $0.00051 | $0.04545 |
| Sonnet 5 | $0.00021 | $0.01818 |
| Haiku 4.5 | $0.00010 | $0.00909 |
Grade A, and why
magpie-security-issue-sync scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 701 lines — stays where its author put it; the contents beside it link to each section on GitHub.
security-issue-sync
This skill reconciles a single security issue in
<tracker> with:
- the GitHub issue itself — comments, labels, milestone, assignee, description fields;
- the email thread on
<security-list>that originated the report (and any follow-ups); - any pull requests in
<upstream>or<tracker>that reference or fix the issue; - the handling process documented in
README.md.
Golden rule 1 — propose before applying. Every change this skill performs is a proposal. The user running the sync must explicitly confirm each update before it is applied. Do not mutate GitHub state, do not send email, do not create, close, or edit anything without a clear "yes" from the user for that specific action. Drafts are always created as Gmail drafts, never sent directly.
Golden rule 2 — every <tracker> reference is clickable in the
surface it lands on. Whenever this skill mentions the tracking
issue, any other <tracker> issue, a <tracker> PR, a specific
issue comment, a milestone, or a label from this repository — in
the observed-state dump, in the proposal, in the confirmation
prompt, in the apply-loop output, in the regeneration output, in
the recap, in status-change comments posted to the issue itself,
anywhere — the reference must be one click away in whatever
surface it lands on:
-
On markdown surfaces (the proposal body and status-change comments posted to
<tracker>, the regenerated CVE JSON's reference list, any draft email reply text destined for the<security-list>Gmail thread): use the markdown link form per the "Linking<tracker>issues and PRs" section ofAGENTS.md:- Issue:
[<tracker>#221](https://github.com/<tracker>/issues/221)(or[#221](https://github.com/<tracker>/issues/221)when the repository is already obvious from context, e.g. inside a status-change comment on that same issue). - PR:
[<tracker>#NNN](https://github.com/<tracker>/pull/NNN)(.../pull/N, not.../issues/N). - Comment: link to the
#issuecomment-<C>anchor, e.g.[<tracker>#216 — issuecomment-4252393493](https://github.com/<tracker>/issues/216#issuecomment-4252393493). - Milestone: link to
https://github.com/<tracker>/milestone/<number>(not the title), because milestone titles can change and the number is stable. Example:[3.2.2](https://github.com/<tracker>/milestone/42).
- Issue:
-
On terminal surfaces (the apply-loop progress messages, the confirmation prompt, the recap printed to the user's terminal at the end): wrap the visible short form (
<tracker>#NNN) in OSC 8 hyperlink escape sequences (\e]8;;<URL>\e\\<tracker>#NNN\e]8;;\e\\) so modern terminals (iTerm2, Kitty, GNOME Terminal, WezTerm, Windows Terminal, …) render the short text as clickable. Where OSC 8 is unsupported (CI logs, dumb terminals), fall back to printing the bare URL on the same line after the number.
Bare #NNN / <tracker>#NNN with no link wrapper of any kind
is never acceptable — not in terminal output, not in posted
comments.
Self-check before presenting any user-visible text (proposal
body, recap body, status-comment body, apply-loop progress
messages): grep the text for bare #\d+ and bare <tracker>#\d+
tokens that aren't already inside a markdown link or an OSC 8
wrapper, and convert any match to the appropriate clickable
form for that surface. If the scrub finds a reference the skill
does not have the full URL for yet, look it up with
gh issue view <N> --repo <tracker> --json url --jq .url
before emitting. Tracker URLs and #NNN identifiers are public-safe
per the
Confidentiality of <tracker>
rule (the page they point at is access-gated, so the link itself
does not leak contents); what stays private is the verbatim
content of the tracker — comment quotes, label transitions, body
excerpts, severity assessments — and, before the advisory ships,
the security framing of a public PR.
What ships with it
5 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 701 lines · 103 tokens per session scan A 3806e765c5b4
magpie-security-issue-sync is a skill published in the GitHub repository apache/magpie (87 stars, last pushed 5d ago), licensed Apache-2.0. It adds 103 tokens to every session and 9,090 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
bridge
Use when the user wants hyperflow's behavioral rules to apply outside the terminal CLI — in Claude Code Desktop, claude.ai web, or IDE extensions that don't load CLI plugins. Writes a managed doctrine block into the project's CLAUDE.md so autonomy + intent-routing + commit cadence + role separation + file-first rules…
atmos-hooks
Atmos hooks: lifecycle events, hook kinds, command/store/git/security hooks, step/steps hooks, when: conditions, scoping and overrides, toolchain integration, --skip-hooks, and Atmos Pro/local output.
taiyi-integration
A project workflow skill for closing a TaiyiForge change and recording it in a CHANGELOG.md file. It checks review results, tests, and the state of the working tree before archiving the change.
qa
QA test your code changes by reading your git diff, choosing the right validation path for frontend/browser and backend changes, and reporting pass/fail with evidence.
no-mistakes
Validate committed feature-branch changes through the no-mistakes pipeline: intent, rebase, review, test, docs, lint, push, PR, and CI. Use when the user asks to run no-mistakes, ship safely, validate before pushing, or gate a change before it reaches upstream.
codex-autoresearch
Run autonomous, measurable experiments in a Git repository: change one hypothesis, verify a numeric metric, keep improvements, and revert failures. Use when the user wants Codex to keep iterating toward a numeric target in the foreground or as a detached background run. Do not use for ordinary one-shot coding…