Custom Skills
Creating custom skills is worthwhile when you have functionality you want to reuse across multiple agents or share with your team. A skill packages a capability — functions, prompts, hints, and configuration — into a single reusable unit.
When to Create a Custom Skill
Create a skill when:
- You’ll use the same functionality in multiple agents
- You want to share a capability with your team
- The functionality is complex enough to benefit from encapsulation
- You want version-controlled, tested components
Just use define_tool() when:
- The function is specific to one agent
- You need quick iteration during development
- The logic is simple and unlikely to be reused
Skill Structure
Create a directory with these files:
What each file does:
Basic Custom Skill
Python
TypeScript
Required Class Attributes
Optional Attributes:
Required Methods
setup()
Initialize the skill and validate requirements:
register_tools()
Register SWAIG functions:
Optional Methods
get_hints()
get_prompt_sections()
get_global_data()
cleanup()
Suppressing Prompt Injection
By default, skills inject POM sections into the agent’s prompt via get_prompt_sections(). To suppress this behavior, set skip_prompt in the skill parameters:
When building custom skills, override _get_prompt_sections() instead of get_prompt_sections():
Namespaced Global Data Helpers
When building skills that store state in global_data, use the namespaced helper methods to avoid collisions between skill instances:
Available methods:
Parameter Schema
Define parameters your skill accepts:
Multi-Instance Skills
Support multiple instances with different configurations:
Using Custom Skills
Register the skill directory and use the custom skill in your agent:
Testing Custom Skills
1. Test the skill class directly:
2. Test with a real agent using swaig-test:
3. Validate skill structure:
Publishing and Sharing Skills
Option 1: Git Repository
Users clone and register:
Option 2: Python Package
Option 3: Environment Variable
Skill Development Best Practices
DO:
- Use descriptive SKILL_NAME and SKILL_DESCRIPTION
- Validate all parameters in setup()
- Return user-friendly error messages
- Log technical errors for debugging
- Include speech hints for better recognition
- Write clear prompt sections explaining usage
- Handle network/API failures gracefully
- Version your skills meaningfully
DON’T:
- Hard-code configuration values
- Expose internal errors to users
- Skip parameter validation
- Forget to handle edge cases
- Make setup() do heavy work (defer to first use)
- Use global state between instances