update-provider-models

Visión general de la skill update-provider-models

Qué hace update-provider-models

La skill update-provider-models es un flujo de mantenimiento centrado en añadir nuevos IDs de modelo o eliminar los obsoletos dentro del código de Vercel AI SDK. Está pensada para tareas de edición de código en las que una instrucción genérica como “actualiza los modelos” resulta demasiado arriesgada, porque los IDs de modelo suelen aparecer en varios paquetes, listas tipadas, tests y ejemplos.

Quién debería usar esta skill

La skill update-provider-models encaja especialmente bien para colaboradores que trabajan en el soporte de providers en vercel/ai, maintainers que gestionan cambios de modelos de providers a partir de issues, y agentes a los que se les pide editar listas de modelos sin pasar por alto ubicaciones secundarias que también necesitan actualizarse.

El trabajo real que resuelve

Normalmente, los usuarios necesitan bastante más que reemplazar una cadena. La tarea real consiste en identificar todas las referencias exactas de un modelo, actualizar el paquete correcto del provider y las superficies compartidas, mantener el orden de clasificación, evitar errores por subcadenas y completar limpiamente el cambio de un modelo antes de pasar al siguiente.

Por qué es mejor que un prompt de edición genérico

El principal valor de update-provider-models for Code Editing es que reduce las suposiciones. La skill aporta un flujo con restricciones explícitas, como buscar solo coincidencias exactas, procesar de forma secuencial las solicitudes con varios modelos y seguir reglas de naming para los ejemplos. Eso importa porque aquí los errores suelen ser sutiles: tocar la superficie equivocada del provider, romper el orden alfabético o editar por accidente modelos con nombres parecidos.

Casos de uso ideales y casos en los que no encaja

Úsala cuando:

• necesites añadir un nuevo ID de modelo a un provider existente
• necesites eliminar un ID de modelo obsoleto
• estés procesando una issue de provider con varias altas o bajas de modelos

No esperes que diseñe una integración de provider nueva desde cero. Esta skill está pensada para actualizar inventarios de modelos de providers ya existentes, no para construir una arquitectura de adapter nueva.

Cómo usar la skill update-provider-models

Cómo instalar update-provider-models

Un comando práctico de update-provider-models install es:

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

Si tu entorno ya expone las skills instaladas, después puedes invocarla indicando el nombre de la skill y pasando el provider concreto junto con la solicitud de cambio de modelos.

Qué entradas necesita la skill

La skill funciona mejor cuando le proporcionas:

• el nombre del provider
• si cada modelo se va a añadir o eliminar
• los IDs exactos de los modelos
• la fuente de verdad, como una issue, un changelog o la documentación del provider
• si se trata de un cambio único o de un lote

Entrada débil:

• “Update OpenAI models”

Entrada sólida:

• “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.”

Cómo convertir una petición imprecisa en un prompt sólido

Un buen prompt de update-provider-models usage suele incluir alcance, validación y expectativas sobre la salida:

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

Este formato reduce el fallo más habitual: ediciones parciales que actualizan una lista pero dejan sin tocar otro paquete o test.

Qué leer primero en el repositorio

Empieza por:

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

Como la evidencia de este repositorio apunta a una skill de un solo archivo, SKILL.md no es solo una introducción: es la especificación operativa. Lee primero la sección “Critical Rules” y luego los flujos para añadir o eliminar.

Las reglas de flujo más importantes que conviene tener presentes

La skill original pone énfasis en varias reglas que cambian de forma material la calidad del resultado:

• usar coincidencias exactas, porque un ID de modelo puede ser subcadena de otro
• respetar el orden existente en arrays, unions y tablas
• usar nombres de archivo en kebab-case para los ejemplos, reemplazando los puntos por guiones
• gestionar las solicitudes con varios modelos de forma secuencial, completando un flujo entero cada vez
• actualizar tanto el paquete principal del provider como las superficies relacionadas del AI SDK cuando haga falta

Son detalles que un prompt genérico suele pasar por alto.

Cómo manejar solicitudes de alta frente a solicitudes de eliminación

En las altas, trata la tarea como descubrimiento más inserción:

1. identifica el paquete exacto del provider y todas las superficies donde aparece la lista de modelos
2. localiza los puntos de inserción que mantengan el orden
3. actualiza los ejemplos relacionados o los patrones de documentación si la convención del repositorio lo exige

En las eliminaciones, trátala como una limpieza:

1. confirma que el modelo está obsoleto y apunta solo al ID exacto
2. elimina las referencias sin tocar modelos con nombres parecidos
3. comprueba si ejemplos, tests o unions tipadas todavía lo mencionan

Cómo procesar un lote con seguridad

La skill update-provider-models prefiere explícitamente el procesamiento secuencial. Si una issue incluye muchos cambios de modelos, completa el flujo entero de un modelo antes de empezar con el siguiente. Así evitas diffs mezclados y te resulta más fácil detectar un archivo omitido mientras el contexto de búsqueda sigue siendo acotado.

Estrategia práctica de búsqueda para evitar ediciones erróneas

Al usar update-provider-models, no te fíes solo de una búsqueda ingenua por subcadenas. Busca cadenas exactas y luego inspecciona cada coincidencia para verificar que se refiere al mismo modelo y al mismo contexto de provider. Esto es clave con nombres como grok-3 frente a grok-3-mini, donde un replace rápido puede corromper entradas vecinas que sí eran válidas.

Qué aspecto tiene una buena salida

Un buen resultado de la update-provider-models guide debería incluir:

• todos los archivos relevantes actualizados, no solo una lista obvia
• el orden correcto dentro de cada estructura editada
• ningún cambio accidental en IDs de modelo parecidos
• un resumen claro de las altas o bajas por archivo
• comprobaciones de confianza o notas allí donde haya quedado alguna ambigüedad

Cuándo esta skill ahorra más tiempo

Esta skill aporta más valor cuando:

• el mismo ID de modelo aparece en varias superficies tipadas
• estás editando con presión de tiempo a partir de una issue de actualización de provider
• delegas la tarea en un agente que necesita límites y reglas explícitas
• el provider tiene muchas variantes de modelo con nombres muy similares

Preguntas frecuentes sobre la skill update-provider-models

¿update-provider-models sirve solo para vercel/ai?

Está escrita para la estructura y las convenciones del repositorio vercel/ai. Puedes adaptar el flujo a otros entornos, pero el caso de uso de mayor confianza es actualizar IDs de modelo dentro de ese código.

¿Es mejor que pedirle a un agente que haga “search and replace”?

Sí, si la corrección importa. La skill update-provider-models está diseñada alrededor de riesgos específicos del repositorio: verificación de coincidencias exactas, orden de listas, actualizaciones en varias superficies y procesamiento secuencial. Un prompt genérico puede editar más rápido, pero también tiene más probabilidades de dejar archivos dependientes sin actualizar o de dañar entradas con nombres parecidos.

¿update-provider-models es apta para principiantes?

Sí, siempre que ya sepas moverte por un repositorio y revisar diffs. El flujo es acotado y concreto. Aun así, quienes empiezan deben verificar bien el alcance del provider e inspeccionar con cuidado los resultados de búsqueda, sobre todo cuando hay nombres de modelos casi duplicados.

¿Puedo usarla para un provider completamente nuevo?

Por lo general, no. No es la herramienta adecuada para crear desde cero un paquete de provider. Está pensada para actualizar IDs de modelo dentro de una integración de provider ya existente.

¿Qué pasa si solo tengo una issue del provider y no una lista exacta de archivos?

Ese caso encaja perfectamente. La skill asume que descubrirás las ubicaciones afectadas mediante búsqueda. Solo asegúrate de proporcionar los IDs exactos de los modelos y si cada uno se añade o se elimina.

¿Cuándo no debería usar update-provider-models?

Sáltatela cuando la solicitud en realidad trate de:

• diseñar la arquitectura del provider
• cambiar capacidades del modelo o lógica de comportamiento no relacionada con IDs
• reescrituras amplias de documentación sin cambios de código
• actualizaciones especulativas en las que los nombres de modelo aún no estén confirmados

Cómo mejorar la skill update-provider-models

Proporciona IDs de modelo exactos y una fuente de verdad

La forma más rápida de mejorar los resultados de update-provider-models es dar cadenas de modelo exactas junto con el anuncio del provider, la página de documentación o el enlace a la issue de donde salen. Eso permite al agente distinguir entre IDs confirmados y simples suposiciones.

Indica explícitamente el paquete del provider

Si ya sabes qué provider está afectado, dilo. “Add model-x” es más débil que “Add model-x to the Anthropic provider surfaces in vercel/ai.” Esto reduce falsos positivos y búsquedas innecesarias.

Pide un resumen de cambios por archivo

Una de las mejores formas de elevar la calidad de salida es pedir una breve justificación por cada archivo modificado. Eso facilita la revisión y deja al descubierto con rapidez el trabajo incompleto, especialmente cuando falta una superficie que se esperaba ver actualizada.

Fuerza la validación por coincidencia exacta en el prompt

Incluye una instrucción como:

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

Esto ataca de forma directa el mayor riesgo de corrección dentro del repositorio.

Exige comprobaciones de orden después de editar

Como la skill depende de preservar las convenciones de orden existentes, pide de forma explícita que el agente vuelva a comprobar el orden de las listas tras cada inserción o eliminación. Así detectas defectos poco visibles que a menudo se cuelan en la revisión de diffs.

Gestiona las actualizaciones de varios modelos de una en una

Para issues por lotes, indica al agente que termine por completo un modelo antes de pasar al siguiente. Esto mantiene preciso el contexto de búsqueda y simplifica mucho tanto la reversión como la revisión.

Pide verificación de superficies omitidas

Una instrucción de seguimiento especialmente útil es:

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

Esa pasada final mejora de forma tangible la confianza en el resultado.

Errores habituales que conviene vigilar

Los problemas típicos en update-provider-models usage son:

• editar por error coincidencias de subcadenas
• añadir un modelo en una lista pero no en todas las superficies necesarias
• romper el orden alfabético o el orden específico del repositorio
• nombrar mal archivos de ejemplo cuando hay puntos en el nombre
• mezclar varias actualizaciones de modelos en una sola pasada confusa

Cómo iterar después del primer borrador

Si la primera salida parece incompleta, no vuelvas a pedirlo de forma vaga. Pide una segunda pasada específica:

• “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.”

Ese tipo de iteración es mucho más sólido que un simple “revísalo otra vez”.

Una checklist práctica de revisión

Antes de hacer merge, confirma:

• que el provider es el correcto
• que cada cambio de ID de modelo es exacto
• que el orden sigue respetando las convenciones locales
• que los ejemplos o tests siguen las reglas de naming de archivos, si se añadieron
• que no quedan referencias obsoletas después de las eliminaciones

Ese patrón de revisión es la forma más fiable de obtener resultados de alta confianza con update-provider-models for Code Editing.