You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reading the new contribution guidelines, one thing I could not work out is how third-party skills are meant to reach users now, and I think the answer affects more people than just me.
What I understand today
packages/coding-agent/skills/ ships integrations for third-party services — linear, notion — bundled in-tree. The RLM docs describe Python-backed skills as a first-class extension point: SKILL.md for discovery and routing, plus a Python package installed into the kernel environment and exposed by import name.
At the same time, CONTRIBUTING.md now says unsolicited pull requests are not reviewed and PRs are limited to vouched contributors. Both of those make sense given the volume you described, and given that skills execute with the worker's OS permissions — the docs are explicit that the kernel is "a durable control environment, not a security sandbox."
The question
Is bundling in-tree now intentionally maintainer-only, with third-party integrations expected to live outside the repo and be installed by the user? Or is in-tree still the intended home, just gated behind the discussion-first process?
If it is the former, is there a supported out-of-tree layout — a directory Prime Agent scans, or an install command — that a skill author should document instead of proposing a PR? I could not find one in the RLM or architecture docs, and the difference matters: one path means "write installation instructions for your users," the other means "wait to be invited."
My stake, so it is on the table
I maintain YantrikDB, an embeddable memory engine, and I opened #1036 adding a yantrikdb skill before the policy changed. It was closed with the rest of the queue, which is fair and not what I am asking about — I am not re-pitching it here. I would rather know the intended shape than guess.
To be clear about the overlap, since I think it is easy to misread: Prime Agent already has persistence — durable harness state, persistent goals, compaction, and /refine writing lessons and memories. What an external memory engine adds is different in kind: semantic recall over a corpus that outlives many sessions, with conflicting facts surfaced rather than silently overwritten. Whether that is interesting to this project is a separate conversation, and one I am happy to have in Feature requests if it is worth having. This question is only about the distribution path.
Happy to write up whatever the answer turns out to be as a docs contribution if that is useful.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Reading the new contribution guidelines, one thing I could not work out is how third-party skills are meant to reach users now, and I think the answer affects more people than just me.
What I understand today
packages/coding-agent/skills/ships integrations for third-party services —linear,notion— bundled in-tree. The RLM docs describe Python-backed skills as a first-class extension point:SKILL.mdfor discovery and routing, plus a Python package installed into the kernel environment and exposed by import name.At the same time, CONTRIBUTING.md now says unsolicited pull requests are not reviewed and PRs are limited to vouched contributors. Both of those make sense given the volume you described, and given that skills execute with the worker's OS permissions — the docs are explicit that the kernel is "a durable control environment, not a security sandbox."
The question
Is bundling in-tree now intentionally maintainer-only, with third-party integrations expected to live outside the repo and be installed by the user? Or is in-tree still the intended home, just gated behind the discussion-first process?
If it is the former, is there a supported out-of-tree layout — a directory Prime Agent scans, or an install command — that a skill author should document instead of proposing a PR? I could not find one in the RLM or architecture docs, and the difference matters: one path means "write installation instructions for your users," the other means "wait to be invited."
My stake, so it is on the table
I maintain YantrikDB, an embeddable memory engine, and I opened #1036 adding a
yantrikdbskill before the policy changed. It was closed with the rest of the queue, which is fair and not what I am asking about — I am not re-pitching it here. I would rather know the intended shape than guess.To be clear about the overlap, since I think it is easy to misread: Prime Agent already has persistence — durable harness state, persistent goals, compaction, and
/refinewriting lessons and memories. What an external memory engine adds is different in kind: semantic recall over a corpus that outlives many sessions, with conflicting facts surfaced rather than silently overwritten. Whether that is interesting to this project is a separate conversation, and one I am happy to have in Feature requests if it is worth having. This question is only about the distribution path.Happy to write up whatever the answer turns out to be as a docs contribution if that is useful.
All reactions