Mettre à jour les skills ElevenLabs depuis un changelog

Tu mets à jour les skill ElevenLabs en fonction du changelog hebdomadaire fusionné dans elevenlabs-dx. Ne lis pas les issues GitHub. Ouvre une pull request dans ce repository quand les fichiers de skill changent.

Les fichiers de skill sont une documentation source-de-vérité persistante pour le comportement actuel. Utilise le changelog pour découvrir ce qui a changé, mais écris le contenu final de SKILL.md et references/*.md comme une documentation intemporelle au présent.

Les fichiers de skill sont un guide de haut niveau, orienté tâches, pour travailler avec ElevenLabs. Ils ne sont pas censés refléter chaque nuance du changelog ou de la référence API. Préfère documenter les workflows principaux, les capacités essentielles et les surfaces de configuration importantes. Omets généralement les cas limites, les chaînes de précédence, la mécanique de persistance, l'ordre de secours, les détails d'implémentation et les exceptions étroites, sauf si les laisser de côté rendrait le skill matériellement trompeur ou inutilisable.

Workflow

Résous CHANGELOG_DATE à partir du déclenchement de l'automatisation ou du message utilisateur.
Récupère le changelog fusionné depuis elevenlabs-dx main.
Applique le filtre de pertinence. Arrête s'il n'y a pas de skills affectés.
Lis chaque fichier de skill et fichier de référence affectés.
Vérifie chaque candidat de mise à jour par rapport à la documentation source canonique.
Applique uniquement les édits ciblés, intemporels qui passent le filtre de pertinence.
Auto-vérifie tous les édits.
Crée skills-update/YYYY-MM-DD, commite, pousse et ouvre une PR.

Ne modifie pas les skills non impliqués par le changelog. Ne modifie pas openclaw/.

Étape 1 : Récupérer le changelog

Détermine CHANGELOG_DATE (YYYY-MM-DD) à partir du déclenchement de l'automatisation ou du message utilisateur.

Récupère le fichier changelog fusionné :

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"

Si le fichier n'existe pas, arrête et signale qu'aucun changelog fusionné n'a été trouvé pour cette date.

Lis également la page publiée le cas échéant :

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

Étape 2 : Appliquer le filtre de pertinence

Lis /tmp/changelog-${CHANGELOG_DATE}.md et mappe les changements par rapport à ces skills :

Skill	Ce qui déclenche une mise à jour
`text-to-speech`	Nouveaux/modèles dépréciés, nouveaux paramètres TTS, changements des paramètres vocaux, changements de format de sortie, changements de signature de méthode SDK pour `text_to_speech.convert()`
`speech-to-text`	Nouveaux modèles de transcription, nouveaux paramètres, schémas de réponse modifiés, changements de méthode SDK
`agents`	Nouveaux fournisseurs/modèles LLM, nouveaux types d'outils, nouveaux champs de config agent, changements de schéma de config conversation, nouvelles commandes CLI, changements de widget
`sound-effects`	Nouveaux paramètres de génération, changements de modèle, changements de méthode SDK
`music`	Nouveaux endpoints, nouveaux paramètres, changements de modèle
`voice-isolator`	Nouveaux paramètres, changements de modèle, changements de méthode SDK pour `audio_isolation.convert()`
`speech-engine`	Changements de l'API WebSocket Speech Engine, changements de token de conversation, changements de méthode SDK pour les conversations vocales en temps réel
`voice-changer`	Nouveaux paramètres de speech-to-speech, changements de modèle, changements de méthode SDK pour `speech_to_speech.convert()` ou `speechToSpeech.convert()`
`setup-api-key`	Changements du flux d'authentification, nouvelles variables d'environnement

Un changement est pertinent s'il affecte les tableaux de modèles, les exemples de code, la documentation des paramètres, les tableaux de configuration ou les commandes CLI documentés dans les skills.

Un changement n'est pas pertinent s'il affecte uniquement les APIs internes/admin, les champs optionnels sans impact au niveau de l'utilisation, les renommages rétro-compatibles, ou l'interface utilisateur des tarifs/tableau de bord.

Si aucun skill n'est affecté, arrête sans succès sans ouvrir de pull request. Signale No skills-relevant changes for CHANGELOG_DATE.

Pour chaque élément pertinent, note le skill affecté et la zone affectée, comme le tableau de modèles, les exemples de code, le tableau des fournisseurs LLM, la section tools, la section CLI, la documentation des paramètres ou le tableau de configuration.

Étape 3 : Lire les fichiers de skill actuels

Pour chaque skill affecté, lis :

{skill}/SKILL.md
Tous les fichiers dans {skill}/references/

Répertoires de skill :

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 uniquement)

Étape 4 : Vérifier la documentation source

Avant de modifier, récupère et lis le matériel source réel. Le changelog te dit ce qui a changé ; les docs API/référence te disent ce qu'il faut documenter comme comportement actuel.

Pour les zones courantes, commence par :

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

Pour chaque champ documenté, paramètre, schéma, énumération, endpoint, ID de modèle ou méthode SDK :

Vérifie le nom exact du champ, le type, l'imbrication, les valeurs autorisées et la signature de la méthode dans la documentation source.
N'infère jamais les schémas à partir du libellé du changelog.
Si une fonctionnalité apparaît dans le changelog mais que la documentation source ne fournit pas assez de détails de schéma, n'écris pas de tableaux de champs ou d'exemples de code pour elle. Mets-la sous Needs Manual Authoring dans le rapport.

Étape 5 : Décider si chaque élément convient

Applique ce filtre de pertinence avant de modifier chaque élément du changelog :

Mappe à un emplacement naturel dans une section, tableau, liste ou exemple existant.
Inclus uniquement les capacités principales, les workflows courants ou les concepts de configuration de haut niveau importants.
Ignore les nuances secondaires : cas limites, règles de précédence, détails de persistance, ordre de secours, détails d'implémentation, exceptions étroites ou notes de dépréciation.
Préfère le non-opération à la structure forcée. Si aucun emplacement naturel n'existe, laisse les fichiers de skill inchangés et signale-le sous No Skill Change Needed.
Ajoute une nouvelle section uniquement quand le concept est substantiel, réutilisable, côté utilisateur, haut niveau et clairement absent de la structure actuelle.
Préfère le chemin actuel. Si un champ, endpoint, modèle, paquet ou motif remplace un autre, documente la façon supportée actuelle et garde le contexte dépréciée dans le rapport.

Bons candidats :

Ajouter une nouvelle ligne de modèle supporté à un tableau de modèles existant.
Ajouter un nouveau paramètre de haut niveau à un tableau de paramètres existant.
Mettre à jour les exemples Python, JavaScript et cURL existants quand les signatures de méthode changent.

Mauvais candidats :

Insérer une phrase autonome entre sections non liées juste pour mentionner un élément du changelog.
Documenter les champs dépréciés, les valeurs d'énumération supprimées, les anciens noms de paquets ou les avertissements de migration sauf si le skill a déjà une section migration/dépannage explicite et le changement y est nécessaire.
Documenter la précédence interne, le comportement de persistance locale, les chaînes de secours ou le comportement d'exception rare.

Étape 6 : Faire des édits ciblés

Applique le plus petit changement utile au fichier et à la section appropriés. Respecte les niveaux de titre existants, les formats de tableau, les langages de bloc de code, l'indentation et le style de nommage.

Motifs de mise à jour :

Tableau de modèles : ajoute, supprime ou modifie les lignes dans le tableau de modèles pertinent dans SKILL.md. Vérifie les IDs de modèles et les descriptions.
Exemples de code : mets à jour les signatures de méthode, les imports et les paramètres significatifs. Garde les exemples Python, JavaScript et cURL cohérents quand tous existent.
Tableau de fournisseurs LLM : mets à jour agents/SKILL.md ou agents/references/agent-configuration.md.
Section tools : mets à jour agents/SKILL.md avec les nouveaux types d'outils dans le style existant.
Section CLI : mets à jour les exemples CLI existants dans les fichiers agents/.
Documentation des paramètres : ajoute les paramètres vérifiés à la liste ou au tableau de paramètres pertinent.
Tableaux de configuration : mets à jour les tableaux de champs dans les fichiers de référence comme agent-configuration.md ou voice-settings.md.
Tableau de format de sortie : mets à jour le tableau de format de sortie dans text-to-speech/SKILL.md.

Règles incontournables :

N'invente jamais les noms de champs, les types, les schémas, les IDs de modèles, les noms de config, les chemins d'endpoint ou les valeurs d'exemple.
N'écris jamais d'exemples de code pour les nouvelles fonctionnalités sans vérifier la forme API exacte.
Traite le changelog comme une entrée de découverte, pas comme une prose de fichier de skill.
Les fichiers de skill doivent être intemporels. Ne mentionne jamais le changelog, l'issue, la PR, la date de sortie, « added in », « introduced in », « as of » ou « now supports » à l'intérieur de SKILL.md ou references/*.md.
Documente les workflows positifs actuels, pas l'historique négatif.
Ne crée pas une nouvelle section uniquement parce qu'une puce du changelog existe.
N'insère pas de contenu orphelin.
Garde les tableaux focalisés sur les champs supportés actuels.
Si une montée de version SDK n'a pas de changement de signature de méthode, mets à jour les commentaires spécifiques à la version uniquement si de tels commentaires existent déjà.

Étape 7 : Auto-vérification avant la mise en place

Revois chaque changement et vérifie :

Chaque nom de champ modifié apparaît dans les docs source lus à l'étape 4.
Chaque exemple de code utilise les noms de paramètres vérifiés et l'imbrication.
Aucun contenu n'a été inféré du seul libellé du changelog.
Aucune valeur fabriquée ne subsiste.
Aucun fichier de skill modifié ne référence un changelog, une issue, une PR, une date de sortie ou un libellé d'historique des versions.
Chaque nouveau titre ou section est justifié par l'étape 5.
Aucune phrase orpheline ou section d'ajustement forcé ne subsiste.
Aucun contenu modifié ne documente les champs dépréciés, supprimés ou remplacés uniquement comme une guidance négative.
Chaque élément du changelog pertinent est comptabilisé comme l'un de : mise à jour docs, nouvelle section justifiée, No Skill Change Needed ou Needs Manual Authoring.

Si un changement échoue cette vérification, reviens sur cet édit et déplace l'élément vers Needs Manual Authoring ou No Skill Change Needed.

Étape 8 : Branche, commit et pull request

Utilise le nom de branche skills-update/YYYY-MM-DD.

Avant de créer une branche, vérifie l'existence d'une PR ouverte et arrête s'il en existe une :

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

Crée la branche à partir de origin/main actuel, commite uniquement si les fichiers ont changé et pousse :

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}"

Écris le rapport dans /tmp/skills-update-report.md, puis ouvre la PR :

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

S'il n'y a pas de changements de fichier après l'analyse, ne pousse pas et n'ouvre pas de PR. Signale No skill file changes needed for CHANGELOG_DATE avec les éléments pertinents sous No Skill Change Needed.

Exigences du rapport et du corps de la PR

Écris ce rapport et utilise-le comme corps de la PR :

# 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>`

## 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.

### Changes

- **skill-name**: Brief description of what changed.

### Verification

- `field_or_area` in `file.md` - verified against [API reference page](url)

### 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."

### 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](https://elevenlabs.io/docs/changelog#YYYY-MM-DDT00:00:00.000Z)
[Changelog file on GitHub](https://github.com/elevenlabs/elevenlabs-dx/blob/main/fern/docs/pages/changelog/YYYY-MM-DD.md)

Quand exécuté via Cursor Cloud Automation avec accès en écriture, ouvrir la pull request est requis sauf si aucun fichier de skill n'a changé. Retourne uniquement le rapport markdown complété dans la réponse finale sauf si l'utilisateur appelant demande explicitement un commentaire supplémentaire.

Important

Ne modifie pas le frontmatter YAML dans les fichiers de skill sauf si le changelog le nécessite spécifiquement.
Garde les dates du changelog et le libellé de l'historique des versions dans le contexte du rapport/PR uniquement.
Préfère le non-opération à la structure forcée quand un élément du changelog n'a pas d'emplacement naturel.
Un mauvais exemple de code est pire qu'un manquant.
Si la couverture du changelog ne donne que les noms des fonctionnalités et les descriptions de haut niveau sans docs source ou détails de schéma, mets ces éléments sous Needs Manual Authoring.

update-skills-from-changelog