en un clic
skill-creator
// Use when user asks to create, build, or add a new skill or capability to the agent
// Use when user asks to create, build, or add a new skill or capability to the agent
| name | skill-creator |
| description | Use when user asks to create, build, or add a new skill or capability to the agent |
| requires | {"env":[],"bins":[]} |
Help the owner create new skills for this agent. This skill is used by the admin sub-agent. Skills are modular capabilities defined in Markdown files that extend what the agent can do.
A skill is a directory skills/{name}/ containing a SKILL.md file with YAML frontmatter:
---
name: my-skill
description: One-line description of what this skill does (max 1024 chars)
requires:
env: [] # Environment variables needed (e.g., [OPENAI_API_KEY])
bins: [] # Binary executables needed (e.g., [curl, ffmpeg])
---
# Skill Title
Instructions for the LLM on how to use this skill...
generate-images, send-email, track-expensesrun_command, schedule_job, web_search, web_fetch)references/ subdirectory if needed)When the owner asks to create a skill, follow these steps in order:
Ask the owner:
Gather enough context to write a useful skill. Ask follow-up questions if the idea is vague.
If the skill needs external tools, APIs, or packages, research before planning:
Skip this step if the skill is straightforward and only uses built-in tools (e.g., reformatting text, filesystem operations).
Outline the skill:
Present this plan to the owner and wait for feedback before drafting.
Write the complete SKILL.md content. Show the full draft to the owner in the chat. Do not write anything to disk yet.
Ask the owner: "Does this look good? Any changes?"
Revise based on feedback. Iterate until the owner is satisfied. Do NOT write to disk until the owner explicitly approves.
Once approved, use workspace tools to:
skills/{name}/skills/{name}/SKILL.mdTell the owner the skill has been created and when it will be available:
Owner: "I want a skill that generates images using AI"
generate-images, requires REPLICATE_API_TOKEN, uses web_fetch to call Replicate API, returns image URL to the user.skills/generate-images/SKILL.md via workspace tools.Before drafting, determine whether the skill should be synchronous or asynchronous. Ask the owner explicitly:
"This skill calls an external API. Should the agent wait for the result (sync), or dispatch it as a background job and notify you when it's done (async)?
- Sync is simpler — good for fast APIs (< 30 seconds)
- Async is better for slow tasks (video generation, CI builds, model training) — the conversation continues immediately"
If the owner is unsure, recommend async for anything that typically takes more than 30 seconds.
The agent calls the API directly using run_command (curl) or web_fetch and returns the result inline. No special setup needed.
For long-running tasks, the skill instructs the agent to use schedule_job with the http-poll handler. This dispatches the work to a background runner that:
Do not create new job handlers or modify agent code. The http-poll handler is generic and works with any async API.
The SKILL.md must document the exact schedule_job call with all parameters filled in. The agent passes these through verbatim — it does not construct the payload itself.
schedule_job({
type: "http-poll",
input: {
label: "human-readable task name (shown in progress messages)",
// Submit — the initial API call
submitUrl: "https://api.example.com/run",
submitMethod: "POST",
submitHeaders: { "Authorization": "Bearer ${API_KEY}" },
submitBody: { prompt: "user's input here", model: "model-name" },
jobIdPath: "id", // dot-path to extract job ID from response
// Poll — check status until done
statusUrlTemplate: "https://api.example.com/status/${jobId}",
statusHeaders: { "Authorization": "Bearer ${API_KEY}" },
statusPath: "status", // dot-path to status field
completedStatuses: ["COMPLETED"],
failedStatuses: ["FAILED", "ERROR"],
resultPath: "output.url", // dot-path to the result on completion
errorPath: "error", // dot-path to error message on failure
// Timing
pollIntervalMs: 10000, // poll every 10s (default)
maxPollMs: 600000 // give up after 10min (default)
},
timeoutMs: 1200000 // job-level timeout (20min for video gen)
})
Owner: "I want a skill that generates videos using RunPod"
SKILL.md would include instructions like:
When the user asks to generate a video:
1. Confirm the prompt and any style preferences
2. Call schedule_job with:
- type: "http-poll"
- submitUrl: "https://api.runpod.ai/v2/${RUNPOD_ENDPOINT_ID}/run"
- submitHeaders: { "Authorization": "Bearer ${RUNPOD_API_KEY}" }
- submitBody: { input: { prompt: "<user's prompt>" } }
- jobIdPath: "id"
- statusUrlTemplate: "https://api.runpod.ai/v2/${RUNPOD_ENDPOINT_ID}/status/${jobId}"
- statusHeaders: { "Authorization": "Bearer ${RUNPOD_API_KEY}" }
- statusPath: "status"
- completedStatuses: ["COMPLETED"]
- failedStatuses: ["FAILED", "CANCELLED"]
- resultPath: "output.video_url"
3. Tell the user the job is running — they'll get the result automatically
If the skill needs an API key, store it with store_secret before creating the skill. Reference it in headers as ${ENV_VAR_NAME} — the handler resolves environment variables at runtime.
Skills can include subdirectories for additional resources:
my-skill/
├── SKILL.md (required)
└── Optional subdirs:
├── scripts/ - Executable code (Python/Bash helpers)
├── references/ - Documentation, API specs, examples
└── assets/ - Images, templates, static files
These subdirectories are detected automatically by the loader. When creating skills with helper scripts, put them in scripts/ so they're properly scanned for security before installation.
Security note: Skills with scripts are automatically scanned for dangerous patterns (shell injection, eval, crypto-mining) before installation. Critical findings block installation.