Summary
Consider supporting an external reusable skill framework so that skills can be shared, discovered, and reused across different agent frameworks and agent applications, instead of being copied and re-implemented separately for each runtime.
Motivation or Use Case
Today, reusable task capabilities are often fragmented across different agent ecosystems.
In practice, the same capability is frequently implemented multiple times in different forms:
- prompt snippets
- custom tools
- local scripts
- agent-specific skill folders
- framework-specific wrappers
This creates several problems:
- the same skill is repeatedly copied across projects and gradually diverges
- users must rewrite or adapt the same capability for each framework or agent application
- there is no consistent way to manage skill metadata, constraints, usage boundaries, and execution resources
- cross-agent reuse is much harder than it should be
A reusable external skill framework could help solve this by making a skill a portable capability unit rather than a framework-local implementation detail.
This would benefit:
- end users who want to reuse the same skill across multiple agents
- framework maintainers who want a cleaner extension model
- teams managing shared internal skill libraries
- the broader ecosystem by improving interoperability
Proposed Change
Consider adding support for an external skill framework or skill specification that can be consumed by this project.
The goal is not to replace the project’s current plugin / tool / prompt system, but to make it easier to interoperate with reusable skills defined outside a single runtime.
A possible support scope could include:
1. Recognize a portable skill package
Support a skill as a self-contained directory that may include:
- a manifest such as
SKILL.md
- instructions and usage boundaries
- referenced scripts or commands
- local resources and supporting files
- metadata describing inputs, outputs, and execution assumptions
2. Allow skill discovery / loading
Provide a way for this project to:
- load an external skill directory
- expose selected skills to the agent
- keep skills separate from project-local prompts or tools
3. Preserve framework-native behavior
The project can still keep its own native abstractions.
This feature could simply act as an adapter layer, for example:
- external skill -> native tool / plugin / prompt wrapper
- external metadata -> framework-specific runtime configuration
4. Support partial interoperability first
Initial support does not need to be full or automatic.
Even a first step such as:
- recognizing skill manifests
- importing basic metadata
- mapping skill instructions into the project’s extension model
would already improve interoperability significantly.
5. Optional future directions
If maintainers think this is valuable, future support could include:
- skill import / export
- selective skill activation
- external skill registries
- versioning and dependency metadata
- trust / verification / security scanning integration
Alternatives Considered
Alternative 1: Keep each framework’s current extension mechanism only
This is simple in the short term, but it keeps skills siloed inside each ecosystem and increases repeated work across projects.
Alternative 2: Users manually port skills into this framework
This works, but it is expensive, error-prone, and leads to fragmentation as copied versions drift over time.
Alternative 3: Build one-off adapters per skill
This can solve specific cases, but it does not address the broader interoperability problem and does not scale well.
Preferred direction
A lightweight compatibility layer for external reusable skills would provide value without requiring the project to abandon its native design.
Documentation or Example Impact
If adopted, the following would likely need updates:
- extension / plugin / tool documentation
- examples showing how an external skill can be loaded or adapted
- guidance on supported manifest fields and limitations
- migration notes for users who want to reuse existing skills
Additional Context
The broader idea is to treat a skill not just as a prompt or a single tool call, but as a reusable capability unit that may contain:
- task knowledge
- usage constraints
- execution methods
- supporting resources
This makes skills easier to share across agents, frameworks, and applications.
I am proposing this because cross-agent skill reuse is still unnecessarily hard today, and this project is in a strong position to help improve interoperability in the ecosystem.
If useful, I’d be happy to provide:
- a concrete example skill package
- a proposed manifest mapping
- an adapter design sketch for this project
Summary
Consider supporting an external reusable skill framework so that skills can be shared, discovered, and reused across different agent frameworks and agent applications, instead of being copied and re-implemented separately for each runtime.
Motivation or Use Case
Today, reusable task capabilities are often fragmented across different agent ecosystems.
In practice, the same capability is frequently implemented multiple times in different forms:
This creates several problems:
A reusable external skill framework could help solve this by making a skill a portable capability unit rather than a framework-local implementation detail.
This would benefit:
Proposed Change
Consider adding support for an external skill framework or skill specification that can be consumed by this project.
The goal is not to replace the project’s current plugin / tool / prompt system, but to make it easier to interoperate with reusable skills defined outside a single runtime.
A possible support scope could include:
1. Recognize a portable skill package
Support a skill as a self-contained directory that may include:
SKILL.md2. Allow skill discovery / loading
Provide a way for this project to:
3. Preserve framework-native behavior
The project can still keep its own native abstractions.
This feature could simply act as an adapter layer, for example:
4. Support partial interoperability first
Initial support does not need to be full or automatic.
Even a first step such as:
would already improve interoperability significantly.
5. Optional future directions
If maintainers think this is valuable, future support could include:
Alternatives Considered
Alternative 1: Keep each framework’s current extension mechanism only
This is simple in the short term, but it keeps skills siloed inside each ecosystem and increases repeated work across projects.
Alternative 2: Users manually port skills into this framework
This works, but it is expensive, error-prone, and leads to fragmentation as copied versions drift over time.
Alternative 3: Build one-off adapters per skill
This can solve specific cases, but it does not address the broader interoperability problem and does not scale well.
Preferred direction
A lightweight compatibility layer for external reusable skills would provide value without requiring the project to abandon its native design.
Documentation or Example Impact
If adopted, the following would likely need updates:
Additional Context
The broader idea is to treat a skill not just as a prompt or a single tool call, but as a reusable capability unit that may contain:
This makes skills easier to share across agents, frameworks, and applications.
I am proposing this because cross-agent skill reuse is still unnecessarily hard today, and this project is in a strong position to help improve interoperability in the ecosystem.
If useful, I’d be happy to provide: