update-skills-from-changelog

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

你需要基于elevenlabs-dx中已合并的每周更新日志更新ElevenLabs Agent技能文档。请勿查看GitHub议题。当技能文件发生变更时，在该仓库中创建拉取请求。

技能文件是关于当前功能的常青式权威文档。使用更新日志发现变更内容，但最终的

SKILL.md

和

references/*.md

文档需以无时间限制的现在时态撰写。

技能文件是面向ElevenLabs使用的高层级、任务导向型指南，无需完全复刻更新日志或API参考中的每一个细节。优先记录核心工作流、核心能力和重要配置层面的内容。通常可忽略边缘情况、优先级链、持久化机制、 fallback顺序、实现细节和特殊例外，除非省略这些内容会导致技能文档产生实质性误导或无法使用。

Workflow

工作流

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

Do not modify skills not implicated by the changelog.

从自动化触发器或用户消息中解析
```
CHANGELOG_DATE
```
。
从elevenlabs-dx的main分支获取已合并的更新日志。
应用相关性筛选。若没有技能受影响则停止操作。
读取所有受影响的技能文件和参考文件。
对照权威源文档验证每一项候选更新内容。
仅应用通过适配校验的、针对性的常青式技能文档编辑。
自行检查所有编辑内容。
创建
```
skills-update/YYYY-MM-DD
```
分支，提交、推送并创建PR。

请勿修改更新日志未提及的技能。

Step 1: Fetch changelog

步骤1：获取更新日志

Determine

CHANGELOG_DATE

(

YYYY-MM-DD

) from the automation trigger or user message.

Fetch the merged changelog file:

bash

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

从自动化触发器或用户消息中确定

CHANGELOG_DATE

（格式为

YYYY-MM-DD

）。

获取已合并的更新日志文件：

bash

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"

若文件不存在，停止操作并报告未找到该日期的已合并更新日志。

必要时也可查看已发布的页面：

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

Step 2: Apply relevance filter

步骤2：应用相关性筛选

Read

/tmp/changelog-${CHANGELOG_DATE}.md

and map changes against these skills:

Skill	What triggers an update
`text-to-speech`	New/deprecated models, new TTS parameters, voice settings changes, output format changes, SDK method signature changes for `text_to_speech.convert()`
`speech-to-text`	New transcription models, new parameters, changed response schemas, SDK method changes
`agents`	New LLM providers/models, new tool types, new agent config fields, conversation config schema changes, new CLI commands, widget changes
`sound-effects`	New generation parameters, model changes, SDK method changes
`music`	New endpoints, new parameters, model changes
`voice-isolator`	New parameters, model changes, SDK method changes for `audio_isolation.convert()`
`speech-engine`	Speech Engine WebSocket API changes, conversation token changes, SDK method changes for real-time voice conversations
`voice-changer`	New speech-to-speech parameters, model changes, SDK method changes for `speech_to_speech.convert()` or `speechToSpeech.convert()`
`setup-api-key`	Authentication flow changes, API key dashboard changes, environment variable guidance

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.

读取

/tmp/changelog-${CHANGELOG_DATE}.md

，并将变更内容与以下技能进行匹配：

技能	触发更新的条件
`text-to-speech`	新增/弃用模型、新增TTS参数、语音设置变更、输出格式变更、 `text_to_speech.convert()` 的SDK方法签名变更
`speech-to-text`	新增转录模型、新增参数、响应 schema 变更、SDK方法变更
`agents`	新增LLM提供商/模型、新增工具类型、新增Agent配置字段、对话配置schema变更、新增CLI命令、组件变更
`sound-effects`	新增生成参数、模型变更、SDK方法变更
`music`	新增端点、新增参数、模型变更
`voice-isolator`	新增参数、模型变更、 `audio_isolation.convert()` 的SDK方法变更
`speech-engine`	Speech Engine WebSocket API变更、对话令牌变更、实时语音对话相关的SDK方法变更
`voice-changer`	新增语音转语音参数、模型变更、 `speech_to_speech.convert()` 或 `speechToSpeech.convert()` 的SDK方法变更
`setup-api-key`	认证流程变更、API密钥控制台变更、环境变量配置指南变更

若变更内容影响技能文档中的模型表格、代码示例、参数文档、配置表格或CLI命令，则视为相关变更。

若变更仅涉及内部/管理API、对使用层面无影响的可选字段、向后兼容的重命名，或与API密钥设置流程无关的定价/控制台UI变更，则视为不相关变更。

若没有技能受影响，无需创建拉取请求，直接完成操作并报告

No skills-relevant changes for CHANGELOG_DATE

。

针对每一项相关变更，记录受影响的技能和领域，例如模型表格、代码示例、LLM提供商表格、工具章节、CLI章节、参数文档或配置表格。

Step 3: Read current skill files

步骤3：读取当前技能文件

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

)

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)

针对每一项受影响的技能，读取：

```
{skill}/SKILL.md
```
```
{skill}/references/
```
下的所有文件

技能目录：

text-to-speech/

（包含

SKILL.md

及

references/installation.md

、

references/streaming.md

、

references/voice-settings.md

）

speech-to-text/

（包含

SKILL.md

及

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

及

references/installation.md

、

references/agent-configuration.md

、

references/client-tools.md

、

references/widget-embedding.md

、

references/outbound-calls.md

）

sound-effects/

（包含

SKILL.md

及

references/installation.md

）

music/

（包含

SKILL.md

及

references/installation.md

、

references/api_reference.md

）

voice-isolator/

（包含

SKILL.md

及

references/installation.md

）

speech-engine/

（包含

SKILL.md

及

references/installation.md

、

references/javascript-sdk-reference.md

、

references/python-sdk-reference.md

）

voice-changer/

（包含

SKILL.md

及

references/installation.md

）

```
setup-api-key/
```
（仅包含
```
SKILL.md
```
）

Step 4: Verify source documentation

步骤4：验证源文档

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.

在编辑之前，获取并阅读实际的源材料。更新日志仅告知变更内容，而API/参考文档才是当前功能的权威记录依据。

针对常见领域，可从以下链接开始：

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

针对每一个已记录的字段、参数、schema、枚举、端点、模型ID或SDK方法：

在源文档中验证确切的字段名称、类型、嵌套结构、允许值和方法签名。
切勿仅根据更新日志的描述推断schema。
若某项功能出现在更新日志中，但源文档未提供足够的schema细节，则不要为其编写字段表格或代码示例，将其归入报告中的
```
Needs Manual Authoring
```
部分。

Step 5: Decide whether each item belongs

步骤5：判断内容是否适合加入

Run this fit gate before editing each changelog item:

Map to a natural home in an existing section, table, list, or example.
Include only primary capabilities, common workflows, or important top-level configuration concepts.
Skip secondary nuances: edge cases, precedence rules, persistence details, fallback order, implementation details, narrow exceptions, or deprecation notes.
Prefer no-op over forced structure. If no natural home exists, leave skill files unchanged and report it under
```
No Skill Change Needed
```
.
Add a new section only when the concept is substantial, reusable, user-facing, high-level, and clearly missing from current structure.
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 cURL 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.

在编辑每一项更新日志内容之前，先执行以下适配校验：

为内容找到现有章节、表格、列表或示例中的合理位置。
仅包含核心能力、常用工作流或重要的顶层配置概念。
跳过次要细节：边缘情况、优先级规则、持久化细节、fallback顺序、实现细节、特殊例外或弃用说明。
若无合理位置，宁愿不做修改也不要强行添加结构。若找不到合适的位置，保持技能文件不变，并将其归入
```
No Skill Change Needed
```
部分。
仅当概念具有实质性、可复用性、面向用户、高层级且当前结构明显缺失时，才新增章节。
优先记录当前可用方案。若某个字段、端点、模型、包或模式替代了原有方案，仅记录当前支持的方式，并将弃用相关内容归入报告。

适合加入的内容：

在现有模型表格中添加新的支持模型行。
在现有参数表格中添加新的顶层参数。
当方法签名变更时，更新现有的Python、JavaScript和cURL示例。

不适合加入的内容：

在不相关章节之间插入独立句子以提及更新日志内容。
添加弃用字段、已移除的枚举值、旧包名称或迁移警告，除非技能文档已有明确的迁移/故障排除章节且该变更需在此处记录。
记录内部优先级、本地持久化行为、fallback链或罕见异常行为。

Step 6: Make targeted edits

步骤6：进行针对性编辑

Apply the smallest useful change to the correct file and section. Match existing heading levels, table formats, code block languages, indentation, and naming style.

Update patterns:

Model table: add, remove, or modify rows in the relevant
```
SKILL.md
```
model table. Verify model IDs and descriptions.
Code examples: update method signatures, imports, and significant parameters. Keep Python, JavaScript, and cURL examples consistent when all exist.

LLM provider table: update

agents/SKILL.md

agents/references/agent-configuration.md

Tools section: update
```
agents/SKILL.md
```
with new tool types in the existing style.
CLI section: update existing CLI examples in
```
agents/
```
files.
Parameter documentation: add verified parameters to the relevant parameter list or table.
Configuration tables: update field tables in reference files such as
```
agent-configuration.md
```
or
```
voice-settings.md
```
.
Output format table: update the output format table in
```
text-to-speech/SKILL.md
```
.

Hard rules:

Never invent field names, types, schemas, model IDs, config names, endpoint paths, or example values.
Never write code examples for new features without verifying the exact API shape.
Treat the changelog as discovery input, not skill-file prose.
Skill files must be evergreen. Never mention changelog, issue, PR, release date, "added in", "introduced in", "as of", or "now supports" inside
```
SKILL.md
```
or
```
references/*.md
```
.
Document current positive workflows, not negative history.
Do not create a new section solely because a changelog bullet exists.
Do not insert orphan content.
Keep tables focused on supported current fields.
If an SDK version bump has no method signature change, update version-specific comments only if such comments already exist.

对正确的文件和章节做出最小且有效的变更。匹配现有标题层级、表格格式、代码块语言、缩进和命名风格。

更新模式：

模型表格：在相关的
```
SKILL.md
```
模型表格中添加、删除或修改行。验证模型ID和描述。
代码示例：更新方法签名、导入语句和重要参数。若同时存在Python、JavaScript和cURL示例，保持它们的一致性。

LLM提供商表格：更新

agents/SKILL.md

或

agents/references/agent-configuration.md

。

工具章节：按照现有风格在
```
agents/SKILL.md
```
中更新新增的工具类型。
CLI章节：更新
```
agents/
```
文件中的现有CLI示例。
参数文档：将已验证的参数添加到相关的参数列表或表格中。
配置表格：更新参考文件（如
```
agent-configuration.md
```
或
```
voice-settings.md
```
）中的字段表格。
输出格式表格：更新
```
text-to-speech/SKILL.md
```
中的输出格式表格。

硬性规则：

切勿自行编造字段名称、类型、schema、模型ID、配置名称、端点路径或示例值。
若未验证确切的API结构，切勿为新功能编写代码示例。
将更新日志视为发现变更的输入，而非技能文档的文案来源。
技能文档必须是常青式的。切勿在
```
SKILL.md
```
或
```
references/*.md
```
中提及更新日志、议题、PR、发布日期、“新增于”、“引入于”、“自版本起”或“现已支持”等表述。
记录当前可用的正向工作流，而非负面历史。
切勿仅因更新日志中有相关条目就新增章节。
切勿插入孤立内容。
表格仅聚焦于当前支持的字段。
若SDK版本升级未导致方法签名变更，仅当已有版本相关注释时才更新该注释。

Step 7: Self-check before committing

步骤7：提交前自行检查

Review every change and verify:

Every edited field name appears in the source docs read in Step 4.
Every code example uses verified parameter names and nesting.
No content was inferred from changelog wording alone.
No fabricated values remain.
No edited skill file references a changelog, issue, PR, release date, or release-history phrasing.
Every new heading or section is justified by Step 5.
No orphan sentences or forced one-off sections remain.
No edited content documents deprecated, removed, or replaced fields solely as negative guidance.
Every relevant changelog item is accounted for as one of: docs update, justified new section,
```
No Skill Change Needed
```
, or
```
Needs Manual Authoring
```
.

If any change fails this check, revert that edit and move the item to

Needs Manual Authoring

No Skill Change Needed

复查所有变更并验证：

每一个编辑的字段名称都出现在步骤4中读取的源文档里。
每一个代码示例都使用已验证的参数名称和嵌套结构。
没有内容仅根据更新日志的描述推断得出。
没有虚构的值残留。
编辑后的技能文件未提及更新日志、议题、PR、发布日期或版本历史相关表述。
每一个新增标题或章节都符合步骤5的要求。
没有孤立句子或强行添加的一次性章节残留。
编辑后的内容未仅作为负面指南记录弃用、移除或替代的字段。
每一项相关的更新日志条目都已归类为：文档更新、合理新增章节、
```
No Skill Change Needed
```
或
```
Needs Manual Authoring
```
。

若任何变更未通过此检查，撤销该编辑并将条目归入

Needs Manual Authoring

或

No Skill Change Needed

。

Step 8: Branch, commit, and pull request

步骤8：创建分支、提交并创建拉取请求

Use branch name

skills-update/YYYY-MM-DD

Before creating a branch, check for an existing open PR and stop if one exists:

bash

gh pr list --repo elevenlabs/skills --head "skills-update/${CHANGELOG_DATE}" --state open --json number --jq 'length == 0'

Create the branch from current

origin/main

, commit only if files changed, and push:

bash

git fetch origin main
git checkout -b "skills-update/${CHANGELOG_DATE}" origin/main
git add -A
git diff --cached --quiet || git commit -m "Update skills from changelog ${CHANGELOG_DATE}"
git push -u origin "skills-update/${CHANGELOG_DATE}"

Write the report to

/tmp/skills-update-report.md

, then open the PR:

bash

gh pr create --repo elevenlabs/skills \
  --base main \
  --head "skills-update/${CHANGELOG_DATE}" \
  --title "Update skills from changelog ${CHANGELOG_DATE}" \
  --body-file /tmp/skills-update-report.md

If there are no file changes after analysis, do not push or open a PR. Report

No skill file changes needed for CHANGELOG_DATE

with relevant items under

No Skill Change Needed

使用分支名称

skills-update/YYYY-MM-DD

。

在创建分支之前，检查是否存在已打开的PR，若存在则停止操作：

bash

gh pr list --repo elevenlabs/skills --head "skills-update/${CHANGELOG_DATE}" --state open --json number --jq 'length == 0'

基于当前的

origin/main

创建分支，仅当文件变更时才提交并推送：

bash

git fetch origin main
git checkout -b "skills-update/${CHANGELOG_DATE}" origin/main
git add -A
git diff --cached --quiet || git commit -m "Update skills from changelog ${CHANGELOG_DATE}"
git push -u origin "skills-update/${CHANGELOG_DATE}"

将报告写入

/tmp/skills-update-report.md

，然后创建PR：

bash

gh pr create --repo elevenlabs/skills \
  --base main \
  --head "skills-update/${CHANGELOG_DATE}" \
  --title "Update skills from changelog ${CHANGELOG_DATE}" \
  --body-file /tmp/skills-update-report.md

若分析后没有文件变更，请勿推送或创建PR。报告

No skill file changes needed for CHANGELOG_DATE

，并将相关条目归入

No Skill Change Needed

。

Report and PR body requirements

报告和PR正文要求

Write this report and use it as the PR body:

markdown

undefined

撰写以下报告并将其作为PR正文：

markdown

undefined

Skills Update Report

技能文档更新报告

Outcome

结果

Changelog:
```
YYYY-MM-DD
```
Branch:
```
skills-update/YYYY-MM-DD
```
Commit:
```
<commit sha or "No commit created">
```
Pull request:
```
<PR URL or "No PR created">
```

Result:

<updated skills | no skill changes needed | partial update>

更新日志：
```
YYYY-MM-DD
```
分支：
```
skills-update/YYYY-MM-DD
```
提交：<提交哈希或"未创建提交">
拉取请求：<PR链接或"未创建PR">
结果：<已更新技能 | 无需更新技能 | 部分更新>

Summary

摘要

Updates skills based on the merged weekly changelog.

If the changelog describes breaking API or SDK changes, add a short warning here describing which examples or docs may need migration guidance.

基于已合并的每周更新日志更新技能文档。

若更新日志描述了破坏性API或SDK变更，在此处添加简短警告说明哪些示例或文档可能需要迁移指南。

Changes

变更内容

skill-name: Brief description of what changed.

技能名称：变更内容的简要描述。

Verification

验证信息

```
field_or_area
```
in
```
file.md
```
- verified against API reference page

```
字段或领域
```
in
```
file.md
```
- 已对照API参考页面验证

Needs Manual Authoring

需要人工编写

List changelog items that were not applied because the schema could not be verified. Include what the changelog said, why it could not be verified, and the source link to check later.

If no items apply, write "None."

列出因无法验证schema而未应用的更新日志条目。包含更新日志中的描述、无法验证的原因以及后续检查的源链接。

若无相关条目，填写“无”。

No Skill Change Needed

无需更新技能文档

List verified changelog items intentionally not added to skill files because they have no natural home or are too low-level for skills. Include what changed, why no edit was appropriate, and the source link.

If no items apply, write "None."

列出已验证但未添加到技能文档的更新日志条目，原因是没有合适位置或内容过于底层不适合技能文档。包含变更内容、不适合编辑的原因以及源链接。

若无相关条目，填写“无”。

Open Questions

待解决问题

List blockers, ambiguous source material, or follow-up items.

If no items apply, write "None."

列出阻塞项、模糊的源材料或后续事项。

若无相关条目，填写“无”。

Source

来源

Changelog YYYY-MM-DD Changelog file on GitHub


When run in an automated/headless agent environment with repository write access, opening the pull request is required unless no skill files changed. Return only the completed markdown report in the final response unless the invoking user explicitly asks for extra commentary.

更新日志 YYYY-MM-DD GitHub上的更新日志文件


当在具有仓库写入权限的自动化/无头Agent环境中运行时，除非没有技能文件变更，否则必须创建拉取请求。最终响应仅返回已完成的Markdown报告，除非调用用户明确要求额外说明。

Important

重要提示

Do not change YAML frontmatter in skill files unless the changelog specifically requires it.
Keep changelog dates and release-history wording in the report/PR context only.
Prefer no-op over forced structure when a changelog item has no natural home.
A wrong code example is worse than a missing one.
If changelog coverage only gives feature names and high-level descriptions without source docs or schema details, put those items under
```
Needs Manual Authoring
```
.

除非更新日志明确要求，否则请勿修改技能文件中的YAML前置内容。
仅在报告/PR语境中保留更新日志日期和版本历史表述。
若更新日志条目没有合适位置，宁愿不做修改也不要强行添加结构。
错误的代码示例比缺失的代码示例更糟糕。
若更新日志仅提供功能名称和高层级描述，而无源文档或schema细节，将这些条目归入
```
Needs Manual Authoring
```
。