aspire

Descripción general de aspire skill

Qué te ayuda a hacer aspire skill

La aspire skill está pensada para quienes necesitan crear, ejecutar, depurar, configurar o publicar una aplicación distribuida basada en Aspire sin tener que reconstruir el flujo de trabajo a partir de documentación dispersa. Resulta especialmente útil cuando tu objetivo real no es “aprender Aspire en teoría”, sino “poner en marcha un AppHost, conectar bien los servicios, revisar fallos y preparar artefactos para el despliegue”.

Quién debería usar aspire

Los perfiles para los que mejor encaja son:

• desarrolladores que están evaluando Aspire para la orquestación local de aplicaciones con varios servicios
• equipos que quieren añadir un AppHost alrededor de APIs, contenedores o ejecutables ya existentes
• usuarios que quieren que un asistente de IA les ayude con aspire install, la configuración, la resolución de problemas y la publicación orientada al despliegue
• equipos polyglot que combinan un AppHost de .NET con servicios en Python, Node.js, Go, Java o en contenedores

Qué hace diferente a esta aspire skill

Esta aspire skill es más sólida que un prompt genérico porque dirige al agente a la ruta de referencia correcta según la tarea:

• uso del CLI y detalles de instalación en references/cli-reference.md
• conceptos de AppHost y del runtime en references/architecture.md
• flujos de trabajo del dashboard y observabilidad en references/dashboard.md
• guía de publicación según destino en references/deployment.md
• descubrimiento de integraciones mediante MCP en references/integrations-catalog.md

Esto importa porque Aspire tiene un modelo mental muy concreto: el AppHost define recursos y dependencias, mientras que el runtime y el dashboard te ayudan a operarlos en local.

Punto clave de decisión antes de instalar aspire

Usa Aspire si quieres un único lugar definido en código para orquestar servicios, dependencias, endpoints, logs, trazas y artefactos de publicación para una plataforma objetivo. No lo elijas si esperas un despliegue directo a producción con un solo comando: el repositorio deja claro que Aspire publica manifiestos y artefactos, y luego son tu CI/CD o tu plataforma quienes se encargan del despliegue real.

Cómo usar aspire skill

Contexto de instalación para aspire skill

Una ruta de instalación práctica para aspire skill empieza por añadir la skill y después usar sus referencias como contexto específico para cada tarea:

1. Instala la skill:
   npx skills add github/awesome-copilot --skill aspire
2. Abre skills/aspire/SKILL.md
3. Carga solo el archivo de referencia que corresponda a tu tarea, en lugar de leerlo todo

Orden de lectura recomendado:

• SKILL.md
• references/cli-reference.md
• references/architecture.md
• references/deployment.md
• references/troubleshooting.md

Cómo instalar Aspire

Si tu objetivo es usar Aspire de verdad, la skill te remite al flujo del CLI independiente:

# Linux / macOS
curl -sSL https://aspire.dev/install.sh | bash

# Windows PowerShell
irm https://aspire.dev/install.ps1 | iex

aspire --version

Esto es importante porque el CLI de Aspire es una interfaz principal, no solo una función secundaria de dotnet.

Empieza con el enfoque correcto de la tarea

La aspire skill funciona mejor cuando tu petición incluye una de estas intenciones explícitas:

• crear una nueva aplicación Aspire
• añadir un AppHost a una solución existente
• conectar una dependencia como Redis o PostgreSQL
• ejecutar y depurar una aplicación distribuida en local
• publicar la salida de Aspire para Docker o Kubernetes
• diagnosticar problemas de arranque, salud o descubrimiento de servicios

Una petición débil como “ayúdame con Aspire” obliga a adivinar. Una más precisa como “configura un AppHost para mi API, Redis y un worker en Python, y luego prepara la salida de publicación para Docker” le da al agente la forma suficiente para usar las referencias correctas.

Qué información necesita aspire skill

Para obtener resultados de alta calidad, aporta:

• la estructura actual de tu repositorio
• los lenguajes y runtimes objetivo
• si ya tienes un AppHost
• restricciones del runtime local, como disponibilidad de Docker o Podman
• plataforma de publicación objetivo: Docker, Kubernetes o salida orientada a Azure
• síntomas observados del fallo, si estás resolviendo problemas

Ejemplo de entrada útil:

I have a .NET API, a React frontend, and a Redis dependency. I want Aspire for local orchestration and Docker publish artifacts. I already use Docker Desktop. Show me the AppHost shape, CLI commands, and likely package choices.

Cómo convertir un objetivo difuso en un buen prompt de aspire

Un buen prompt para guiar aspire suele incluir cinco partes:

1. forma actual de la aplicación
2. recursos deseados
3. expectativas de ejecución local
4. objetivo de despliegue
5. formato en el que quieres la respuesta

Ejemplo:

Use the aspire skill to propose an AppHost for:
- .NET API in src/Api
- Node frontend in src/Web
- PostgreSQL for local dev
Need:
- service startup order
- endpoint wiring
- environment variable strategy
- Aspire CLI commands
- publish path for Kubernetes
Return code snippets plus a short explanation of tradeoffs.

Archivos del repositorio que conviene leer primero para un uso real

Si estás evaluando la adopción de aspire skill, estos archivos son los más importantes:

• SKILL.md para alcance y enrutamiento
• references/cli-reference.md para instalación, aspire new, aspire run, aspire publish y comandos sensibles a la versión
• references/deployment.md para el límite clave entre publicar y desplegar
• references/polyglot-apis.md si tus servicios no son todos .NET
• references/mcp-server.md si quieres inspección asistida y búsqueda de documentación mediante el asistente
• references/troubleshooting.md si falla la orquestación local

Esta estructura es práctica: la skill se apoya en referencias, así que la calidad depende de cargar el archivo correcto, no todos a la vez.

Cómo funciona aspire en la práctica

El uso típico de aspire sigue este orden:

1. crear o abrir el AppHost
2. definir recursos y referencias
3. ejecutar en local con aspire run
4. inspeccionar el estado de los recursos, logs, endpoints y trazas en el dashboard
5. iterar sobre la configuración
6. publicar artefactos para tu destino de despliegue

Este flujo de trabajo es mejor que saltar directamente al despliegue, porque Aspire está claramente orientado primero a la orquestación local y la observabilidad.

Cómo usar aspire para Deployment correctamente

En aspire for Deployment, el dato más importante es que aspire publish genera artefactos de despliegue; no los despliega directamente.

Ejemplos tomados de las referencias:

aspire publish -p docker -o ./docker-output
aspire publish -p kubernetes -o ./k8s-output

Consejo para decidir:

• elige Aspire si quieres que los artefactos de despliegue deriven del mismo modelo de AppHost que usas en local
• no lo elijas si esperas una única herramienta que tanto defina la aplicación como gestione por completo el rollout a producción

Cuándo usar la vía de MCP

La aspire skill resulta especialmente útil con MCP cuando quieres que un asistente inspeccione una aplicación en ejecución o recupere documentación de integraciones sin búsquedas manuales.

references/mcp-server.md muestra aspire mcp init, que configura entornos de IA compatibles y puede crear .vscode/mcp.json además de AGENTS.md. Esto es relevante para la adopción porque reduce la distancia entre “el asistente conoce los conceptos de Aspire” y “el asistente puede ver mis recursos, logs y trazas reales”.

Consejos prácticos que mejoran de verdad la salida

• Indica si tu carga es un .NET project, container o executable; Aspire los modela de forma distinta.
• Menciona pronto la disponibilidad del runtime local. Las aplicaciones polyglot pueden necesitar que el runtime del lenguaje objetivo esté instalado aunque el AppHost sea .NET.
• Pide explícitamente el orden de arranque y la conexión de dependencias; ahí es donde se ve el valor del AppHost.
• Si el objetivo final es el despliegue, pide al agente que separe las decisiones de orquestación local de las decisiones del destino de publicación.
• Si un comando falla, incluye el comando completo y el estado observado en el dashboard o en los logs, no solo “no funcionó”.

Preguntas frecuentes sobre aspire skill

¿Es buena aspire skill para principiantes?

Sí, siempre que ya entiendas a nivel básico cómo funcionan las aplicaciones con varios servicios. La aspire skill reduce los mayores puntos de fricción para principiantes: qué comandos del CLI importan, de qué se responsabiliza el AppHost, dónde mirar el comportamiento del dashboard y por qué publicar no es lo mismo que desplegar.

¿Cuál es el alcance de aspire skill?

La aspire skill cubre la orquestación local, los conceptos de AppHost, el descubrimiento de integraciones, la configuración de MCP, los flujos del dashboard, la resolución de problemas y la preparación para despliegue orientada a publicación. No sustituye por completo tu CI/CD específico de plataforma, las operaciones del clúster ni el diseño de seguridad en la nube.

¿En qué mejora aspire skill a un prompt normal?

Un prompt normal puede generar consejos de configuración plausibles pero incorrectos. La aspire skill es mejor cuando necesitas:

• guía de CLI sensible a la versión
• la distinción correcta entre publicar y desplegar
• patrones de hosting polyglot
• rutas de dashboard y resolución de problemas
• descubrimiento de integraciones mediante herramientas MCP

¿Aspire es solo para equipos .NET?

No. Las referencias cubren explícitamente cargas polyglot. El AppHost sigue estando basado en .NET, pero los servicios orquestados pueden ser contenedores o ejecutables en otros lenguajes. Eso hace que Aspire encaje en stacks mixtos, no solo en soluciones .NET puras.

¿Cuándo no debería usar aspire?

Omite Aspire si:

• solo necesitas una aplicación de un único proceso
• tu equipo ya tiene un estándar de orquestación local que encaja bien
• necesitas gestión directa del despliegue a producción en lugar de artefactos generados
• tu entorno no puede soportar los runtimes locales o las herramientas de contenedores necesarias

¿La instalación de aspire requiere Docker?

No siempre, pero muchos flujos de trabajo prácticos con Aspire se benefician del soporte para contenedores. La referencia de arquitectura señala que los contenedores pueden ejecutarse mediante runtimes locales como Docker o Podman, mientras que los ejecutables se ejecutan como procesos nativos. El requisito exacto depende de los recursos que planees orquestar.

Cómo mejorar aspire skill

Dale a aspire skill entradas concretas de arquitectura

La forma más rápida de mejorar los resultados de aspire skill es dejar de pedir ejemplos abstractos y aportar tu topología real:

• nombres de servicios
• puertos o expectativas de endpoints
• grafo de dependencias
• restricciones del runtime local
• plataforma de publicación objetivo

Esto conduce a mejores propuestas de AppHost, una conexión de endpoints más limpia y menos marcadores genéricos.

Pide la salida en bloques desplegables

En lugar de “constrúyeme una configuración de Aspire”, pide:

• código del AppHost
• comandos de paquetes y plantillas
• pasos de ejecución local
• pasos de verificación en el dashboard
• comandos de publicación para la plataforma objetivo

Esa estructura encaja con cómo se usa Aspire en la práctica y hace que la salida sea más fácil de validar.

Usa la carpeta references de forma intencional

Para mejorar la calidad, indica al agente en qué fuente basarse:

• “use references/deployment.md for publish choices”
• “use references/polyglot-apis.md for Node and Python hosting options”
• “use references/troubleshooting.md to diagnose failed startup”

Así evitas respuestas mezcladas que confunden arquitectura, comportamiento del runtime y despliegue.

Fallo habitual: confundir la orquestación local con el despliegue a producción

Uno de los errores de adopción más comunes es asumir que Aspire despliega por sí mismo a producción. Si la primera respuesta se desvía hacia eso, corrígelo de inmediato: pide artefactos de publicación y luego un plan separado de entrega a CI/CD. Así mantendrás la guía de aspire práctica y precisa.

Fallo habitual: omitir dependencias y supuestos de salud

Si los servicios arrancan en el orden incorrecto o falla el descubrimiento, pide al agente que modele explícitamente:

• referencias entre recursos
• comportamiento de espera/salud
• variables de entorno derivadas de dependencias
• necesidades de exposición de endpoints externos

Aquí es donde una petición vaga sobre el uso de aspire suele quedarse corta.

Mejora la resolución de problemas compartiendo evidencia observable

Cuando quieras que aspire skill depure un problema, aporta:

• el comando aspire run usado
• el estado de cada recurso en el dashboard
• logs del recurso que falla
• si el fallo está relacionado con el arranque, la conectividad o la publicación

La evidencia observable importa más que volcar una gran cantidad de código.

Mejora las salidas de aspire para Deployment con restricciones del destino

Para aspire for Deployment, indica qué espera tu plataforma:

• artefactos de Docker Compose
• manifiestos de Kubernetes
• salida compatible con Helm
• límites de configuración por entorno
• expectativas de réplicas o ingress

La referencia de despliegue muestra que la salida de publicación depende del destino, así que tu petición también debería hacerlo.

Itera después de la primera respuesta en lugar de empezar de cero

Un buen prompt de segunda vuelta suele ser:

Revise the Aspire plan using these constraints:
- frontend must stay outside Aspire
- API and worker should run under AppHost
- use PostgreSQL container locally
- produce Kubernetes publish output
- explain what must still be handled by CI/CD

Ese tipo de iteración mejora mucho más el encaje que pedir una guía genérica nueva de aspire.