Problem statement
Skills currently have no story for sharing: no export/import, no way to install a skill pack from a git URL, and no alignment with the emerging skills.md format standard.
This turns out to be one instance of a broader gap: agent profiles, custom tools, custom apps, and routines have the same problem — hand-export only (if that), no import, and no way to move a curated collection of these things (an org preset, a personal backup) in one action. There's no single, standardized way to package and move any of these functional primitives.
Full architecture direction: plans/pack_system.md (omnideck repo). That document is a direction-setting RFC-style doc, not yet an execution plan — phase sequencing below is proposed, not committed.
What success looks like
A user can package any functional primitive — agent profile, skill, custom tool, custom app, or routine — into a single distributable "pack" (manifest + optional embedded files) and import it into another install. An organization can define a preset "bundle" (a pack whose purpose is establishing a working install state) so a new install can be provisioned to a known state in one step, the way Ansible provisions a machine. Installed packs are locked by default so a user (or the agent acting for them) can't accidentally break something installed from a trusted source, with an explicit "clone to customize" path when they want to.
A searchable, publishable community library is the long-term destination this architecture should not preclude, but it is explicitly out of scope for near-term work (see below).
Impacted repositories
Acceptance criteria
Tracks the phased breakdown in the plan doc (§12); sub-issues may be filed per phase as this is scheduled:
- Any of profile / skill / tool / app / routine can be exported as a pack and imported into another install, using one standardized manifest + on-disk format (
~/.packs/<vendor>/<pack-name>/<type>/), with per-item provenance (publisher/editable) — Phases A–B.
- A "Create Pack" flow (manual and agent-assisted) lets a user select items — including cloneable items embedded from other installed packs — into a new pack, with best-effort dependency resolution plus an import-time check that reports missing dependencies rather than silently degrading — Phase C.
- Installed pack items are locked (read-only) by default, enforced at the filesystem level via a privileged installer/updater component, with an explicit "clone to customize" path — Phase D.
- Packs can be imported/exported as git repositories (clone to install, push to publish, fetch/diff to check for updates), not just ad-hoc file downloads — Phase E.
- Every pack import or update passes a deterministic security scan by default (manifest validation, zip-slip path checks, static script analysis, dependency-advisory checks), with an optional opt-in LLM-enhanced review pass — Phase F.
- A dedicated Packs area in Settings lists installed packs (by vendor), lock state, source, and install path, cross-linked from the existing per-type tabs — Phase G.
- Existing on-disk profiles, skills, tools, and apps are migrated to the new layout with a concrete, reviewed migration path (required deliverable of Phase B, not a follow-up).
Carried over from the original scope, not yet addressed by the architecture doc: alignment with the emerging skills.md format standard for interoperability. Needs its own resolution during Phase A/C design — flagging so it isn't dropped.
Explicitly out of scope
- Community library (search, browse, rate, publish/install from a hosted registry) — Phase H. Needs its own design pass (hosting, moderation, licensing) and real team bandwidth; named so it isn't lost, not scheduled.
- Anything requiring a hosted registry or payment/licensing infrastructure.
- Vendor namespace verification — not a live concern until a shared (published) namespace exists.
Problem statement
Skills currently have no story for sharing: no export/import, no way to install a skill pack from a git URL, and no alignment with the emerging skills.md format standard.
This turns out to be one instance of a broader gap: agent profiles, custom tools, custom apps, and routines have the same problem — hand-export only (if that), no import, and no way to move a curated collection of these things (an org preset, a personal backup) in one action. There's no single, standardized way to package and move any of these functional primitives.
Full architecture direction:
plans/pack_system.md(omnideck repo). That document is a direction-setting RFC-style doc, not yet an execution plan — phase sequencing below is proposed, not committed.What success looks like
A user can package any functional primitive — agent profile, skill, custom tool, custom app, or routine — into a single distributable "pack" (manifest + optional embedded files) and import it into another install. An organization can define a preset "bundle" (a pack whose purpose is establishing a working install state) so a new install can be provisioned to a known state in one step, the way Ansible provisions a machine. Installed packs are locked by default so a user (or the agent acting for them) can't accidentally break something installed from a trusted source, with an explicit "clone to customize" path when they want to.
A searchable, publishable community library is the long-term destination this architecture should not preclude, but it is explicitly out of scope for near-term work (see below).
Impacted repositories
Acceptance criteria
Tracks the phased breakdown in the plan doc (§12); sub-issues may be filed per phase as this is scheduled:
~/.packs/<vendor>/<pack-name>/<type>/), with per-item provenance (publisher/editable) — Phases A–B.Carried over from the original scope, not yet addressed by the architecture doc: alignment with the emerging skills.md format standard for interoperability. Needs its own resolution during Phase A/C design — flagging so it isn't dropped.
Explicitly out of scope