Why We Built a Package Management System for Skills
Radish Skills aren’t static prompts; they’re versioned packages with dependencies, constraints, and install/upgrade flows.
Most AI “skills” today are surprisingly primitive.
They’re often just markdown files: static instructions wrapped in a label.
That can work for simple prompting, but it breaks down quickly when you need to evolve and continuously improve them.
That’s why in Radish, we designed Skills differently.
Skills as Packages, Not Prompts
In Radish, a Skill is a published, immutable, versioned snapshot.
Every published Skill has a semver version (like 1.2.0), and Skills can also declare dependencies on other Skills using semver ranges (like ^1.2.0). This gives Skills a real lifecycle: you can install them, upgrade them, and reason about what changed.
There are two “shapes” of Skills in Radish:
- Toolset Skills: a Skill that provides a comprehensive set of tools for services(e.g. gmail_send_email, gmail_create_draft are 2 out of 15 tools in the Gmail “toolset” skill).
- Composite Skills: a Skill that doesn’t define a tool itself, but instead composes other Skills via dependencies, plus constraints and setup instructions.
That means “higher level” Skills are first-class: they can be built out of other Skills and evolve over time without turning into one giant, unmaintainable prompt.
Composability (with Dependencies and Constraints)
Because Skills can depend on other Skills, you can build packages that intentionally combine capabilities.
In practice, a package can specify:
- dependencies: which underlying tools & Skills it needs
- constraints: how those dependencies should behave in the context of this Skill package
- global constraints: rules that apply across the composed setup
This is the difference between “a prompt that mentions Gmail” and “a package that actually installs required Gmail capabilities and important knowledge about it into an agent config”.
Install and Upgrade Are Real Product Features
When you import a Skill into an assistant:
- any tools in the Skill are added
- constraints are applied
- dependencies are resolved and installed
And because everything is versioned, upgrades are part of the real workflow too. Radish can compute an upgrade preview (including conflicts when a user modified something locally) and apply upgrades as a set of config deltas.
Describe the Work Instead of Worrying about Skills
One of the core UX goals of Skills is to make building assistants feel like describing work, not wiring systems.
If you ask for something that requires a capability your agent doesn’t have yet, the system can surface that it can use an existing Skill, and the import flow installs the right tools + constraints into your project.
The New Human Job: Validation
As AI becomes more capable at assembling systems, our role shifts:
- less manual construction
- more validation, testing, and iteration
That’s why Skills need lifecycles. Once a capability works, it can be packaged, versioned, published, upgraded, and improved over time.
Prompt files were the beginning.
Composable, testable, versioned Skills are what comes next.
Tutorial: How to Use (and Build) Skills
If you want a walkthrough of how Skills work in practice (including how to build your own) here’s a step-by-step tutorial:
Or open it on YouTube: Radish AI Skills Tutorial - How to use and build Skills in Radish