RFC: Skills Lifecycle Management in ToolHive CLI #30
Conversation
This RFC proposes adding skill lifecycle management capabilities to the ToolHive CLI (thv), enabling users to install, remove, list, and package Agent Skills as OCI artifacts. Key decisions: - Dedicated `thv skill` command namespace - Extend pkg/client/ for skills (convergence with MCP client system) - Hybrid state storage (per-skill metadata + index file) - Integration with groups system - Require explicit --client selection Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
amirejaz
left a comment
amirejaz
left a comment
There was a problem hiding this comment.
Overall looks good to me, added a small comment
Address PR feedback: instead of modifying thv group list behavior, add --group flag to existing thv skill list command for filtering skills by group. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
jhrozek
left a comment
jhrozek
left a comment
There was a problem hiding this comment.
I left some comments inline but overall this sounds like a good proposal
| - Enable lifecycle management of Agent Skills through dedicated `thv skill` commands | ||
| - Support installation from OCI registries with version tracking | ||
| - Distinguish between managed (installed via thv) and unmanaged (manual) skills | ||
| - Support packaging and publishing skills to any OCI-compliant registry |
There was a problem hiding this comment.
I think this is important because unlike the early days of MCP where docker:// was an established (even though minor) practice, skills are usually packaged more directly.
There was a problem hiding this comment.
that is to say, I wonder if it makes sense to add the packaging directly in the main thv command and not e.g. dockyard.
There was a problem hiding this comment.
ah yes you list it below. sorry.
| - **Auto-updates**: Automatic skill updates when registry changes (requires daemon infrastructure; post-MVP) | ||
| - **Compound skills/workflows**: Bundling multiple skills together as workflow units (separate epic) | ||
| - **Agent integration**: Managing agents alongside skills (requires additional design) | ||
| - **Skill-to-MCP dependencies**: Declaring that skills require specific MCP servers (adds complexity) |
There was a problem hiding this comment.
Is this something planned for later? I have not spent so much time with skills, but they seem like very nice "enablement layer" of MCP servers. I do agree that it seems like a separate epic.
|
|
||
| ## Non-Goals | ||
|
|
||
| - **Auto-updates**: Automatic skill updates when registry changes (requires daemon infrastructure; post-MVP) |
There was a problem hiding this comment.
but later the skill status in the doc shows upgraded and version numbers.. In general I wonder if thv.json can already track version metadata so upgrades can be made possible through e.g. thv skill upgrade
There was a problem hiding this comment.
or is the keyword automatic ? so that manual updates would be possible
| ``` | ||
|
|
||
| **Behavior:** | ||
| - Requires explicit `--client` selection (no default) |
There was a problem hiding this comment.
Why? Would it make sense to keep a list of clients we support from the get go (I think CC and Cursor have a decent skill support now) and automatically enable those? Is it because of pushback we've gotten on the client enablement of MCP servers?
| "group": "development" | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
I wonder if it would make sense to separately start building an SQL-based state, also thinking about the discussions about state management we had elsewhere
| **Manifest Annotations:** | ||
| - `org.stacklok.skillet.skill.name` | ||
| - `org.stacklok.skillet.skill.description` | ||
| - `org.stacklok.skillet.skill.version` |
There was a problem hiding this comment.
This might be something to ask @lorr1 or someone more acquainted with skills format, not sure if you'd know but I was wondering if there's any skills format version we should track? (Something like works only with CC 1.2.3+)
|
|
||
| **Reproducible Packaging:** | ||
| - Deterministic tar (sorted entries, normalized timestamps via SOURCE_DATE_EPOCH) | ||
| - Deterministic gzip (no ModTime, OS=255) |
There was a problem hiding this comment.
sorry what does OS=255 mean?
|
|
||
| | Threat | Description | Likelihood | Impact | | ||
| |--------|-------------|------------|--------| | ||
| | Malicious skill | User installs skill with malicious instructions | Medium | High | |
There was a problem hiding this comment.
this opens interesting possibilities to scan and vet the skills and have a policy to e.g. not install scripts along with skills or at least remove the executable bit.
There was a problem hiding this comment.
Although I guess this would better be done on the registry side ..
Summary
This RFC proposes adding skill lifecycle management capabilities to the ToolHive CLI (
thv), enabling users to install, remove, list, and package Agent Skills as OCI artifacts.Key Decisions
thv skillcommand namespace - Avoids conflicts with existing MCP server commandspkg/client/- Converge with existing client system rather than duplicating.thv-skill.json+ lightweight index file for fast queries--clientflag (no default to avoid mistakes)Commands
thv skill list- List installed skills (managed + unmanaged)thv skill install <ref>- Install from OCI registrythv skill uninstall <name>- Remove managed skillthv skill info <name>- Show skill detailsthv skill build <path>- Package as OCI artifactthv skill push <ref>- Push to registryOut of Scope (Post-MVP)
Related
🤖 Generated with Claude Code