# elevenlabs/skills ships ten instruction folders and an eval harness that needs a Cursor login

> The elevenlabs/skills repository is a set of ten Agent Skills for the ElevenLabs developer products, plus a Python evaluation harness. The skills work with any compatible assistant, but running their evals requires the Cursor Agent CLI and a Cursor credential.

**elevenlabs/skills** — Collections of skills for building with ElevenLabs

- Repository: https://github.com/elevenlabs/skills
- Website: https://elevenlabs.io
- Stars: 463 · Forks: 75
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/elevenlabs-skills

## Ten skill directories, each a folder of instructions

The collection is ten directories, one per product surface. `text-to-speech` turns text into lifelike speech with the AI voices, `speech-to-text` transcribes audio with timestamps, `speech-engine` adds real-time voice conversation to a custom LLM or chat agent, and `agents` builds conversational voice agents. The rest are transformations: `voice-changer` maps a recording's voice onto a different target voice as speech-to-speech, `voice-isolator` strips background noise down to the vocals, `dubbing` translates audio and video into other languages while keeping the original speakers' voices, `sound-effects` generates effects from text descriptions and `music` generates tracks by composition. The tenth is not a capability but a prerequisite: `setup-api-key`, which walks through obtaining and configuring a key. The repository is recorded as a Python project because of the evaluation harness; the skills themselves are prose and examples, not importable code.

## Every skill needs the same environment variable

Configuration is one variable for the whole collection:

```bash
export ELEVENLABS_API_KEY="your-api-key"
```

The key can be obtained through the `setup-api-key` skill or from the API keys page in the ElevenLabs dashboard. The root of the repository also ships a `.env.example` containing the same variable name with a placeholder value, so there are two mechanisms in play: an environment variable for the shell that runs the scripts, and a dotenv file for a tool that reads one. Nothing in the documentation distinguishes when to use which, and nothing documents what the key's scope is, whether it can be restricted per product, or what a request fails with when it is missing or wrong. Each skill is also said to carry an installation guide in its own `references/` folder, including how to migrate away from deprecated packages.

## The npm package called elevenlabs is the wrong package

Three SDK paths are offered, and one of them carries an explicit warning:

```bash
pip install elevenlabs
npm install @elevenlabs/elevenlabs-js
npm install -g @elevenlabs/cli
```

The Python name `elevenlabs` is correct for Python. The JavaScript name is not what anyone would guess: the note says to always use `@elevenlabs/elevenlabs-js` and not to run `npm install elevenlabs`, because that unscoped package is an outdated v1.x release. That is a live trap for an agent writing an install command, since the deprecated package occupies the obvious name and still resolves from the registry. A third path is a command line tool, installable globally from npm or through a Homebrew tap, which wraps the REST API directly and reads `ELEVENLABS_API_KEY` from the environment without extra configuration.

## The evaluations need a Cursor credential to run

The skills claim to work with any assistant that follows the Agent Skills specification, and the installation command reflects that openness:

```bash
npx skills add elevenlabs/skills
```

The evaluation harness does not share that neutrality. It needs the Cursor Agent CLI on the path, named `cursor-agent`, with the binary overridable through `CURSOR_AGENT`, and it needs Cursor authentication through either `cursor-agent login` or a `CURSOR_API_KEY`. The set of available eval models is read from `cursor-agent --list-models`, and the example invocation passes a Cursor-side model identifier. So a repository whose value proposition is assistant independence has a test suite that only runs on one assistant, and it introduces a second credential to manage alongside the ElevenLabs key. That is a defensible choice for an internal quality gate and an awkward one for a contributor who wants to verify a change without a Cursor account.

## Three minutes for triggers, fifteen for functionals

The `evals/` directory holds trigger and functional evaluations for all skills, run through one script:

```bash
python3 evals/run_all.py -v
python3 evals/run_all.py --trigger-only -v
python3 evals/run_all.py --functional-only -v
python3 evals/run_all.py --skills text-to-speech agents -v
python3 evals/run_all.py --model gpt-5.4-high -v
```

The split is the useful part. Trigger evaluations ask whether a skill fires for the right query and are estimated at about three minutes. Functional evaluations ask whether a fired skill produces correct output and are estimated at about fifteen, so the same suite costs five times as much once behaviour is checked instead of routing. The `--skills` flag takes specific directories, which makes a single-skill change cheap to verify, and `--model` picks the agent model. Two safety properties are stated: functional evals use an isolated `cursor-agent` workspace per test case, created under the results tree, and they do not modify skill sources under each skill's own directory.

## Results are a timestamped tree with a report and a JSON twin

Every run writes to `evals/results/<timestamp>/`, containing a `report.md` summary and a `results.json` for programmatic access. That layout is the whole result-handling story, and it has consequences worth planning around. Because the path is timestamped rather than stable, nothing in the repository points at a previous run, so there is no stored baseline to diff against and no record in version control of whether a change improved anything; comparisons have to be done by reading two report files side by side. Because results live under a timestamped tree inside the repository rather than in an external location, a run leaves untracked files behind unless that path is ignored. And because the JSON twin exists alongside the Markdown, a CI job can consume the machine-readable form without parsing prose, which is the detail that makes the harness usable as a gate at all.

## An mcp.json at the root is a fourth way in

Beyond the ten skill directories and `evals/`, the root holds `.agents/`, an `mcp.json`, the `.env.example` and a logo image. An MCP manifest sitting next to the skills suggests the same material can be surfaced as tool definitions for a client that speaks that protocol rather than only as assistant instructions read from disk, which would be a different integration path from `npx skills add`. What this page does not say is what that file contains: no server list, no command, no note about which skills are exposed that way, and no indication of whether it is complete or a stub. So the existence of the file is a lead rather than a documented feature. The rest of the root is unremarkable: a licence file, a gitignore and the README itself, with no build configuration for the skills because there is nothing to build.

## Conclusion

This is a well-organised instruction set rather than a library, and the two details worth knowing before you start are both about naming. First, the obvious npm package name is the deprecated one: install @elevenlabs/elevenlabs-js, not elevenlabs. Second, the evaluation harness is not vendor neutral even though the skills are, so you need a Cursor CLI and credential to run trigger or functional evals, which is worth knowing before you plan a CI job around them. The trigger evals are cheap at about three minutes and the functional ones are not at about fifteen, so run triggers on every change and functionals on a schedule. And keep the API key in the environment variable the skills expect rather than in a prompt.

## FAQ

### How do I install the ElevenLabs skills?

With `npx skills add elevenlabs/skills`. The skills follow the Agent Skills specification and are described as working with any compatible AI coding assistant, not only one vendor's client. Each skill also carries an installation guide in its own references folder for per-product setup.

### What API key do the ElevenLabs skills need?

An ElevenLabs API key set as the environment variable `ELEVENLABS_API_KEY`. You can obtain it through the `setup-api-key` skill or from the API keys page in the ElevenLabs dashboard, and the repository root ships a `.env.example` showing the same variable name with a placeholder value.

### Which JavaScript package should I install for ElevenLabs?

`@elevenlabs/elevenlabs-js`. The documentation carries an explicit warning not to run `npm install elevenlabs`, because that unscoped package is an outdated v1.x release that still resolves. A separate CLI is available as `@elevenlabs/cli`, also installable through a Homebrew tap, and it wraps the REST API while reading the API key from the environment.

### How do I run the ElevenLabs skill evaluations?

Through `python3 evals/run_all.py -v`, with `--trigger-only`, `--functional-only`, `--skills` and `--model` flags to narrow or widen the run. It requires the Cursor Agent CLI on your path plus Cursor authentication, either `cursor-agent login` or a `CURSOR_API_KEY`, and writes a report.md and results.json under evals/results/<timestamp>/.

## Sources

- [elevenlabs/skills on GitHub](https://github.com/elevenlabs/skills)
- [Issues](https://github.com/elevenlabs/skills/issues)
- [License: MIT](https://github.com/elevenlabs/skills/blob/main/LICENSE)
- [Project website](https://elevenlabs.io)
- [README](https://github.com/elevenlabs/skills/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/elevenlabs-skills