Skip to content

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

Description

@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-bankNVIDIA/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. Declarationcomponents.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 packagingplugins/<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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions