Mit Aspire Skills den Agenten auf die offizielle CLI bringen

Für wen

Passt für Leute, die Aspire-verteilte Apps bauen und wollen, dass der Agent zuerst den Arbeitsbereich erkennt und dann die Aspire CLI richtig nutzt. Das offizielle Repository ist

https://github.com/microsoft/aspire-skills

Es schreibt Aspire Skills als plugin, skill pack und extension pack für diese Arbeit. Der Agent soll übliche Arbeit an eigene Skills routen, statt dotnet, curl, Docker oder shell zu improvisieren. Das Material nennt kein Pflicht-Agentenprodukt; keine Clientliste ergänzen.

Es passt eher zu Erkennung, Orchestrierungsblick und Diagnose, nicht zu sofortigem Veröffentlichen. Im Material Publishes, deploys, and tears down Aspire apps aspire-deployment. Diesen Weg beim ersten Versuch nicht gehen.

Ersten Versuch in 3 Minuten abschließen

Der Hauptweg nutzt die offizielle Aspire CLI; am Prompt wählst du, Agent-Guidance anzubinden. Für einen bestehenden Arbeitsbereich diese Zeile:

aspire agent init

Das Material schreibt auch aspire new (App anlegen und am Prompt Guidance wählen) und aspire init (Aspire-Skelett ins bestehende Repo und am Prompt Guidance wählen). Der erste Versuch bevorzugt aspire agent init, weil das Add, update, or reconfigure Aspire guidance in an existing workspace ist. Voraussetzung: diese Maschine kann die Aspire CLI schon ausführen, und das aktuelle Verzeichnis ist ein Aspire-Arbeitsbereich, den du umschreiben darfst. Das Material schreibt weder CLI-Paketnamen noch Versionsnummer.

Nebenwirkung: Guidance-Konfiguration wird ins Arbeitsverzeichnis geschrieben oder aktualisiert. Vor dem Ausführen das Verzeichnis prüfen. Danach zuerst sehen, ob der Agent recognize Aspire workspaces kann, dann entscheiden, ob Ressourcen gestartet werden. In diesem Schritt nicht deployen und nicht abreissen.

Risikoarme Aufgabe: den Top-Level-aspire-Routing-Skill nur schreibgeschützt prüfen lassen, zum Beispiel ob der Arbeitsbereich erkannt und die CLI richtig aufgerufen wird. Wenn eine laufende App berührt werden muss, nur aspire-monitoring für logs, traces, dashboard, telemetry oder diagnostics; aspire-deployment nicht aufrufen. Erfolgssignal: der Agent wechselt für diese Aspire-Aufgaben nicht mehr zu improvisiertem dotnet / curl / Docker / shell. Fehlt die CLI, bei „diese Maschine hat keine Aspire CLI“ stoppen; den ersten Versuch nicht mit einem anderen Installer beenden.

Anwendungsfälle

Fall 1: Guidance an einen bestehenden Arbeitsbereich anbinden oder aktualisieren. Entspricht aspire agent init und recognize Aspire workspaces. Passt, wenn das Repo schon da ist und der Agent nur auf Aspire-Art arbeiten soll. Das Material schreibt weder Prompttexte noch welche Dateien erzeugt wurden; prüfbar ist, dass ein bestehender Arbeitsbereich guidance aktualisieren kann. Fall 1 nicht als schon in die Cloud deployed schreiben.

Fall 2: Nach der Orchestrierung Monitoring und Diagnose. Entspricht aspire-orchestration (Starts, stops, waits for, and manages Aspire resources) und aspire-monitoring (Routes logs, traces, dashboard, telemetry, and diagnostics work). Passt, wenn Ressourcen schon laufen und nur Logs oder das Dashboard gebraucht werden. Das Material schreibt weder Dashboard-Adresse noch Alarmregeln; Monitoring über diesen Skill, nicht über improvisiertes curl. Start/Stop von Ressourcen hat Nebenwirkungen; zuerst prüfen, ob die Umgebung das erlaubt.

Nutzungsgrenzen

aspire-init Creates a new Aspire project or adds an Aspire skeleton to an existing repo; aspireify Wires an AppHost nach aspire init. Das ändert die Repo-Struktur; nicht als schreibgeschützte Prüfung behandeln. aspire-deployment enthält Teardown und braucht Extra-Bestätigung. Das Material zeigt außerdem npx skills add microsoft/aspire-skills und eine Gruppe /plugin-Befehle; das sind andere Einstiege. Beim ersten Versuch nicht mit der Aspire CLI zu einem Hauptweg mischen und nicht folgern, ein Client besitze das allein.