Feature Request: Bundle-level shared assets: let a plugin/component carry assets shared across many skills

[christinayyw]

Problem Statement

The catalog sync mirrors per-skill directories (the Agent Skills spec treats each skill as a portable, self-contained dir), so any repo-root / plugin-level asset that lives outside a skill dir is dropped by design. That breaks skill sets whose skills aren't standalone.

Our TAO skills (NVIDIA-TAO/tao-skills-bank → NVIDIA/skills, ~57 tao-* skills) form a chained, multi-skill workflow (data prep → train → eval → deploy) where the agent hands off across skills. Four cross-cutting assets drive that orchestration and are required for the signed copies to run end-to-end — none survive the per-skill sync:

Asset	Role	Skills depending	Why shared, not per-skill
versions.yaml	Single source of truth for container image tags + SDK wheel pins	33	One file must pin every workflow step to the same image/SDK versions; per-skill copies drift out of sync
scripts/ (resolve_tao_image.py, check_tao_launch_preflight.py, list_tao_*)	Shared helpers skills invoke at runtime	~57 (≈ all)	The same helpers are called by nearly every skill; per-skill copies mean ~57× duplication + re-sign churn on every change
hooks/session_start.sh (+ hooks.json)	SessionStart hook: injects cross-skill discovery/orchestration guidance + setup checks	every session	Must fire once per session to set up and route the multi-skill flow — not meaningful inside a single skill
AGENTS.md (+ scripts/install-codex-agents.sh)	Agent instructions + Codex agent install	Codex backend	Plugin-level instructions that guide the agent across skills; cross-skill orchestration can't live in one skill dir

Proposed Design

Introduce a bundle-level shared-assets concept at the plugin/component layer (above individual skills), carried by the sync and included in the plugin-bundle distribution.

1. Declaration — components.d/<component>.yml gains an optional block:

   shared:
     dest: components/tao-toolkit/        # stable bundle root in the catalog
     paths:                               # copied verbatim, outside skills/
       - versions.yaml
       - scripts/
       - AGENTS.md
     hooks:
       - hooks/session_start.sh           # registered as a plugin SessionStart hook

2. Sync — these are rsync'd to a stable per-component bundle root (e.g. components/<name>/ or plugins/<plugin>/shared/), not under skills/, so they survive the per-skill mirror.
3. Resolution — skills locate shared assets via a documented stable path or env (e.g. $SKILL_BUNDLE_ROOT), so a skill finds versions.yaml / scripts/ regardless of where the catalog places them.
4. Plugin packaging — plugins/<plugin>/ bundles the shared dir alongside the curated skills, so the installed plugin ships them.
5. Hooks — a component/plugin can register a SessionStart hook from the bundle (fires once per session, not per skill).
6. Signing / trust — the shared bundle is signable like a skill (extend skill.oms.sig coverage or add a bundle-level signature) so it's verified end-to-end.

Alternatives Considered

• Bootstrap / setup skill (interim, adopting now): consolidate the shared assets into one tao-setup skill that ships its own scripts/ + SessionStart hook; other skills instruct "run TAO setup first." Works today, but: (a) cross-skill access to its scripts/ / versions.yaml relies on brittle sibling-relative paths under skills/; (b) the hook only fires if that skill is installed/enabled; (c) doesn't generalize — the ~57 skills that call shared helpers directly still can't reference them without duplication or fragile paths.
• Inline into all ~57 skills: heavy duplication, version drift, and re-signing churn on every change to a shared file.

Category

enhancement: distribution channel (plugin / marketplace) (also touches enhancement: catalog / sync workflow)

Checklist

• I searched existing issues and this is not a duplicate
• This is a design proposal, not a "please build this" request

[jasonnvidia]

hi @christinayyw - I know it's been a month since you wrote this. We have skills based plugin generation support and a plugins.d/xxxxx.yml flow. Which might not have existed when you wrote this. See example https://github.com/NVIDIA/skills/blob/main/plugins.d/nvidia-skills.yml#L52
I think we could extend this to allow external repo references and a sync of more than skills into the plugin - hooks, mcp, subagents

Is this still relevant to you? Because we do want to come up with the approach to grow plugins to be more than just skills.
Bundle level signing is also interesting and we might need to track that outside this sync; currently the external scanning CI generates these .sigs.