You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@magpie.apache.org by Jarek Potiuk <ja...@potiuk.com> on 2026/06/02 11:25:15 UTC
[RENAME] Big rename and next steps
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.
Re: [RENAME] Big rename and next steps
Posted by Yeonguk Choo <ch...@ubuntu.com>.
COOL, Thanks Jarek!
Glad to see everything coming together.
Yeonguk
2026년 6월 5일 (금) 오전 1:37, Richard Zowalla <rz...@apache.org>님이 작성:
> Sounds great. Thanks, Jarek.
>
> See you in Berlin ;-)
>
> Gruß
> Richard
>
> > Am 03.06.2026 um 15:57 schrieb Jarek Potiuk <ja...@potiuk.com>:
> >
> > 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 <ja...@potiuk.com> 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 <ch...@apache.org>
> 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.
> >>>>
> >>>
> >>
>
>
Re: [RENAME] Big rename and next steps
Posted by Richard Zowalla <rz...@apache.org>.
Sounds great. Thanks, Jarek.
See you in Berlin ;-)
Gruß
Richard
> Am 03.06.2026 um 15:57 schrieb Jarek Potiuk <ja...@potiuk.com>:
>
> 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 <ja...@potiuk.com> 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 <ch...@apache.org> 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.
>>>>
>>>
>>
Re: [RENAME] Big rename and next steps
Posted by Jarek Potiuk <ja...@potiuk.com>.
BTW. There are still a few small reminders of the steward in a few places
which I am going to address as small follow-up PRs.
On Wed, Jun 3, 2026 at 3:57 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> 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 <ja...@potiuk.com> 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 <ch...@apache.org>
>> 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.
>>> >
>>>
>>
Re: [RENAME] Big rename and next steps
Posted by Jarek Potiuk <ja...@potiuk.com>.
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 <ja...@potiuk.com> 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 <ch...@apache.org> 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.
>> >
>>
>
Re: [RENAME] Big rename and next steps
Posted by Jarek Potiuk <ja...@potiuk.com>.
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 <ch...@apache.org> 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.
> >
>
Re: [RENAME] Big rename and next steps
Posted by Yeonguk Choo <ch...@apache.org>.
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.
>