aspire

Überblick über den aspire skill

Wobei der aspire skill hilft

Der aspire skill ist für Nutzer gedacht, die eine auf Aspire basierende verteilte Anwendung erstellen, ausführen, debuggen, konfigurieren oder veröffentlichen möchten, ohne sich den Ablauf mühsam aus verstreuten Dokumentationen zusammensuchen zu müssen. Besonders nützlich ist er, wenn Ihre eigentliche Aufgabe nicht lautet, „Aspire theoretisch zu lernen“, sondern „einen funktionierenden AppHost aufzusetzen, Services korrekt zu verdrahten, Fehler zu analysieren und Artefakte für die Bereitstellung vorzubereiten“.

Für wen aspire geeignet ist

Am besten passt aspire für:

• Entwickler, die Aspire für die lokale Orchestrierung von Multi-Service-Anwendungen evaluieren
• Teams, die einen AppHost um bestehende APIs, Container oder Executables herum ergänzen möchten
• Nutzer, die einen KI-Assistenten für aspire install, Setup, Troubleshooting und publish-orientierte Deployment-Vorbereitung einsetzen wollen
• polyglotte Teams, die einen .NET AppHost mit Python-, Node.js-, Go-, Java- oder containerisierten Services kombinieren

Was diesen aspire skill von anderen unterscheidet

Dieser aspire skill ist stärker als ein generischer Prompt, weil er den Agenten je nach Aufgabe gezielt auf den richtigen Referenzpfad lenkt:

• CLI-Nutzung und Installationsdetails in references/cli-reference.md
• AppHost- und Laufzeitkonzepte in references/architecture.md
• Dashboard- und Observability-Workflows in references/dashboard.md
• Hinweise zum Publish für Zielplattformen in references/deployment.md
• Integrationssuche via MCP in references/integrations-catalog.md

Das ist wichtig, weil Aspire ein klares eigenes Modell hat: Der AppHost definiert Ressourcen und Abhängigkeiten, während Runtime und Dashboard dabei helfen, diese lokal zu betreiben.

Zentrale Entscheidung vor der Installation von aspire

Setzen Sie Aspire ein, wenn Sie einen einzigen, codebasierten Ort möchten, um Services, Abhängigkeiten, Endpunkte, Logs, Traces und Publish-Artefakte für eine Zielplattform zu orchestrieren. Wählen Sie Aspire nicht in der Erwartung, per Ein-Kommando direkt in Produktion zu deployen: Das Repository macht klar, dass Aspire Manifeste und Artefakte erzeugt und anschließend Ihre CI/CD-Pipeline oder Plattform das eigentliche Deployment übernimmt.

So verwenden Sie den aspire skill

Installationskontext für den aspire skill

Ein praxisnaher Installationspfad für den aspire skill beginnt damit, den Skill hinzuzufügen und anschließend seine Referenzen als aufgabenspezifischen Kontext zu nutzen:

1. Installieren Sie den Skill:
   npx skills add github/awesome-copilot --skill aspire
2. Öffnen Sie skills/aspire/SKILL.md
3. Laden Sie nur die Referenzdatei, die zu Ihrer Aufgabe passt, statt alles auf einmal zu lesen

Empfohlene Lesereihenfolge:

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

So installieren Sie Aspire selbst

Wenn Ihr Ziel die tatsächliche Nutzung von Aspire ist, verweist der Skill auf den eigenständigen CLI-Ablauf:

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

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

aspire --version

Das ist wichtig, weil die Aspire CLI eine primäre Schnittstelle ist und nicht nur eine Nebenfunktion von dotnet.

Starten Sie mit der richtigen Aufgabenbeschreibung

Der aspire skill funktioniert am besten, wenn Ihre Anfrage eine dieser klaren Absichten enthält:

• eine neue Aspire-App erstellen
• einen AppHost zu einer bestehenden Solution hinzufügen
• eine Abhängigkeit wie Redis oder PostgreSQL anbinden
• eine lokale verteilte App ausführen und debuggen
• Aspire-Output für Docker oder Kubernetes veröffentlichen
• Probleme beim Start, Health-Checks oder Service Discovery beheben

Eine vage Anfrage wie „hilf mir mit Aspire“ zwingt den Assistenten zum Raten. Eine stärkere Anfrage wie „richte einen AppHost für meine API, Redis und einen Python-Worker ein und bereite anschließend Docker-Publish-Output vor“ gibt genug Struktur vor, damit der Agent die passenden Referenzen verwendet.

Welche Eingaben der aspire skill braucht

Für hochwertige Ergebnisse sollten Sie Folgendes angeben:

• die aktuelle Struktur Ihres Repositories
• Zielsprachen und Laufzeitumgebungen
• ob bereits ein AppHost vorhanden ist
• lokale Laufzeitbeschränkungen wie verfügbare Docker- oder Podman-Unterstützung
• Zielplattform für Publish-Output: Docker, Kubernetes oder Azure-orientierter Output
• beobachtete Fehlersymptome, falls Sie ein Problem debuggen

Nützliches Beispiel für eine Eingabe:

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.

Wie Sie aus einem groben Ziel einen starken aspire Prompt machen

Ein guter aspire-Leitprompt enthält in der Regel fünf Bestandteile:

1. aktuelle Anwendungsstruktur
2. gewünschte Ressourcen
3. Erwartungen an den lokalen Betrieb
4. Deployment-Ziel
5. gewünschtes Ausgabeformat

Beispiel:

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.

Repository-Dateien, die Sie für die reale Nutzung zuerst lesen sollten

Wenn Sie den aspire skill für den produktiven Einsatz evaluieren, sind diese Dateien besonders relevant:

• SKILL.md für Umfang und Routing
• references/cli-reference.md für Installation, aspire new, aspire run, aspire publish und versionsabhängige Kommandos
• references/deployment.md für die zentrale Trennung zwischen Publish und Deploy
• references/polyglot-apis.md, wenn Ihre Services nicht ausschließlich .NET sind
• references/mcp-server.md, wenn Sie assistentengestützte Inspektion und Doku-Lookups nutzen möchten
• references/troubleshooting.md, falls die lokale Orchestrierung fehlschlägt

Diese Struktur ist praxisnah: Der Skill ist referenzgetrieben, daher hängt die Qualität davon ab, die richtige Datei zu laden, nicht alle Dateien gleichzeitig.

Wie aspire in der Praxis genutzt wird

Typische aspire-Nutzung folgt dieser Reihenfolge:

1. den AppHost erstellen oder öffnen
2. Ressourcen und Referenzen definieren
3. lokal mit aspire run starten
4. Ressourcenstatus, Logs, Endpunkte und Traces im Dashboard prüfen
5. Konfiguration iterativ anpassen
6. Artefakte für das Deployment-Ziel veröffentlichen

Dieser Ablauf ist besser, als direkt mit dem Deployment zu beginnen, weil Aspire bewusst zuerst auf lokale Orchestrierung und Observability setzt.

aspire für Deployment richtig nutzen

Bei aspire für Deployment ist der wichtigste Punkt: aspire publish erzeugt Deployment-Artefakte, deployt sie aber nicht direkt.

Beispiele aus den Referenzen:

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

Entscheidungshilfe:

• Wählen Sie Aspire, wenn Ihre Deployment-Artefakte aus demselben AppHost-Modell abgeleitet werden sollen, das Sie lokal verwenden
• Wählen Sie es nicht, wenn Sie ein einzelnes Tool erwarten, das sowohl die App definiert als auch den Produktions-Rollout vollständig steuert

Wann Sie den MCP-Weg nutzen sollten

Der aspire skill ist besonders in Verbindung mit MCP nützlich, wenn ein Assistent eine laufende App inspizieren oder Integrationsdokumentation ohne manuelle Suche abrufen soll.

references/mcp-server.md zeigt aspire mcp init, das unterstützte KI-Umgebungen konfiguriert und .vscode/mcp.json sowie AGENTS.md anlegen kann. Das ist für die Einführung relevant, weil es die Lücke zwischen „der Assistent kennt Aspire-Konzepte“ und „der Assistent kann meine tatsächlichen Ressourcen, Logs und Traces sehen“ deutlich verkleinert.

Praktische Tipps, die die Ausgabe spürbar verbessern

• Geben Sie an, ob Ihre Workload ein .NET project, container oder executable ist; Aspire modelliert diese unterschiedlich.
• Nennen Sie frühzeitig, welche lokalen Laufzeitumgebungen verfügbar sind. Polyglotte Apps benötigen unter Umständen die Runtime der Zielsprache, auch wenn der AppHost auf .NET basiert.
• Fragen Sie explizit nach Startreihenfolge und Verdrahtung von Abhängigkeiten; genau dort zeigt sich der Mehrwert des AppHost.
• Wenn Deployment das eigentliche Ziel ist, bitten Sie den Agenten, Entscheidungen zur lokalen Orchestrierung von Entscheidungen zum Publish-Ziel zu trennen.
• Wenn ein Kommando fehlschlägt, geben Sie das vollständige Kommando und den beobachteten Zustand aus Dashboard oder Logs an, nicht nur „es hat nicht funktioniert“.

aspire skill FAQ

Ist der aspire skill gut für Einsteiger geeignet

Ja, sofern Sie Multi-Service-Anwendungen in ihren Grundzügen bereits verstehen. Der aspire skill reduziert die größten Einstiegshürden: welche CLI-Kommandos relevant sind, wofür der AppHost zuständig ist, wo Sie Verhalten im Dashboard nachvollziehen können und warum Publish nicht dasselbe ist wie Deploy.

Wo die Grenze des aspire skill liegt

Der aspire skill deckt lokale Orchestrierung, AppHost-Konzepte, Integrationssuche, MCP-Setup, Dashboard-Workflows, Troubleshooting und publish-orientierte Deployment-Vorbereitung ab. Er ersetzt jedoch nicht Ihre plattformspezifische CI/CD, den Betrieb von Clustern oder das Design Ihrer Cloud-Sicherheitsarchitektur.

Warum der aspire skill besser ist als ein normaler Prompt

Ein normaler Prompt kann plausibel klingende, aber falsche Setup-Empfehlungen liefern. Der aspire skill ist überlegen, wenn Sie Folgendes brauchen:

• versionssichere CLI-Hinweise
• die korrekte Unterscheidung zwischen Publish und Deploy
• Hosting-Muster für polyglotte Setups
• Dashboard- und Troubleshooting-Pfade
• Integrationssuche über MCP-Tools

Ist aspire nur für .NET-Teams gedacht

Nein. Die Referenzen behandeln ausdrücklich auch polyglotte Workloads. Der AppHost bleibt zwar .NET-basiert, die orchestrierten Services können jedoch Container oder Executables in anderen Sprachen sein. Dadurch eignet sich Aspire auch für gemischte Stacks und nicht nur für reine .NET-Lösungen.

Wann Sie aspire nicht verwenden sollten

Verzichten Sie auf Aspire, wenn:

• Sie nur eine Single-Process-Anwendung benötigen
• Ihr Team bereits einen gut passenden Standard für lokale Orchestrierung hat
• Sie statt generierter Artefakte ein direktes Produktions-Deployment-Management brauchen
• Ihre Umgebung die benötigten lokalen Laufzeiten oder Container-Tools nicht unterstützt

Erfordert die Installation von aspire Docker

Nicht immer, aber viele praxisnahe Aspire-Workflows profitieren von Container-Support. Die Architektur-Referenz weist darauf hin, dass Container über lokale Laufzeitumgebungen wie Docker oder Podman laufen können, während Executables als native Prozesse ausgeführt werden. Was Sie konkret benötigen, hängt von den Ressourcen ab, die Sie orchestrieren möchten.

So verbessern Sie den aspire skill

Geben Sie dem aspire skill konkrete Architektur-Eingaben

Der schnellste Weg zu besseren Ergebnissen mit dem aspire skill ist, nicht nach abstrakten Beispielen zu fragen, sondern Ihre reale Topologie anzugeben:

• Servicenamen
• Ports oder erwartete Endpunkte
• Abhängigkeitsgraph
• lokale Laufzeitbeschränkungen
• Zielplattform für Publish-Output

Das führt zu besseren AppHost-Vorschlägen, saubererem Endpoint-Wiring und weniger generischen Platzhaltern.

Fordern Sie Ausgabe in deploybaren Bausteinen an

Statt „bau mir ein Aspire-Setup“ sollten Sie gezielt nach Folgendem fragen:

• AppHost-Code
• Paket- und Template-Kommandos
• Schritte zum lokalen Start
• Verifikationsschritte im Dashboard
• Publish-Kommandos für die Zielplattform

Diese Struktur entspricht der tatsächlichen Nutzung von Aspire und macht die Ausgabe leichter überprüfbar.

Nutzen Sie den references-Ordner gezielt

Um die Qualität zu verbessern, sagen Sie dem Agenten, auf welche Quelle er sich stützen soll:

• „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“

So vermeiden Sie vermischte Antworten, in denen Architektur, Laufzeitverhalten und Deployment durcheinandergeraten.

Häufiger Fehler: lokale Orchestrierung mit Produktions-Deployment verwechseln

Einer der größten Fehler bei der Einführung ist die Annahme, Aspire selbst deploye in Produktion. Wenn die erste Antwort in diese Richtung abdriftet, korrigieren Sie das sofort: Fragen Sie nach Publish-Artefakten und anschließend nach einem separaten Übergabeplan für CI/CD. So bleibt der aspire guide praxisnah und fachlich korrekt.

Häufiger Fehler: fehlende Annahmen zu Abhängigkeiten und Health-Checks

Wenn Services in der falschen Reihenfolge starten oder bei der Service Discovery scheitern, bitten Sie den Agenten, diese Punkte explizit zu modellieren:

• Referenzen zwischen Ressourcen
• Wait-/Health-Verhalten
• aus Abhängigkeiten abgeleitete Umgebungsvariablen
• Anforderungen an die Freigabe externer Endpunkte

Genau hier bleibt eine zu vage aspire-Anfrage oft hinter den Erwartungen zurück.

Troubleshooting verbessern, indem Sie beobachtbare Hinweise teilen

Wenn der aspire skill ein Problem debuggen soll, geben Sie Folgendes mit:

• verwendetes aspire run-Kommando
• Dashboard-Status jeder Ressource
• Logs der fehlschlagenden Ressource
• ob es sich um ein Startup-, Konnektivitäts- oder Publish-Problem handelt

Beobachtbare Hinweise sind wichtiger als ein großer Code-Dump.

aspire für Deployment-Ausgaben mit Zielvorgaben verbessern

Für aspire für Deployment sollten Sie angeben, was Ihre Plattform erwartet:

• Docker-Compose-Artefakte
• Kubernetes-Manifeste
• Helm-freundlichen Output
• Grenzen zwischen umgebungsspezifischer und allgemeiner Konfiguration
• Erwartungen an Replikate oder Ingress

Die Deployment-Referenz zeigt, dass Publish-Output zielabhängig ist — Ihre Anfrage sollte es ebenfalls sein.

Nach der ersten Antwort iterieren statt neu zu starten

Ein starker Prompt für die zweite Runde sieht meist so aus:

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

Diese Art der Iteration verbessert die Passung deutlich stärker, als erneut nach einem komplett neuen generischen aspire guide zu fragen.