[PROPOSE] Mechanism to pull skills/skill-families from trusted external repositories (RFC-AI-0006, PR #677)

[Jarek Potiuk <ja...@potiuk.com>]

Hi all,

I've opened a first cut of something we discussed a while back and I'd like
the list's read on it.

The problem
-----------

Back on the dev-magpie@ thread with Justin and Rich  we talked about
Comdev/Incubator skills that would sensibly live in *their own* repository
rather than in apache/magpie, but that we'd still want to adopt with the
same ergonomics as a native Magpie skill. Today there's no clean way to do
that -- you either upstream the skill into Magpie or hand-vendor a copy,
which is unpinned, unverified, and invisible to our drift/verify/eval
discipline.

The proposal
------------
A "trusted external skill source": where a skill directory would sit, a
small skills/<name>/source.md *redirect* names a remote source (a GitHub
folder, an SVN/dist archive, or a git tag/branch). The skill -- with its
evals and tests -- is fetched into the gitignored snapshot, pinned,
verified, and wired in *exactly* like an in-tree skill (same magpie-
symlink relay, same override layer). Nothing is fetched unless the adopter
explicitly vouches for the source by committing its pin. Trust is layered:
a framework discovery registry -> an org may curate sources it stands
behind -> the adopter's own skill-sources.md is the install gate.

This does move a bright line: PRINCIPLES section 13 previously said
catalogs are "for discovery, never for installation." The PR narrows that
to "never for *untrusted* installation" -- a trusted, adopter-vouched,
pinned+verified source is held to the same bar as the framework snapshot
itself.

PR + RFC
--------
https://github.com/apache/magpie/pull/677 -  the design and threat model
are in docs/rfcs/RFC-AI-0006.md, the formats in docs/skill-sources/.

Important caveat -- this is the first part only
-----------------------------------------------
The PR is the design, the section-13 change, the formats, and the validator
guardrails. It does *not* yet include the /magpie-setup fetch/lock/symlink
wiring (that's the next step), and it does not yet give the *source* repos
a way to run the same kinds of evals and tests we run in Magpie -- which
we'll want, so a skill is verifiable at its home and not just at adoption.

Where this could go
-------------------
The owning-repo idea is tied to our "Organization" concept.
Comdev/Incubator is the obvious first case, but the same shape would let,
say, Python Software Foundation maintainers or Eclipse Foundation
maintainers publish skills their projects adopt -- each rendered under its
own organization identity. See the Organization sections of the site
https://magpie.apache.org/tools/#organizations / organizations/README.md
for how that would look.

Does this direction make sense to people? Concerns about the section-13
change, the trust model, or the eval-portability piece especially welcome.

Cheers,
Jarek

Re: [PROPOSE] Mechanism to pull skills/skill-families from trusted external repositories (RFC-AI-0006, PR #677)

[Jarek Potiuk <ja...@potiuk.com>]

The mechanism is ready, together with the documentation on how to author
your own skill sources:
https://magpie.apache.org/skills/skill-sources/authoring-a-source/

This is now "possible." The question now is whether we will make use of it
internally and externally?

We have several "trusted sources" we can use:

* Incubator
* ComDev
* Other Foundations (I am going to point them to the docs)

But.I think we should discuss the "trust" involved and how we think the PMC
should approach - especially for "Accepting" new trust sources and possibly
"exposing" them on our website when that happens. We can defer that
discussion until we have the first such internal and first such external
source to discuss - or we can theorise even now :)

My thinking is:

a) ComDev/Incubator: If they choose to host their own sources, there is no
problem / trust issue whatsoever - including linking to "main" versions of
those
b) External Sources (e.g., Eclipse Foundation, Python Software Foundation):
We can link to "tagged/released" versions and perform lightweight scans on
"security" - but other than that - we just make sure when someone adopts
the skill familiies  from  those sources - they are doing so based on trust
in those external sources.

J.



On Thu, Jul 2, 2026 at 9:08 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> Hi all,
>
> I've opened a first cut of something we discussed a while back and I'd
> like the list's read on it.
>
> The problem
> -----------
>
> Back on the dev-magpie@ thread with Justin and Rich  we talked about
> Comdev/Incubator skills that would sensibly live in *their own* repository
> rather than in apache/magpie, but that we'd still want to adopt with the
> same ergonomics as a native Magpie skill. Today there's no clean way to do
> that -- you either upstream the skill into Magpie or hand-vendor a copy,
> which is unpinned, unverified, and invisible to our drift/verify/eval
> discipline.
>
> The proposal
> ------------
> A "trusted external skill source": where a skill directory would sit, a
> small skills/<name>/source.md *redirect* names a remote source (a GitHub
> folder, an SVN/dist archive, or a git tag/branch). The skill -- with its
> evals and tests -- is fetched into the gitignored snapshot, pinned,
> verified, and wired in *exactly* like an in-tree skill (same magpie-
> symlink relay, same override layer). Nothing is fetched unless the adopter
> explicitly vouches for the source by committing its pin. Trust is layered:
> a framework discovery registry -> an org may curate sources it stands
> behind -> the adopter's own skill-sources.md is the install gate.
>
> This does move a bright line: PRINCIPLES section 13 previously said
> catalogs are "for discovery, never for installation." The PR narrows that
> to "never for *untrusted* installation" -- a trusted, adopter-vouched,
> pinned+verified source is held to the same bar as the framework snapshot
> itself.
>
> PR + RFC
> --------
> https://github.com/apache/magpie/pull/677 -  the design and threat model
> are in docs/rfcs/RFC-AI-0006.md, the formats in docs/skill-sources/.
>
> Important caveat -- this is the first part only
> -----------------------------------------------
> The PR is the design, the section-13 change, the formats, and the
> validator guardrails. It does *not* yet include the /magpie-setup
> fetch/lock/symlink wiring (that's the next step), and it does not yet give
> the *source* repos a way to run the same kinds of evals and tests we run in
> Magpie -- which we'll want, so a skill is verifiable at its home and not
> just at adoption.
>
> Where this could go
> -------------------
> The owning-repo idea is tied to our "Organization" concept.
> Comdev/Incubator is the obvious first case, but the same shape would let,
> say, Python Software Foundation maintainers or Eclipse Foundation
> maintainers publish skills their projects adopt -- each rendered under its
> own organization identity. See the Organization sections of the site
> https://magpie.apache.org/tools/#organizations / organizations/README.md
> for how that would look.
>
> Does this direction make sense to people? Concerns about the section-13
> change, the trust model, or the eval-portability piece especially welcome.
>
> Cheers,
> Jarek
>