The whole file
This is exactly what you download: no summaries, nothing trimmed.
Heads-up: the skill file itself is written in Spanish. Agents read it fine and answer in your language, but the prose below is not translated.
Consultar la documentación de Microsoft
Los SDKs de Azure y .NET son el terreno donde un modelo de lenguaje se equivoca con más aplomo: los nombres son predecibles, las versiones se solapan y cada renombrado deja años de ejemplos antiguos indexados. El resultado es un método que suena perfecto, que compila en tu cabeza y que no existe.
La regla es sencilla: cuando el coste de equivocarse es una hora de depurar, consultar cuesta diez segundos.
Cuándo consultar, sin excusa
- Usas una API por primera vez
- El método suena demasiado conveniente:
UploadFilecuando lo real esUpload - Se mezclan versiones del SDK:
CloudBlobClient(v11) conBlobServiceClient(v12) - El nombre del paquete no sigue la convención (
Azure.*en .NET,azure-*en Python) - Un error no cuadra con lo que esperabas del código
Preguntas que devuelven algo
Lo específico funciona; lo genérico devuelve la página de portada.
# Mal
"Azure Functions"
# Bien
"Azure Functions Python v2 programming model"
"Cosmos DB partition key design best practices"
"BlobClient UploadAsync Azure.Storage.Blobs"
Añade siempre lo que acota: la versión (.NET 8, EF Core 8), la
intención (quickstart, limits, overview) y el espacio de nombres
cuando busques una API concreta. El namespace es lo que separa una respuesta útil
de tres páginas de desambiguación.
Buscar, leer entera o buscar ejemplo
Tres movimientos distintos para tres necesidades distintas:
| Necesitas | Qué haces |
|---|---|
| Saber si existe y cómo se llama | Buscar en la documentación |
| Todos los pasos o todas las opciones | Traer la página completa |
| Ver cómo se usa de verdad | Buscar un ejemplo de código oficial |
Trae la página completa cuando sea un tutorial (necesitas todos los pasos), una guía de configuración (necesitas todas las opciones) o cuando el extracto de búsqueda se corte justo donde importaba.
Errores y qué preguntar
| Síntoma | Consulta |
|---|---|
| El método no existe | "<Clase> methods <Namespace>" |
| El tipo no se encuentra | "<Tipo> NuGet package namespace" |
| La firma no encaja | "<Clase> <Método> overloads" y traer la página entera |
| Aviso de obsoleto | "<TipoViejo> migration v12" |
| Falla la autenticación | "DefaultAzureCredential troubleshooting" |
| 403 Forbidden | "<Servicio> RBAC permissions" |
Para un error, comparar tu código con un ejemplo oficial suele ser más rápido que leer la referencia: la diferencia salta a la vista y casi siempre está en la inicialización, no en la llamada que falla.
Antes de dar por bueno el código
- Confirmar que el método o el paquete existe
- Si tiene sobrecargas o parámetros complejos, leer la página completa
- Buscar un ejemplo que funcione para el caso concreto
Para una consulta simple basta el primero. Para una API que no habías tocado, los tres.
Por qué no fiarse de la memoria
Tres razones concretas, no una postura:
- Está viva. La documentación refleja el SDK de hoy; el conocimiento de un modelo, el de su fecha de corte.
- Está completa. Un tutorial trae todos los pasos, incluida la línea de configuración que nadie recuerda.
- Es la fuente. Cuando la documentación y un ejemplo de Stack Overflow de 2019 se contradicen, no hay debate.
El coste real de no consultar no es el método inventado —ese lo caza el compilador—, sino el patrón obsoleto que compila, funciona en desarrollo y falla el día que alguien retira la versión antigua.