Hi all, I want to put a proposal in front of the list about how projects adopt Magpie, and about the primitive we organise the framework around. This is a [DISCUSS] thread, not a vote. I have a working prototype, but nothing is decided and I want the list's read before anything moves upstream. The problem
Today a project adopts Magpie by reasoning about modes (Triage, Mentoring, Drafting, Pairing, Auto-merge) and families (security, pr-management, ...). A new PMC has to internalise ~17 skills, 5 modes, several families and the relationships between them before they can answer "what do we turn on". The conversation lands on "do we enable family X" when the real question is "how much automation does our project actually want, and for whom". The deeper issue: modes are not one axis. The framework's own docs/modes.md <https://github.com/andreahlert/magpie/blob/main/docs/modes.md> shows it. Triage is listed as "stable (security) / experimental (pr-management, issue-management, ...)", one mode spanning two maturity states and four domains. pr-management-code-review is filed under Triage with a hand-wave. security-cve-allocate admits it is "procedural rather than classificatory ... listed here for navigability". Pairing is defined by where the agent runs (dev-side vs project-side), Auto-merge purely by risk tier, Mentoring is also a property of Pairing skills. Modes fuse at least three different axes (action/risk, audience, register) into one enum. That is fine as prose, lossy the moment you want to compute against it. The proposal (Model C: intent + lock, Terraform style) 1. Every skill carries machine-readable tags on explicit axes: domain, audience, risk-tier, integrations, requires. 2. An adopter writes a short intent file: domains, audiences, risk-tier-max, integrations, plus surgical overrides (exclude, force-include, pin, params). 3. A reconciler intersects intent against the skill registry and emits a deterministic lock file (reproducible across machines) plus optional rendered templates. 4. plan / apply behave like Terraform: the adopter sees the diff before anything writes. Onboarding then shrinks to four strategic questions (domains, audiences, risk-tier-max, integrations). The reconciler picks the skills. A skill rename ships as a migration entry and shows up in plan, so no adopter ever grep-and-replaces. Structure becomes computable: "every write-comment skill that touches gmail" is a one-line query over the registry index. Modes do not die. They survive as a projection over the taxonomy in MISSION.md and the adoption docs, where the narrative is genuinely useful. They stop being the data primitive. Why this also helps the website If skills are tagged by audience and adoption path, the site can be organised around "what Magpie offers a maintainer / a contributor / a security team" instead of around internal mode names. The taxonomy and the site information architecture become the same model. Evidence / prototype I built a fork to pressure-test this end to end: - Repo: github.com/andreahlert/magpie - Umbrella issue: #1 <https://github.com/andreahlert/magpie/issues/1> - RFC-MAG-0001 (adoption models A/B/C): RFC-MAG-0001 <https://github.com/andreahlert/magpie/blob/main/docs/rfcs/RFC-MAG-0001-adoption-models.md> - RFC-MAG-0002 (structural impact of Model C): RFC-MAG-0002 <https://github.com/andreahlert/magpie/blob/main/docs/rfcs/RFC-MAG-0002-model-c-structural-impact.md> - Working registry (29 skills tagged on all axes, with requires edges): registry/skills-index.json <https://github.com/andreahlert/magpie/blob/main/registry/skills-index.json> The fork is a prototype. It has rough edges I would clean before any upstream PR, and a self-written drift audit at docs/audit-drift-report.md <https://github.com/andreahlert/magpie/blob/main/docs/audit-drift-report.md> documents where the fork diverges from current main. I am sharing it as discussion material, not a finished change set. What I am asking - Does the "modes conflate multiple axes" diagnosis read as real to the people running adopters, or is it an edge-case annoyance? - If the taxonomy is right, is the full intent + lock + reconciler the proportionate mechanism, or do we want the structured registry first and the reconciler as a follow-up? - Concerns about the migration cost for current adopters? I discussed an early version of this with Jarek offline and he suggested bringing it to the list. Keen to hear where people push back. Thanks, André
