Skip to main content

​
What is a skill?

A skill is a set of instructions - packaged as a simple folder. It teaches an AI agent how to handle specific tasks or workflows to avoid long prompts and re-explaining your processes and domain expertise every time. A skill is a folder with structure like this: 
my-skill/
├── SKILL.md          # (required): Instructions in Markdown with YAML frontmatter
├── scripts/          # (optional): Executable code (Python, Bash, etc.)
├── references/       # (optional): Documentation loaded as needed
└── assets/           # (optional): Templates, fonts, icons used in output
Note: Folder-based skills (with scripts/, references/, and assets/ subdirectories) are created and managed via the Versuno UI. API support for multi-file skill uploads is coming soon. When creating a skill via the API, pass the contents of SKILL.md as the content field.
Skills are the most structured asset type. They solve a specific problem that prompts and contexts don’t: agents need not just knowledge and instructions, but procedures — step-by-step playbooks for recurring tasks that may involve tools, APIs, file operations, or multi-step decision trees.

​
Supported file types

Skills can include supporting files of these types: 
.md, .py, .sh, .js, .ts, .json, .yaml, .yml, .txt

​
Tips

  • Keep each skill focused on a single task so it stays reusable across agents.
  • Define allowed-tools in the frontmatter so agents know what capabilities the skill needs.
  • Use consistent file path conventions: scripts/, references/, assets/.
  • Write SKILL.md as if a developer who has never seen your codebase will follow it.
  • Test your skill across multiple AI agents to verify broad compatibility.

​
API value

"assetType": "skill"

​
Example

{
  "name": "GitHub PR reviewer",
  "assetType": "skill",
  "content": "
  ---
  name: github-pr-reviewer
  description: Review a GitHub pull request and produce a structured feedback report.
  ---

  # GitHub PR Reviewer
  Review a GitHub pull request and produce a structured feedback report.

  ## Inputs
  - `repo`: owner/repo string
  - `pr_number`: integer

  ## Steps
  1. Fetch the PR diff via GitHub API
  2. Check for breaking changes in public interfaces
  3. Check for missing tests on changed files
  4. Check for security issues (hardcoded secrets, unsafe inputs)
  5. Return a structured report with: summary, issues (severity: critical/warning/info), and suggested next steps

  ## Output format
  JSON with keys: summary, issues[], next_steps[]
  "
}