Skip to content

Skills & Tools

A Skill is a composable bundle of tools that provides capabilities to Nodes. Skills group related tools with shared configuration requirements.

FieldTypeRequiredDescription
idstringREQUIREDUnique identifier. Referenced by node skills arrays. MUST be non-empty.
namestringREQUIREDHuman-readable name.
descriptionstringREQUIREDWhat this skill provides.
categorySkillCategoryREQUIREDFunctional category.
configRecord<string, ConfigField>REQUIREDConfiguration fields required by this skill.
toolsTool[]REQUIREDTools this skill provides to nodes.
instructionstringOPTIONALNatural language expertise injected into the node prompt when this skill is referenced.
mcpMcpServerConfigOPTIONALExternal MCP server definition wired for nodes referencing this skill.

A valid Skill MUST provide at least one of tools, instruction, or mcp.

The category field classifies a skill’s function. Valid values:

CategoryDescription
gitSource control operations (commits, PRs, code search).
observabilityError tracking, logs, metrics, incident management.
tasksIssue tracking and project management.
notificationMessaging and alerting.
dataEmbeddings, vector stores, databases, ETL.
generalCatch-all for skills that don’t fit other categories.

Each entry in a skill’s config map declares a configuration value the skill needs.

FieldTypeRequiredDefaultDescription
descriptionstringREQUIREDHuman-readable description of this config field.
requiredbooleanOPTIONALfalseWhether this field must be provided for the skill to function.
envstringOPTIONALDefault environment variable name to read this value from.

A conforming executor MUST resolve config values using the following precedence:

  1. Explicit overrides — values passed directly to the executor at invocation.
  2. Environment variables — if an env field is set, read from process.env[env].

If a required config field cannot be resolved from either source, the skill MUST be treated as unavailable. The executor SHOULD NOT fail the workflow — the skill is silently excluded, and any node that listed it will execute without that skill’s tools.

Declares an external MCP (Model Context Protocol) server that provides tools to the AI model at runtime.

FieldTypeRequiredDescription
type"stdio" | "http"OPTIONALTransport type. Inferred from presence of command (stdio) or url (http) when omitted.
commandstringCONDITIONALSpawn command (stdio transport). Required if url absent.
argsstring[]OPTIONALArguments for the command.
urlstringCONDITIONALHTTP endpoint (HTTP transport). Required if command absent.
headersRecord<string, string>OPTIONALHTTP headers (HTTP transport only).
envRecord<string, string>OPTIONALEnvironment variable names the server needs. Values are human-readable descriptions, not secrets. Actual values are resolved from process.env at runtime.

A conforming executor:

  • MUST wire the MCP server only for nodes that reference the skill declaring it (node-scoped, not global).
  • MUST resolve env values from process.env at runtime (the declared values are descriptions, not secrets).
  • SHOULD prefer user-supplied MCP server configs over skill-declared ones when both exist for the same key.
FieldTypeRequiredDescription
namestringREQUIREDTool name. MUST be unique within the skill.
descriptionstringREQUIREDWhat this tool does. Provided to the AI model for tool selection.
input_schemaJSON Schema objectREQUIREDJSON Schema defining the tool’s input parameters.
handlerfunctionREQUIRED (runtime)Implementation-defined. Receives validated input and a context object. Not serialized.

A conforming executor:

  • MUST validate tool inputs against input_schema before invoking the handler.
  • MUST provide a ToolContext to the handler containing resolved config values and a logger.
  • Tool outputs are opaque JSON values. They are included in the execution trace and available to the AI model within the current node’s execution.
  • If a tool handler throws, the error is surfaced to the AI model as a tool result. The executor MUST NOT crash.

Implementations MAY provide built-in skills that are available without explicit definition by the user. Built-in skills follow the same Skill Object schema as custom skills — there is no structural distinction.

Skill IDs:

  • MUST be non-empty strings.
  • SHOULD use lowercase kebab-case (e.g., github, error-tracking, my-custom-tool).
  • MUST be unique within a workflow. If a custom skill uses the same ID as a built-in skill, the custom skill’s instruction and mcp fields take precedence, but the built-in skill’s tools remain available.

A conforming executor SHOULD document which built-in skills it provides, including their IDs, required config fields, and available tools. This catalog is implementation-specific and outside the scope of this specification.

Custom skills are authored as directories containing a SKILL.md file. The format follows the Agent Skills Open Standard.

A skill directory contains a SKILL.md file with YAML frontmatter and a markdown body:

---
name: code-standards
description: Team coding conventions for TypeScript projects
mcp:
command: npx
args: ["-y", "@company/tool-server"]
env:
API_KEY: Company API key
---
When writing TypeScript code, follow these standards:
- Use camelCase for variables and functions
- Use PascalCase for types and interfaces

The markdown body becomes the skill’s instruction, injected into the node prompt when the skill is referenced. The mcp, category, and config frontmatter fields are SWEny-specific extensions:

Frontmatter fieldRequiredDescription
nameREQUIREDSkill ID. MUST satisfy Skill ID Conventions.
descriptionOPTIONALOne-line summary. Defaults to Custom skill: <name> when omitted.
categoryOPTIONALOne of the Skill Categories. Defaults to general when omitted or invalid.
configOPTIONALMap of env-var-backed config fields with the same shape as the Config Field Object.
mcpOPTIONALExternal MCP server definition with the same shape as McpServerConfig.

A conforming executor SHOULD discover custom skills from the following directories, in priority order (highest first):

PriorityDirectoryConvention
1.sweny/skills/<name>/SKILL.mdSWEny-native
2.claude/skills/<name>/SKILL.mdClaude Code
3.agents/skills/<name>/SKILL.mdUniversal (Codex, Gemini CLI, OpenCode)
4.gemini/skills/<name>/SKILL.mdGemini CLI

On ID collision, the higher-priority directory wins. When a custom skill overrides a built-in skill ID, the custom skill’s instruction and mcp fields take precedence, but the built-in skill’s tools remain available.

# Skill definition (programmatic, not YAML — shown for illustration)
id: github
name: GitHub
description: Search code, manage issues and pull requests on GitHub.
category: git
config:
GITHUB_TOKEN:
description: GitHub personal access token or installation token.
required: true
env: GITHUB_TOKEN
tools:
- name: search_code
description: Search for code across repositories.
input_schema:
type: object
properties:
query: { type: string }
repo: { type: string }
required: [query]
- name: create_issue
description: Create a new issue in a repository.
input_schema:
type: object
properties:
repo: { type: string }
title: { type: string }
body: { type: string }
required: [repo, title]

The canonical JSON Schema for validating Skill definitions is available at spec.sweny.ai/schemas/skill.json.