update-skills-from-changelog について
マージ済みの週次チェンジログを確認し、ElevenLabs のスキル文書を更新するエージェントスキルです。関連性の判定、一次資料での確認、編集、セルフチェック、プルリクエスト作成を案内します。
主な機能
- 01日付指定でマージ済みチェンジログを取得
- 02変更を対象スキルに対応付け
- 03公式文書で内容を確認
- 04長期利用できる文書を限定的に編集
- 05変更を確認してプルリクエストを作成
活用シーン
- 01週次 API 変更後のスキルファイル更新
- 02スキルに関係するチェンジログ項目の選別
- 03文書変更の準備と提出
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ elevenlabs/ skills --skill update-skills-from-changelogインストール後、Claude Code で/update-skills-from-changelogを入力して読み込まれたか確認します。
詳細
elevenlabs-dx にマージされた週次変更履歴に基づいて、ElevenLabs エージェントのスキルを更新します。GitHub のイシューは読まないでください。スキルファイルに変更がある場合は、このリポジトリでプルリクエストを作成してください。
スキルファイルは、現在の動作を示す、常に最新の信頼できるドキュメントです。変更履歴は変更点を把握するために使いますが、最終的な SKILL.md と references/*.md の内容は、時代に左右されない現在形のドキュメントとして記述してください。
スキルファイルは、ElevenLabs の使い方を説明する、概括的でタスク指向のガイダンスです。変更履歴や API リファレンスの細部をすべて反映するものではありません。主要なワークフロー、中心的な機能、重要な設定項目を優先して記載してください。省略するとスキルの内容が著しく誤解を招いたり、使いものにならなくなったりする場合を除き、通常はエッジケース、優先順位の連鎖、永続化の仕組み、フォールバックの順序、実装の詳細、限定的な例外は省略してください。
ワークフロー
- 自動化のトリガーまたはユーザーメッセージから
CHANGELOG_DATEを特定します。 elevenlabs-dxのmainからマージ済みの変更履歴を取得します。- 関連性フィルターを適用します。影響を受けるスキルがなければ終了します。
- 影響を受けるスキルファイルとリファレンスファイルをすべて読みます。
- 候補となる更新内容を、信頼できる正規のドキュメントで確認します。
- 適合性の基準を満たす、対象を絞った、時代に左右されないスキルの編集のみを適用します。
- すべての編集内容をセルフチェックします。
skills-update/YYYY-MM-DDを作成し、コミット、プッシュして、プルリクエストを作成します。
変更履歴に関係しないスキルは変更しないでください。
手順 1:変更履歴を取得する
自動化のトリガーまたはユーザーメッセージから CHANGELOG_DATE(YYYY-MM-DD)を特定します。
マージ済みの変更履歴ファイルを取得します。
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
ステップ 2:関連性フィルターを適用する
/tmp/changelog-${CHANGELOG_DATE}.md を読み、変更内容を次のスキルと照合します。
| スキル | 更新の対象となる変更 |
|---|---|
text-to-speech | 新規/非推奨モデル、新しい TTS パラメーター、音声設定の変更、出力形式の変更、text_to_speech.convert() の SDK メソッドシグネチャの変更 |
speech-to-text | 新しい文字起こしモデル、新しいパラメーター、レスポンススキーマの変更、SDK メソッドの変更 |
agents | 新しい LLM プロバイダー/モデル、新しいツールタイプ、新しいエージェント設定フィールド、会話設定スキーマの変更、新しい CLI コマンド、ウィジェットの変更、プロシージャのエンドポイント/フィールド/型の変更、構造化されたプロシージャステップの型と検証ルール、下書き保存または公開時のコンパイルと検証の動作、conversational_ai.agents.procedures または conversationalAi.agents.procedures 配下の SDK メソッドの変更 |
sound-effects | 新しい生成パラメーター、モデルの変更、SDK メソッドの変更 |
music | 新しいエンドポイント、新しいパラメーター、モデルの変更 |
voice-isolator | 新しいパラメーター、モデルの変更、audio_isolation.convert() の SDK メソッドの変更 |
realtime | リアルタイムモデル ID、realtime_model エージェント設定、管理対象の設定、地域またはコンプライアンスモード別のリアルタイムの提供状況、Realtime API(/v1/convai/realtime)または client_secrets の変更、conversational_ai.realtime または conversationalAi.realtime の SDK メソッドの変更 |
speech-engine | Speech Engine WebSocket API の変更、会話トークンの変更、リアルタイム音声会話向け SDK メソッドの変更 |
voice-changer | 新しい音声間変換パラメーター、モデルの変更、speech_to_speech.convert() または speechToSpeech.convert() の SDK メソッドの変更 |
setup-api-key | 認証フローの変更、API キーダッシュボードの変更、環境変数に関する案内 |
onboarding | elevenlabs onboard CLI の変更、承認ページまたはサインアップフローの変更、CLI のインストールチャネル、SDK パッケージ名 |
スキルに記載されているモデル一覧、コード例、パラメーターの説明、設定一覧、CLI コマンドに影響する変更は関連性があります。
内部/管理用 API のみに影響する変更、使用方法に影響しない任意フィールドの変更、後方互換性のある名称変更、または API キー設定フローに関係しない料金/ダッシュボード UI の変更は関連性がありません。
影響を受けるスキルがない場合は、正常に処理を終了し、プルリクエストを作成しないでください。CHANGELOG_DATE に関連するスキル変更はありません(No skills-relevant changes for CHANGELOG_DATE)と報告してください。
関連する項目ごとに、影響を受けるスキルと、モデル一覧、コード例、LLM プロバイダー一覧、ツールセクション、CLI セクション、パラメーターの説明、設定一覧などの影響箇所を記録してください。
ステップ 3:現在のスキルファイルを読む
影響を受けるスキルごとに、以下を読みます。
{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、references/using-procedure-api.md、references/writing-procedures.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)realtime/(SKILL.mdとreferences/session-config.md、references/browser-audio.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のみ)onboarding/(SKILL.mdのみ)
ステップ 4:ソースドキュメントを確認する
編集前に、実際のソース資料を取得して読みます。変更履歴には変更点が記載されていますが、現在の動作としてドキュメント化する内容は API/リファレンスドキュメントで確認します。
よくある項目については、以下から確認を始めます。
- エージェント:
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
ドキュメントに記載するフィールド、パラメーター、スキーマ、列挙値、エンドポイント、モデル ID、SDK メソッドごとに、以下を確認します。
- ソースドキュメントで、正確なフィールド名、型、ネスト構造、許可される値、メソッドシグネチャを確認します。
- 変更履歴の記述からスキーマを推測してはいけません。
- 機能が変更履歴に記載されていても、ソースドキュメントにスキーマの詳細が十分にない場合は、その機能のフィールド表やコード例を記載しないでください。レポートの
Needs Manual Authoringに記載します。
ステップ 5:各項目を含めるか判断する
変更履歴の各項目を編集する前に、以下の適合性チェックを実施します。
- 既存のセクション、表、リスト、例の中から自然に追加できる場所を見つけます。
- 主要な機能、一般的なワークフロー、または重要なトップレベルの設定項目のみを含めます。
- 二次的な詳細、つまりエッジケース、優先順位ルール、永続化の詳細、フォールバック順序、実装の詳細、限定的な例外、非推奨に関する注記は省きます。
- 無理に構成を追加するより、何も変更しないことを優先します。自然に追加できる場所がなければ、スキルファイルは変更せず、
No Skill Change Neededに記載します。 - 新しいセクションを追加するのは、その概念が実質的で、再利用可能で、ユーザー向けかつ高レベルであり、現在の構成に明らかに不足している場合に限ります。
- 現行の方法を優先します。フィールド、エンドポイント、モデル、パッケージ、パターンが別のものに置き換わる場合は、現在サポートされている方法を記載し、非推奨になった情報はレポートに残します。
適切な例:
- 既存のモデル表に、新たにサポートされたモデルの行を追加する。
- 既存のパラメーター表に、新しいトップレベルパラメーターを追加する。
- メソッドシグネチャが変更された場合、既存の Python、JavaScript、CLI の例を更新する。
不適切な例:
- 変更履歴の項目に触れるためだけに、関連のないセクションの間に単独の文を挿入する。
- スキルに明示的な移行/トラブルシューティングのセクションが既にあり、そこでの変更が必要な場合を除き、非推奨フィールド、削除された列挙値、古いパッケージ名、移行に関する警告を記載する。
- 内部的な優先順位、ローカルでの永続化動作、フォールバックの連鎖、まれな例外動作を記載する。
ステップ 6:対象を絞って編集する
適切なファイルとセクションに、必要最小限の有用な変更を加えます。既存の見出しレベル、表の形式、コードブロックの言語、インデント、命名スタイルに合わせてください。
更新パターン:
- モデル表: 該当する
SKILL.mdのモデル表で行を追加、削除、または変更します。モデル ID と説明を確認してください。 - コード例: メソッドのシグネチャ、インポート、重要なパラメーターを更新します。Python、JavaScript、CLI の例がすべてある場合は、内容に一貫性を持たせてください。
- 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の出力形式の表を更新します。
厳守事項:
- フィールド名、型、スキーマ、モデル ID、設定名、エンドポイントのパス、例の値を決して捏造しないでください。
- 正確な API の形式を確認せずに、新機能のコード例を書かないでください。
- 変更履歴は調査の手がかりとして扱い、スキルファイルの文章には使用しないでください。
- スキルファイルは長期にわたって有効な内容にしてください。
SKILL.mdまたはreferences/*.md内では、変更履歴、issue、PR、リリース日、「追加された」、「導入された」、「現在はサポートしている」などに触れないでください。 - 過去の経緯を否定するのではなく、現在有効な使い方を記載してください。
- 変更履歴の項目があるという理由だけで、新しいセクションを作成しないでください。
- 孤立した内容を追加しないでください。
- 表には現在サポートされているフィールドのみを記載してください。
- SDK のバージョンを上げてもメソッドのシグネチャに変更がない場合、バージョンに関するコメントが既にあるときに限り、そのコメントを更新してください。
ステップ 7:コミット前のセルフチェック
変更内容をすべて確認し、次の点を検証してください。
- 編集した各フィールド名が、ステップ 4 で読んだソースドキュメントに記載されている。
- 各コード例で、確認済みのパラメーター名とネスト構造を使用している。
- 変更履歴の記述だけから内容を推測していない。
- 捏造した値が残っていない。
- 編集したスキルファイルが、変更履歴、issue、PR、リリース日、またはリリース履歴に関する表現に言及していない。
- 追加した見出しやセクションがすべてステップ 5 によって正当化されている。
- 孤立した文や、無理に追加した単発のセクションが残っていない。
- 編集した内容が、非推奨、削除済み、または置き換えられたフィールドについて、否定的な注意事項のみを記載していない。
- 該当する変更履歴の項目がすべて、次のいずれかとして扱われている:ドキュメントの更新、正当な新規セクション、
No Skill Change Needed、またはNeeds Manual Authoring。
このチェックに通らない変更があれば、その編集を元に戻し、該当項目を Needs Manual Authoring または No Skill Change Needed に移してください。
ステップ 8:ブランチの作成、コミット、プルリクエスト
ブランチ名には skills-update/YYYY-MM-DD を使用します。
ブランチを作成する前に、既存のオープンな PR がないか確認し、あれば中止してください。
gh pr list --repo elevenlabs/skills --head "skills-update/${CHANGELOG_DATE}" --state open --json number --jq 'length == 0'
現在の origin/main からブランチを作成し、ファイルに変更がある場合に限りコミットして、プッシュします。
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 を作成します。
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 Change Needed に記載し、No skill file changes needed for CHANGELOG_DATE と報告してください。
レポートと PR 本文の要件
このレポートを作成し、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)
リポジトリへの書き込み権限がある自動化/ヘッドレスエージェント環境で実行する場合、スキルファイルに変更がない場合を除き、プルリクエストを作成する必要があります。呼び出し元のユーザーが追加のコメントを明示的に求めていない限り、最終応答には完成した Markdown レポートのみを返してください。
重要
- 変更履歴で明示的に求められていない限り、スキルファイルの YAML フロントマターは変更しないでください。
- 変更履歴の日付とリリース履歴の文言は、レポート/PR の文脈でのみ使用してください。
- 変更履歴の項目に自然な配置場所がない場合は、無理に構成を変更せず、何もしないことを優先してください。
- 誤ったコード例を載せるより、載せないほうが適切です。
- 変更履歴の情報が機能名と概要のみで、参照できるドキュメントやスキーマの詳細がない場合は、それらの項目を
Needs Manual Authoringの下に記載してください。