Winui Dev Workflow

Testbericht

Das Repo geklont und den Skill unter plugins/winui/skills/winui-dev-workflow gefunden; Frontmatter sauber über yaml.safe_load mit genau name + description geparst, und das Kopieren des Ordners in ein temporäres HOME platzierte SKILL.md unter ~/.claude/skills/winui-dev-workflow/SKILL.md. SKILL.md, BuildAndRun.ps1 und analyzer/Microsoft.WindowsAppSDK.Analyzers.targets roh abgerufen — alle HTTP 200; ich habe alle 267 Zeilen von BuildAndRun.ps1 gelesen und jedes der sechs Verhaltensweisen bestätigt, die SKILL.md dafür beansprucht (AppModelUnlock Registry Developer-Mode Check, single-csproj Discovery, PROCESSOR_ARCHITECTURE Plattform-Erkennung, dotnet build mit /restore, bin\<Platform>\<Config>\net*\win-<rid> Ausgabe-Lookup, `winapp run --debug-output`), plus einen `finally`-Block, der das temporäre Directory.Build.props löscht, und einen Schutz, der das Überschreiben eines bereits existierenden verweigert. Kein curl|sh, kein base64, keine Netzwerkaufrufe, keine Geheimnisse, keine festkodierten Maschinenpfade — nur eine 49KB vorgefertigte Analyzer-DLL, deren Quelle im Repo unter src/tools/winui-analyzer liegt. Die AUSGABE-Phase konnte nicht ausgeführt werden: Dieser Mac hat kein pwsh/powershell, kein dotnet, kein winapp (`pwsh -File ./BuildAndRun.ps1 -SkipRun` → „command not found“), und der Developer-Mode Check liest HKLM, so dass kein Build jemals lief; ich schrieb stattdessen zwei Textartefakte (scratchpad/wdw_baseline.md vs wdw_skill.md) für eine Diagnose von leerem Fenster + 0x8000FFFF — die Baseline griff auf Visual Studio F5, Add-AppxPackage und try/catch um InitializeComponent zurück und listete vier spekulative Ursachen für leere Fenster auf, während die Skill-Version die gesamte Schleife durch einen asynchronen BuildAndRun.ps1-Aufruf ersetzt, die einzelne Grundursache „x:Bind defaults to OneTime — add Mode=OneWay“ benennt und Fakten hinzufügt, die die Baseline nie produzierte (WINAPP_DBGTOOLS_DIR, um den ersten Absturz-Debugger-Tools-Download zu überspringen, MSB3073 XamlCompiler exit-1 = Microsoft.WindowsAppSDK auf >= 2.1.3 aktualisieren). Dies sind dokumentierte Inhaltsunterschiede, keine verifizierten Laufzeitverhalten, daher bleibt outputMeasured false und das Urteil ist Setup. Trigger-Formulierungen beurteilt: SOLLTE laden — „My WinUI 3 app won't build, I'm getting XLS0414 on a custom control“ (ja), „Scaffold a new WinUI 3 desktop app and get it running“ (ja), „The Windows App SDK app launches then instantly closes with 0x8000FFFF“ (ja); SOLLTE NICHT — „Sign my MSIX and submit it to the Microsoft Store“ (nein, das ist der Geschwister-Skill winui-packaging), „My React Native Windows app fails to build on x64“ (nein, nicht WinUI 3). 5/5 korrekt.

Getestet am: 2026-07-21 · Claude Code 2.x (agent harness)