update-provider-models

Vue d’ensemble de la compétence update-provider-models

Ce que fait update-provider-models

La compétence update-provider-models est un workflow de maintenance ciblé pour ajouter de nouveaux IDs de modèles ou supprimer ceux qui sont obsolètes dans le codebase du Vercel AI SDK. Elle est conçue pour les tâches d’édition de code où une simple consigne du type « mets à jour les modèles » est trop risquée, car les IDs de modèles apparaissent souvent dans plusieurs packages, listes typées, tests et exemples.

À qui s’adresse cette compétence

Cette update-provider-models skill convient surtout aux contributeurs qui travaillent sur le support des providers dans vercel/ai, aux maintainers qui traitent des changements de modèles signalés dans des issues, et aux agents chargés de modifier des listes de modèles sans oublier des emplacements secondaires à mettre à jour.

Le véritable besoin à couvrir

En pratique, les utilisateurs ont presque toujours besoin de plus qu’un simple remplacement de chaîne. Le vrai travail consiste à repérer toutes les références exactes d’un modèle, mettre à jour le bon package provider et les surfaces partagées, préserver l’ordre de tri, éviter les erreurs de sous-chaîne, puis finaliser proprement une modification de modèle avant de passer à la suivante.

Pourquoi c’est préférable à une consigne d’édition générique

La valeur principale de update-provider-models for Code Editing, c’est de réduire les suppositions. La compétence fournit un workflow avec des contraintes explicites, comme la recherche en correspondance exacte, le traitement séquentiel des demandes portant sur plusieurs modèles, et des règles de nommage pour les exemples. C’est important, car les erreurs ici sont souvent discrètes : mauvaise surface provider, ordre alphabétique cassé, ou modifications accidentelles de modèles au nom proche.

Cas d’usage idéaux et cas à éviter

Utilisez-la quand il faut :

• ajouter un nouvel ID de modèle à un provider existant
• supprimer un ID de modèle obsolète
• traiter une issue provider avec plusieurs ajouts/suppressions de modèles

N’attendez pas d’elle qu’elle conçoive une nouvelle intégration provider à partir de zéro. Cette compétence sert à mettre à jour des inventaires de modèles existants, pas à construire une nouvelle architecture d’adaptateur.

Comment utiliser la compétence update-provider-models

Comment installer update-provider-models

Une commande pratique pour update-provider-models install est :

npx skills add vercel/ai --skill update-provider-models

Si votre environnement expose déjà les compétences installées, vous pouvez ensuite l’invoquer en citant son nom et en fournissant la demande précise concernant le provider et les changements de modèles.

Quelles entrées fournir à la compétence

La compétence fonctionne au mieux si vous fournissez :

• le nom du provider
• pour chaque modèle, s’il faut l’ajouter ou le supprimer
• les IDs de modèles exacts
• la source de vérité, comme une issue, un changelog ou la documentation du provider
• s’il s’agit d’un changement isolé ou d’un lot

Entrée faible :

• « Update OpenAI models »

Entrée solide :

• « Use update-provider-models to add gpt-4.1-mini to the existing provider model lists and examples in vercel/ai. Check all exact matches only, preserve existing ordering, and show me every file changed. »

Transformer une demande vague en prompt solide

Un bon prompt update-provider-models usage inclut en général le périmètre, la validation et les attentes de sortie :

Use update-provider-models for Code Editing in vercel/ai.

Provider: [provider name]
Changes:
- add [exact-model-id]
- remove [exact-model-id]

Requirements:
- search for exact matches only
- update all relevant provider and shared locations
- preserve current sort/order conventions
- if examples are needed, use kebab-case filenames
- process one model completely before starting the next
- summarize why each file changed

Ce format réduit le mode d’échec le plus courant : des modifications partielles qui mettent à jour une liste mais oublient un autre package ou un test.

Quels fichiers lire d’abord dans le dépôt

Commencez par :

• skills/update-provider-models/SKILL.md

Comme les éléments disponibles dans ce dépôt indiquent une compétence définie dans un seul fichier, SKILL.md n’est pas seulement une vue d’ensemble : c’est la spécification de fonctionnement. Lisez d’abord la section « Critical Rules », puis les workflows d’ajout et de suppression.

Les règles de workflow les plus importantes à garder en tête

La compétence source insiste sur quelques règles qui changent concrètement la qualité du résultat :

• utiliser des correspondances exactes, car certains IDs de modèles sont des sous-chaînes d’autres IDs
• respecter l’ordre de tri existant dans les tableaux, unions et tables
• utiliser des noms de fichiers en kebab-case pour les exemples, en remplaçant les points par des tirets
• traiter les demandes portant sur plusieurs modèles de manière séquentielle, avec un workflow complet à la fois
• mettre à jour à la fois le package provider principal et les surfaces liées du AI SDK quand c’est nécessaire

C’est précisément le type de détail qu’un prompt générique laisse souvent de côté.

Comment traiter les demandes d’ajout ou de suppression

Pour les ajouts, considérez la tâche comme un travail de découverte puis d’insertion :

1. identifier le package provider exact et toutes les surfaces qui listent les modèles
2. trouver les points d’insertion qui préservent l’ordre
3. mettre à jour les exemples liés ou les motifs de documentation si les conventions du dépôt l’exigent

Pour les suppressions, abordez la tâche comme un nettoyage :

1. confirmer que le modèle est bien obsolète et cibler uniquement l’ID exact
2. supprimer les références sans toucher aux modèles au nom proche
3. vérifier si des exemples, tests ou unions typées le mentionnent encore

Comment traiter un lot en toute sécurité

La compétence privilégie explicitement un traitement séquentiel. Si une issue contient de nombreux changements de modèles, terminez tout le workflow pour un modèle avant de passer au suivant. Cela évite les diffs mélangés et facilite la détection d’un fichier oublié tant que le contexte de recherche reste étroit.

Une stratégie de recherche concrète pour éviter les mauvaises modifications

Quand vous utilisez update-provider-models, ne vous reposez pas uniquement sur une recherche naïve par sous-chaîne. Recherchez les chaînes exactes, puis inspectez chaque occurrence pour vérifier qu’elle correspond bien au même modèle et au bon contexte provider. C’est essentiel pour des noms comme grok-3 face à grok-3-mini, où un remplacement trop rapide peut corrompre des entrées voisines pourtant valides.

À quoi ressemble un bon résultat

Un résultat solide avec le update-provider-models guide doit inclure :

• tous les fichiers pertinents mis à jour, pas seulement une liste évidente
• un ordre correct dans chaque structure modifiée
• aucune modification accidentelle d’IDs de modèles proches
• un résumé clair des ajouts/suppressions, fichier par fichier
• des vérifications de confiance ou des notes lorsqu’une ambiguïté subsiste

Quand cette compétence fait gagner le plus de temps

Cette compétence est particulièrement utile quand :

• le même ID de modèle apparaît sur plusieurs surfaces typées
• vous éditez dans l’urgence à partir d’une issue de mise à jour provider
• vous déléguez la tâche à un agent qui a besoin de garde-fous explicites
• le provider comporte de nombreuses variantes de modèles aux noms proches

FAQ sur la compétence update-provider-models

update-provider-models est-il uniquement fait pour vercel/ai ?

Elle a été écrite pour la structure et les conventions du dépôt vercel/ai. Vous pouvez adapter le workflow ailleurs, mais le cas d’usage le plus fiable reste la mise à jour d’IDs de modèles dans ce codebase.

Est-ce préférable à demander à un agent de simplement « search and replace » ?

Oui, si l’exactitude compte. La update-provider-models skill est conçue autour de risques propres au dépôt : vérification en correspondance exacte, ordre des listes, mises à jour sur plusieurs surfaces et traitement séquentiel. Un prompt générique peut aller plus vite, mais il a davantage de chances d’oublier des fichiers dépendants ou d’endommager des entrées au nom similaire.

update-provider-models est-il accessible aux débutants ?

Oui, à condition de savoir déjà naviguer dans un dépôt et relire des diffs. Le workflow est étroit et concret. Les débutants doivent néanmoins vérifier soigneusement le périmètre du provider et inspecter les résultats de recherche, surtout quand des noms de modèles sont presque identiques.

Puis-je l’utiliser pour un provider entièrement nouveau ?

En général non. Ce n’est pas le bon premier outil pour créer un package provider à partir de zéro. Il est conçu pour mettre à jour des IDs de modèles dans une intégration provider existante.

Que faire si je n’ai qu’une issue provider et aucune liste de fichiers exacte ?

C’est un cas d’usage normal. La compétence part du principe que vous allez découvrir les emplacements concernés via la recherche. Fournissez simplement les IDs de modèles exacts et indiquez pour chacun s’il faut l’ajouter ou le supprimer.

Dans quels cas ne pas utiliser update-provider-models ?

Évitez-la si la demande concerne en réalité :

• la conception de l’architecture provider
• des changements de capacités de modèles ou de logique de comportement sans lien avec les IDs
• une réécriture large de la documentation sans changement de code
• des mises à jour spéculatives où les noms de modèles ne sont pas confirmés

Comment améliorer la compétence update-provider-models

Fournir des IDs de modèles exacts et une source de vérité

Le moyen le plus rapide d’améliorer les résultats de update-provider-models est de fournir les chaînes de modèles exactes ainsi que l’annonce du provider, la page de documentation ou le lien d’issue dont elles proviennent. Cela permet à l’agent de distinguer les IDs confirmés des suppositions.

Indiquer explicitement le package provider

Si vous connaissez déjà le provider concerné, dites-le clairement. « Add model-x » est moins précis que « Add model-x to the Anthropic provider surfaces in vercel/ai ». Cela réduit les faux positifs et les recherches inutiles.

Demander un résumé des changements fichier par fichier

L’un des meilleurs leviers pour améliorer la qualité de sortie consiste à demander une courte justification pour chaque fichier modifié. La relecture devient plus simple, et cela fait rapidement ressortir un travail incomplet, surtout lorsqu’une surface attendue a été oubliée.

Imposer la validation par correspondance exacte dans le prompt

Ajoutez une consigne comme :

• « Verify every search hit is an exact model match, not a substring variant. »

Cela cible directement le principal risque d’exactitude dans ce dépôt.

Exiger une vérification de l’ordre après les modifications

Comme la compétence dépend du respect des conventions de tri existantes, demandez explicitement à l’agent de revérifier l’ordre des listes après une insertion ou une suppression. Cela permet de repérer des défauts peu visibles qui échappent souvent à la revue de diff.

Traiter les mises à jour de plusieurs modèles une par une

Pour les issues par lot, demandez à l’agent de terminer complètement un modèle avant de passer au suivant. Le contexte de recherche reste ainsi précis, et le rollback comme la revue deviennent beaucoup plus simples.

Demander une vérification des surfaces potentiellement oubliées

Une consigne de suivi particulièrement utile est :

• « After edits, do one final search for the exact model ID to confirm no outdated references remain and no unintended references were changed. »

Ce balayage final améliore nettement la confiance dans le résultat.

Modes d’échec fréquents à surveiller

Les problèmes typiques avec update-provider-models usage sont :

• modifier par erreur des correspondances de sous-chaîne
• ajouter un modèle dans une liste, mais pas sur toutes les surfaces requises
• casser l’ordre alphabétique ou l’ordre spécifique au dépôt
• mal nommer les fichiers d’exemple lorsque des points sont présents
• mélanger plusieurs mises à jour de modèles dans un seul passage confus

Comment itérer après le premier jet

Si le premier résultat semble incomplet, ne relancez pas avec une consigne vague. Demandez plutôt un second passage ciblé :

• « Re-run update-provider-models for model-id and verify all exact matches across provider package, shared types, tests, and examples. List any files considered but intentionally unchanged. »

Ce type d’itération est bien plus efficace qu’un simple « double-check this ».

Une checklist de revue pratique

Avant de fusionner, vérifiez que :

• le provider est le bon
• chaque changement d’ID de modèle est exact
• l’ordre respecte toujours les conventions locales
• les exemples ou tests suivent les règles de nommage si vous en avez ajouté
• aucune référence obsolète ne reste après les suppressions

C’est le schéma de revue le plus fiable pour obtenir des résultats de haute confiance avec update-provider-models for Code Editing.