Add SkillProvider SPI for pluggable skill backends

[danielvolovik96]

Problem Statement

Currently, the SkillsTool is tightly coupled to file-system–based skill loading. All skill resolution logic lives inside SkillsFunction, making it impossible to plug in alternative skill sources (e.g., remote registries, databases, classpath-based providers) without modifying the core class.

This limits extensibility for users who want to integrate skills from non-filesystem backends.

---

Proposed Solution

Introduce a SkillProvider SPI (Service Provider Interface) that decouples skill discovery and loading from the SkillsTool core:

• SkillProvider interface — defines listSkills() and loadSkill(name) methods for pluggable skill backends
• SkillDescriptor interface — describes a skill's metadata (name, description) without loading its full content
• FileSystemSkillProvider — default implementation preserving existing file-system behavior
• SkillsTool.Builder.addSkillProvider() — allows registering custom providers
• Full backward compatibility with addSkillsDirectory() / addSkillsResource() API

This enables community contributors to implement custom SkillProvider implementations for their own backends while keeping the default behavior unchanged.

[tzolov]

Hi @danielvolovik96,

The current implementation follows the agent-skills specification (https://agentskills.io/specification) to ensure compatibility, portability, and interoperability. The spec strictly requires a file-system-based, Markdown skill format — custom backends would likely break this.

Could you share more about your reasoning for a different approach?

[danielvolovik96]

Hey @tzolov,

To be clear — this doesn't replace or bypass the agent-skills spec. The file-system-based flow remains the default, and FileSystemSkillProvider is just a thin wrapper over the existing logic. The SPI only adds an extension point alongside it.

Our use case: the service using this library is owned by my team, but the skills and system prompts are managed by a separate team that doesn't have access to our repo. We need them to be able to update skill content (e.g. in a database) without requiring us to redeploy. A pluggable provider lets us pull those updates dynamically at invocation time while keeping full backward compatibility for file-system-based skills.