Sounds great. Thanks, Jarek. See you in Berlin ;-)
Gruß Richard > Am 03.06.2026 um 15:57 schrieb Jarek Potiuk <[email protected]>: > > 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. >>>> >>> >>
