COOL, Thanks Jarek! Glad to see everything coming together. Yeonguk
2026년 6월 5일 (금) 오전 1:37, Richard Zowalla <[email protected]>님이 작성: > 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. > >>>> > >>> > >> > >
