Custom skills
Create, upload or fork a skill so a recurring analysis is one click away.
A skill is a reusable, typed, versioned analysis workflow — the platform's "verbs". Custom skills let you capture a recurring analysis (the one you ran four times last quarter and will run again next quarter) and turn it into a named tool your team can invoke on demand.
Where to find this
Sidebar → Skills.
(There's a Settings → Skills link too — it's a shortcut that redirects to the same place.)
The Skills page is the catalogue: every skill in your project with run stats, examples count, and a source badge: seeded, uploaded, or forked.
Three sources
| Source | What it is |
|---|---|
| Seeded | Skills that ship with the platform (e.g. "RCA on a metric drop", "Cohort retention by signup month"). You can fork these into your project to customise. |
| Uploaded | A skill you authored as a package and uploaded |
| Forked | A copy of a seeded or canonical skill that you can then edit |
What's in a skill
Every skill has:
- Slug — unique-within-project identifier (e.g.
quarterly-channel-decomposition) - Name and description
- System prompt — the instructions the platform follows when running the skill
- Input schema (JSON schema) — what the user (or another skill) must pass in
- Output schema — what the skill returns
- Tool allowlist — which platform tools the skill is allowed to use
- Sub-skills — other skills this one calls
- References — examples, prior runs, source materials
- Model tier — which LLM tier to use (lead, brief, deep)
- Thinking budget — how much extended reasoning to allow
- Version — increments when you patch the prompt
Forking a seeded skill
The fastest way to customise: find a seeded skill that's close to what you want, click Fork, then edit.
Forking creates a copy in your project with source=forked and version reset to 1. The slug gets a _<random> suffix so it doesn't clash with the original. The new copy is completely independent — edits don't propagate back to the seeded skill.
Uploading a skill
If you've authored a skill externally (or got one from someone else), upload it as a .zip archive containing the skill definition + any sub-skills.
- Click Upload skill on the Skills page.
- Pick the archive (≤ 5 MB).
- The platform installs the skill (and any nested sub-skills) into the current project.
- Audit log records the upload.
Editing the system prompt
Open a skill's detail page → Edit prompt. Save creates a new version (the old one is preserved). The version counter increments automatically.
Note: there's no UI-level version history viewer yet (you can see the current
versionnumber but not diff against prior versions). The version data is preserved in the database — engineering can surface a UI for this when needed.
Running a skill
From a skill's detail page, click Run. You'll see the input form derived from the input schema. Fill it in, submit, watch the output stream.
Skills can also be called from a reasoning run (when the agent decides a skill is the right approach) or scheduled via a tracker.
Sharing skills across projects
Skills are project-scoped. To share a skill with another project, fork it there. To share with the whole workspace, ask your admin to promote it to the canonical project (the workspace-wide skill library) — only ontology admins and workspace owners can do that.
Tips
- Start by forking. Don't build from scratch unless nothing close exists.
- Tight input schemas, tight output schemas. A skill with vague IO is a skill the agent picks wrong.
- Use sub-skills. A skill that composes other skills stays maintainable; one giant prompt does not.
- Examples are evidence. Add a few real input/output examples in the references field — the platform uses them when generating new runs.
- Audit uploaded skills. They're code your project runs; treat them with the same review process as any other code.