Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/apache/airflow/magpie-setupnpx skills add apache/airflow --skill magpie-setupgit clone --depth 1 https://github.com/apache/airflowWhat 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 | $0.00243 | $0.06520 |
| Opus 5 | $0.00121 | $0.03260 |
| Sonnet 5 | $0.00049 | $0.01304 |
| Haiku 4.5 | $0.00024 | $0.00652 |
Grade A, and why
magpie-setup 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 yesterday.
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 — 432 lines — stays where its author put it; the contents beside it link to each section on GitHub.
setup
This skill is the only framework artefact an adopter
project commits. Every other apache-magpie skill (security,
pr-management, issue) is a gitignored symlink into the gitignored
snapshot at <snapshot-dir> that this skill manages.
The adoption model is snapshot + agentic overrides + drift- aware updates (not submodule, not marketplace, not vendored copy):
- The framework is downloaded into
<snapshot-dir>and gitignored in the adopter repo. The snapshot is a build artefact, not source. - Three install methods are supported (see
docs/setup/install-recipes.mdfor verbatim copy-pasteable recipes):- svn-zip — released, signed zip from ASF distribution (recommended for production once releases ship).
- git-tag — pinned to a specific git tag.
- git-branch — tracks a branch tip (default:
main, the WIP path).
- Two lock files record the framework version. The
committed one declares what the project pins to; the local
one records what each machine actually fetched. Drift
between them is surfaced and remediated by
/magpie-setup upgrade. - Symlinks make the framework's skills callable as if they
lived in the adopter repo. Each symlink is named
magpie-<framework-skill>— every framework skill is installed under amagpie-prefix so it is namespaced and never collides with the adopter's own skills (e.g. the snapshot'sskills/pr-management-triage/becomesmagpie-pr-management-triage, invoked as/magpie-pr-management-triage)..agents/skills/is the one canonical home: itsmagpie-*entries link into<snapshot-dir>/skills/<framework-skill>/. Every other agent target (.claude/skills/,.github/skills/, …) gets a thin per-skill relay symlink that points back at the canonical entry (.claude/skills/magpie-<n>→../../.agents/skills/magpie-<n>) — no matter what layout the adopting project previously used (seeagents.md). The symlinks are gitignored because their targets disappear on a fresh clone before/magpie-setupruns. - Adopter-specific modifications to framework workflows live as
agent-readable instructions under
.apache-magpie-overrides/<skill-name>.md(committed). They invalidate or change steps the framework's skill would otherwise run. Seeoverrides.mdfor the contract anddocs/setup/agentic-overrides.mdfor the design rationale.
Local self-adoption (the framework checkout only). The one
repo that cannot be adopted via the snapshot mechanism is the
Apache Magpie framework checkout itself — a remote snapshot of the
framework into itself would be circular. Instead it self-adopts
with method:local: each canonical magpie-<skill> in
.agents/skills/ is a committed symlink into the in-repo
../../skills/<skill>/ source, and every other active agent
target (agents.md) — .claude/skills/ (Claude
Code), .github/skills/ (GitHub's skill loader), and any present
holdout — gets a committed relay symlink
(magpie-<skill> → ../../.agents/skills/magpie-<skill>) — with
no snapshot, no remote fetch, and no copy. This makes
the framework's own skills callable while developing the framework,
and every contributor gets them active on a fresh clone with no
setup step. adopt detects the framework checkout structurally and
routes there automatically (see
adopt.md → Local self-adoption).
What ships with it
8 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.
- yesterday First seen · 432 lines · 243 tokens per session scan A 07528d1316f4
magpie-setup is a skill published in the GitHub repository apache/airflow (46,647 stars, last pushed yesterday), licensed Apache-2.0. It adds 243 tokens to every session and 6,520 once invoked, about $0.0012 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-08-30.
Other skills, from other repositories
airflow-workflow
Execution guide for Airflow scheduled jobs — troubleshooting, updating, connid conventions, and cron references.
release-candidate-prep
Preflight and prepare an OpenAI Agents Python release candidate in a dedicated worktree from exact origin/main, gate readiness before branch creation, freeze the released API contract, create or replace the local release branch with one release commit, enforce final release review as a checker, and produce…
dagster-docs
Expert guidance for writing documentation for the Dagster docs website. ALWAYS use before creating or updating documentation in the docs directory.
qa
QA-test a website or web app and return a 1-5 quality score (5 = flawless, 1 = broken) with evidence. Use when the user wants to test, QA, evaluate, score, or "check how good" a site, page, flow, or app — including a local dev server (e.g. "qa test localhost:5173", "does the checkout work?", "rate this landing page").…
stripe-best-practices
Guides Stripe integration decisions across API selection (Checkout Sessions vs PaymentIntents), Connect platform setup (Accounts v2, controller properties), billing/subscriptions, tax and registrations (Stripe Tax, automatictax, product tax codes), Treasury financial accounts, integration options (Checkout, Payment…
billing-stripe
Work with Stripe billing — subscriptions, plans/prices, the Customer Portal, credits, usage metering, invoices, and webhook events. Use when changing plans, handling a new Stripe webhook, debugging a payment/subscription flow, or touching credit balances and usage.