Winui Dev Workflow

Rapport de test

Cloné le dépôt et trouvé la compétence à plugins/winui/skills/winui-dev-workflow ; le frontmatter a été analysé proprement via yaml.safe_load avec exactement nom + description, et la copie du dossier dans un HOME temporaire a placé SKILL.md à ~/.claude/skills/winui-dev-workflow/SKILL.md. Récupéré SKILL.md, BuildAndRun.ps1 et analyzer/Microsoft.WindowsAppSDK.Analyzers.targets — tous HTTP 200 ; j'ai lu les 267 lignes de BuildAndRun.ps1 et confirmé chacun des six comportements que SKILL.md lui attribue (vérification du mode développeur du registre AppModelUnlock, découverte de single-csproj, détection de plateforme PROCESSOR_ARCHITECTURE, dotnet build avec /restore, recherche de sortie bin\<Platform>\<Config>\net*\win-<rid>, `winapp run --debug-output`), plus un bloc `finally` qui supprime le fichier temporaire Directory.Build.props et une protection qui refuse d'écraser un fichier préexistant. Aucun curl|sh, aucun base64, aucun appel réseau, aucun secret, aucun chemin de machine codé en dur — seulement une DLL d'analyseur pré-construite de 49 Ko dont la source se trouve dans le dépôt à src/tools/winui-analyzer. L'étape de SORTIE n'a pas pu être exécutée : ce Mac n'a pas de pwsh/powershell, pas de dotnet, pas de winapp (`pwsh -File ./BuildAndRun.ps1 -SkipRun` → « command not found »), et la vérification du mode développeur lit HKLM, donc aucune construction n'a jamais été exécutée ; j'ai plutôt écrit deux artefacts texte (scratchpad/wdw_baseline.md vs wdw_skill.md) pour un diagnostic de fenêtre vide + 0x8000FFFF — la base de référence a utilisé Visual Studio F5, Add-AppxPackage et try/catch autour de InitializeComponent et a listé quatre causes spéculatives de fenêtre vide, tandis que la version de la compétence remplace toute la boucle par un seul appel asynchrone BuildAndRun.ps1, nomme la cause racine unique « x:Bind defaults to OneTime — add Mode=OneWay », et ajoute des faits que la base de référence n'a jamais produits (WINAPP_DBGTOOLS_DIR pour ignorer le téléchargement des outils de débogage lors du premier plantage, MSB3073 XamlCompiler exit-1 = mettre à jour Microsoft.WindowsAppSDK vers >= 2.1.3). Ce sont des différences de contenu documenté, pas un comportement d'exécution vérifié, donc outputMeasured reste faux et le verdict est setup. Phrases de déclenchement jugées : DEVRAIT charger — « My WinUI 3 app won't build, I'm getting XLS0414 on a custom control » (oui), « Scaffold a new WinUI 3 desktop app and get it running » (oui), « The Windows App SDK app launches then instantly closes with 0x8000FFFF » (oui) ; NE DEVRAIT PAS — « Sign my MSIX and submit it to the Microsoft Store » (non, c'est la compétence sœur winui-packaging), « My React Native Windows app fails to build on x64 » (non, pas WinUI 3). 5/5 correct.

Testé le: 2026-07-21 · Claude Code 2.x (agent harness)