Feature request description
Using ramalama sandbox I can start a containerized (goose|opencode|pi) and use the skills, agents, plugins in the /work/.agents directory (or equivalent). Instead of copy&pasting these files between projects and relying solely on the presence in the mounted directory, it would be great to leverage OCI artifacts for cross-cutting skills etc.
AI skills, agents, plugins, etc. could be packaged as OCI artifacts - similar to AI models - and mounted on demand into the sandbox container. This way the same distribution channel as for images and models could be used.
Similar to the shortnames.conf for AI models, another file (e.g.shortnames-skills.conf) could be used to define shortnames for these OCI artifacts.
Suggest potential solution
Proposed CLI changes
-
ramalama [skill | agent | plugin] build -d <path> -t <tag>
-> Creates a .tar.gz for the and adds it to the artifact (overwriting existing one locally). The tarball is required since skills etc. can consist of multiple files and (nested) directories.
-
ramalama [skill | agent | plugin] ls
-> Lists locally available OCI artifacts.
-
ramalama sandbox goose --skill <full name or shortname> <model>
-> The --skill <name> option can be repeated n times
-> Run the local model and AI agent, (optionally) resolve the skill shortname and mount the OCI artifact into the sandbox container. In order to make the skill inside the tarball usable, it needs to be extracted into the respective directory (e.g. ~/.agents/skills for goose). This could be done by overwriting the entrypoint and running a plain bash script first, unpacking these tarballs.
shortnames for skill artifacts
[shortnames.skills]
"wiki-kb" = "quay.io/ramalama/wiki-kb"
...
[shortnames.agents]
...
Have you considered any alternatives?
No response
Additional context
No response
Feature request description
Using
ramalama sandboxI can start a containerized (goose|opencode|pi) and use the skills, agents, plugins in the/work/.agentsdirectory (or equivalent). Instead of copy&pasting these files between projects and relying solely on the presence in the mounted directory, it would be great to leverage OCI artifacts for cross-cutting skills etc.AI skills, agents, plugins, etc. could be packaged as OCI artifacts - similar to AI models - and mounted on demand into the sandbox container. This way the same distribution channel as for images and models could be used.
Similar to the
shortnames.conffor AI models, another file (e.g.shortnames-skills.conf) could be used to define shortnames for these OCI artifacts.Suggest potential solution
Proposed CLI changes
ramalama [skill | agent | plugin] build -d <path> -t <tag>-> Creates a .tar.gz for the and adds it to the artifact (overwriting existing one locally). The tarball is required since skills etc. can consist of multiple files and (nested) directories.
ramalama [skill | agent | plugin] ls-> Lists locally available OCI artifacts.
ramalama sandbox goose --skill <full name or shortname> <model>-> The
--skill <name>option can be repeated n times-> Run the local model and AI agent, (optionally) resolve the skill shortname and mount the OCI artifact into the sandbox container. In order to make the skill inside the tarball usable, it needs to be extracted into the respective directory (e.g.
~/.agents/skillsfor goose). This could be done by overwriting the entrypoint and running a plain bash script first, unpacking these tarballs.shortnames for skill artifacts
Have you considered any alternatives?
No response
Additional context
No response