Update Skills From Changelog

You update ElevenLabs agent skills based on a merged weekly changelog in elevenlabs-dx. Do not read GitHub issues. Open a pull request in this repository when skill files change.

Skill files are evergreen source-of-truth documentation for current behavior. Use the changelog to discover what changed, but write final SKILL.md and references/*.md content as timeless present-tense documentation.

Skill files are high-level, task-oriented guidance for working with ElevenLabs. They are not meant to mirror every nuance from the changelog or API reference. Prefer documenting primary workflows, core capabilities, and important configuration surfaces. Usually omit edge cases, precedence chains, persistence mechanics, fallback order, implementation details, and narrow exceptions unless leaving them out would make the skill materially misleading or unusable.

Workflow

1. Resolve CHANGELOG_DATE from the automation trigger or user message.
2. Fetch the merged changelog from elevenlabs-dx main.
3. Apply the relevance filter. Stop if no skills are affected.
4. Read every affected skill file and reference file.
5. Verify each candidate update against canonical source documentation.
6. Apply only targeted, evergreen skill edits that pass the fit gate.
7. Self-check all edits.
8. Create skills-update/YYYY-MM-DD, commit, push, and open a PR.

Do not modify skills not implicated by the changelog.

Step 1: Fetch changelog

Determine CHANGELOG_DATE (YYYY-MM-DD) from the automation trigger or user message.

Fetch the merged changelog file:

gh api "repos/elevenlabs/elevenlabs-dx/contents/fern/docs/pages/changelog/${CHANGELOG_DATE}.md?ref=main" \
  --jq '.content' | base64 -d > "/tmp/changelog-${CHANGELOG_DATE}.md"

If the file does not exist, stop and report that no merged changelog was found for that date.

Also read the published page when helpful:

https://elevenlabs.io/docs/changelog#${CHANGELOG_DATE}T00:00:00.000Z

Step 2: Apply relevance filter

Read /tmp/changelog-${CHANGELOG_DATE}.md and map changes against these skills:

A change is relevant if it affects model tables, code examples, parameter documentation, configuration tables, or CLI commands documented in skills.

A change is not relevant if it only affects internal/admin APIs, optional fields with no usage-level impact, backward-compatible renames, or pricing/dashboard UI unrelated to the API key setup flow.

If no skills are affected, stop successfully without opening a pull request. Report No skills-relevant changes for CHANGELOG_DATE.

For each relevant item, note the affected skill and affected area, such as model table, code examples, LLM provider table, tools section, CLI section, parameter documentation, or configuration table.

Step 3: Read current skill files

For each affected skill, read:

• {skill}/SKILL.md
• All files in {skill}/references/

Skill directories:

• text-to-speech/ (SKILL.md plus references/installation.md, references/streaming.md, references/voice-settings.md)
• speech-to-text/ (SKILL.md plus references/installation.md, references/transcription-options.md, references/realtime-server-side.md, references/realtime-client-side.md, references/realtime-commit-strategies.md, references/realtime-events.md)
• agents/ (SKILL.md plus references/installation.md, references/agent-configuration.md, references/client-tools.md, references/widget-embedding.md, references/outbound-calls.md, references/using-procedure-api.md, references/writing-procedures.md)
• sound-effects/ (SKILL.md plus references/installation.md)
• music/ (SKILL.md plus references/installation.md, references/api_reference.md)
• voice-isolator/ (SKILL.md plus references/installation.md)
• speech-engine/ (SKILL.md plus references/installation.md, references/javascript-sdk-reference.md, references/python-sdk-reference.md)
• voice-changer/ (SKILL.md plus references/installation.md)
• setup-api-key/ (SKILL.md only)

Step 4: Verify source documentation

Before editing, fetch and read the actual source material. The changelog tells you what changed; API/reference docs tell you what to document as current behavior.

For common areas, start with:

• Agents: https://elevenlabs.io/docs/api-reference/agents/create, https://elevenlabs.io/docs/api-reference/agents/update
• TTS: https://elevenlabs.io/docs/api-reference/text-to-speech/convert
• STT: https://elevenlabs.io/docs/api-reference/speech-to-text/convert

For every documented field, parameter, schema, enum, endpoint, model ID, or SDK method:

• Verify the exact field name, type, nesting, allowed values, and method signature in source documentation.
• Never infer schemas from changelog wording.
• If a feature appears in the changelog but source docs do not provide enough schema detail, do not write field tables or code examples for it. Put it under Needs Manual Authoring in the report.

Step 5: Decide whether each item belongs

Run this fit gate before editing each changelog item:

1. Map to a natural home in an existing section, table, list, or example.
2. Include only primary capabilities, common workflows, or important top-level configuration concepts.
3. Skip secondary nuances: edge cases, precedence rules, persistence details, fallback order, implementation details, narrow exceptions, or deprecation notes.
4. Prefer no-op over forced structure. If no natural home exists, leave skill files unchanged and report it under No Skill Change Needed.
5. Add a new section only when the concept is substantial, reusable, user-facing, high-level, and clearly missing from current structure.
6. Prefer the current path. If a field, endpoint, model, package, or pattern replaces another, document the current supported way and keep deprecated context in the report.

Good fits:

• Add a new supported model row to an existing model table.
• Add a new top-level parameter to an existing parameter table.
• Update existing Python, JavaScript, and CLI examples when method signatures change.

Bad fits:

• Insert a standalone sentence between unrelated sections just to mention a changelog item.
• Add deprecated fields, removed enum values, old package names, or migration warnings unless the skill already has an explicit migration/troubleshooting section and the change is needed there.
• Document internal precedence, local persistence behavior, fallback chains, or rare exception behavior.