Hi all,
As promised, here is the more detailed write-up of what landed in the
rename/restructure push (typing from the train to Berlin Buzzwords, so
forgive any mistakes).
== What shipped ==
It came together as a chain of small PRs, all merged except the last one:
1. Magpie everywhere. Docs, user-facing strings, and the project-local
dotfiles all carry the new name: per-project state moved
.apache-steward* -> .apache-magpie*, and the per-user config dir
~/.config/apache-steward/ -> ~/.config/apache-magpie/.
2. Vendor-neutral skill layout. Exactly the move Yeonguk proposed in
"[DISCUSS] Move framework skills from .claude/skills/ to skills/". The
payload skills now live in a top-level skills/ as the canonical,
harness-neutral source; .claude/skills/ no longer holds source. This is
what unblocks a future adapters/<vendor>/ transpile layer (Cursor,
Codex, ...) without hard-coding one harness's directory shape.
3. Every skill is namespaced magpie-. The source `name:` frontmatter is now
magpie-<skill> (magpie-issue-triage, magpie-setup, ...), matching the
installed/invoked name, and the skill validator now ENFORCES
`name: magpie-<dir>` as a hard rule so the convention can't drift.
(apache/airflow-steward#442, merged.)
4. Magpie adopts itself ("inception" - the idea I floated in the layout
thread is now real). A new `method:local` self-adoption path makes the
framework checkout link its own skills/ source directly: each
magpie-<skill> is a committed symlink into ../../skills/<skill>/, written
under BOTH .claude/skills/ (Claude Code) and .github/skills/ (GitHub's
skill loader). No remote, no snapshot, no copy - and because the targets
are in-repo, a fresh clone has every skill active with zero setup. We now
dog-food the exact skills we ship.
(https://github.com/apache/airflow-steward/pull/443 - the one still OPEN;.)
5. Retired the setup-steward migration shim - the last artefact still
carrying the old name. Every current adopter can be easily migrated,
so #443 drops the shim and documents the (now-rare) manual
pre-Magpie cleanup path.
== Migration: the built-in upgrade just worked ==
I migrated all three projects where Magpie was in active use - Airflow (PR
triage), our security tracker, and the ASF-wide LLM-security scanning
campaign - using the framework's OWN built-in upgrade/migration flow. It
worked flawlessly across all of them: snapshot refresh, symlink re-wiring,
dotfile + config-dir moves, each driven by the skill itself with a
reviewable diff at every step. I can't overstate what a good sign this is:
agent/skill-driven migration of skill-based projects is genuinely a breeze,
so we can evolve the framework aggressively without dumping migration toil
on adopters.
== Taxonomy + plugins: not blocked, set up ==
Nothing here closes André's "[DISCUSS] Retire modes in favour of an
intent-based adoption taxonomy" or the plugin/marketplace direction - if
anything it lays the groundwork:
- A canonical, vendor-neutral skills/ tree with uniform magpie-* naming is
exactly the substrate André's registry / skills-index.json + intent/lock
reconciler wants to compute over.
- Validator-enforced naming + the self-adopt mechanism mean "a skill rename
ships as a migration entry" (his plan/apply model) maps cleanly onto what
we already do.
- Plugin/marketplace packaging (the skills.sh / Claude-plugin direction) is
now basically "bundle skills/ + the magpie-setup bootstrap" - the layout
is finally in the right shape for it.
So let's keep both discussions going; this work removes friction rather than
pre-deciding anything.
== Current state of skills / how to adopt ==
For anyone adopting Magpie today:
- follow one of the adoption paths described in the repo (for now it's
mostly
via URL from `main` of https://github.com/apache/airflow-steward/ (which
until
the TLP establish is our current home). It will require a JIRA issue to
rename it,
so I think it's not worth now - since when we will become a TLP, the only
change will be to move it from "apache/airflow-steward" to "apache/magpie".
- The adoption will install and run the /magpie-setup in the repo.
It fetches the framework as a gitignored
snapshot under .apache-magpie/ pinned by a committed .apache-magpie.lock,
then symlinks the families you opt into as magpie-* into .claude/skills/
(and .github/skills/ if you use GitHub's loader). The one committed
framework artefact is the magpie-setup bootstrap; everything else is a
gitignored symlink.
- Maintenance is /magpie-setup upgrade (refresh + reconcile) and
/magpie-setup verify (drift check). Adopter-specific tweaks go in
.apache-magpie-overrides/ (committed), never in the snapshot.
- All skills are invoked under the magpie- prefix now
(/magpie-pr-management-triage, /magpie-security-issue-import, ...).
== One operational note ==
CI is lagging - the shared ASF GitHub Actions runner pool is badly queued
right now, so Magpie PRs (incl. #443) sit waiting on checks longer than they
should. It's not the PRs, it's ASF-wide runner contention. On the Airflow
side we're actively working to offload a chunk of our own CI jobs off the
shared runners, which should ease pressure on the whole ASF pool over time.
Next: I'll keep pushing the board discussion with Sander and prep the move
toward apache/steward. More soon.
J.
On Wed, Jun 03, 2026 12:07 PM, Jarek Potiuk <[email protected]> wrote:
> I am finishing the move and found a few "limits/clarifications" that I had
> to apply - still completing it - but I will provide some more detailed
> summary shortly. I , going to Berlin in a few minuts for Berlin Buzzwords
> next week - but I have good connectivity in train :)
>
> All seems good and I applied all the ideas we discussed so far, without
> closing discussions on taxonomy and plugins. Also migration worked
> flawlessly for all my adopted projects. Agents and SKILLS are really, relly
> good in making installation and migration of SKILL-based projects ... a
> breeze (and Airflow people here will know what I mean ;) ...
>
> J.
>
> On Wed, Jun 3, 2026 at 4:20 AM Yeonguk Choo <[email protected]> wrote:
>
>> Thanks for the update, this sounds great!
>>
>> I just wanted to clarify the naming/migration path: are we moving to
>> apache/steward (instead of apache/magpie),
>> and is the intended flow something like apache/airflow-steward -->
>> apache/steward --> apache/magpie? Just want to make sure I fully understand
>> the direction.
>>
>> Best,
>> Yeonguk
>>
>> On 2026/06/02 11:25:15 Jarek Potiuk wrote:
>> > Hello here,
>> >
>> > I reached out to Sander yesterday, and I will try to move the "board"
>> > discussion forward today. However, I would also like to complete some
>> > overdue renames today.
>> >
>> > We have just a few outstanding PRs left. I will merge them now, even if
>> > they aren't fully complete to avoid costly conflict resolution; we will
>> > continue iterating on those.
>> >
>> > This will help us with a more global rename, implementing the upgrade,
>> and
>> > preparing for moving out to "apache/steward" finally.
>> >
>> > I've been quite focused on ground-level tasks over the last
>> week—focusing
>> > on "ironing out wrinkles" in the existing skills - those we are
>> "actively"
>> > using. I implemented several of those "infrastructural" issues I found
>> > across the **three** projects where Magpie is integrated:
>> >
>> > *a)* airflow -> PR triage is used heavily there
>> > *b)* airflow-s -> Our security issues
>> > *c)* security -> I am running a campaign to scan ASF projects with LLM
>> > security and preparing them for scan and I adopted Magpie (and Magpie's
>> > approach) there for privacy/security
>> >
>> > A lot of friction has been removed. I generalised the security part,
>> added
>> > many optimizations for both user workflow and token usage (the Security
>> > family of skills now uses about 5x fewer tokens). I also nicely
>> integrated
>> > the two official "Ponymail" and "Apache Projects" MCPs from comdev. I
>> also
>> > added more security layers and privacy layers and optimized a lot a
>> number
>> > of "interruptions" running some of the skills involved.
>> >
>> > So .. I think now is a good time to do the renames :)
>> >
>> > Kind request .. Hold on with new changes ;)
>> >
>> > J.
>> >
>>
>
