@fprad0/skill-master-mcp 0.0.12 → 1.0.1

package/docs/skill-candidates/v0.0.10/winui-app/config.yaml

@@ -1,50 +1,50 @@
-# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2
-
-##################################################################################################################################
-# This configuration installs the tools needed to get started building Windows apps with WinUI.                                  #
-#                                                                                                                                #
-# This will:                                                                                                                     #
-#   * Enable Developer Mode                                                                                                      #
-#   * Install Visual Studio Community 2026                                                                                       #
-#   * Install the WinUI / Windows App SDK workloads                                                                              #
-##################################################################################################################################
-properties:
-  assertions:
-    - resource: Microsoft.Windows.Developer/OsVersion
-      directives:
-        description: Verify min OS version requirement
-        allowPrerelease: true
-      settings:
-        MinVersion: '10.0.17763'
-  resources:
-    - resource: Microsoft.Windows.Settings/WindowsSettings
-      directives:
-        description: Enable Developer Mode
-        securityContext: elevated
-        allowPrerelease: true
-      settings:
-        DeveloperMode: true
-    - resource: Microsoft.WinGet.DSC/WinGetPackage
-      id: Visual Studio
-      directives:
-        description: Install Visual Studio Community 2026
-        securityContext: elevated
-      settings:
-        id: Microsoft.VisualStudio.Community
-        source: winget
-    - resource: Microsoft.VisualStudio.DSC/VSComponents
-      id: Workloads ManagedDesktop
-      dependsOn:
-        - Visual Studio
-      directives:
-        description: Install required VS workloads (ManagedDesktop, Windows App SDK)
-        allowPrerelease: true
-        securityContext: elevated
-      settings:
-        productId: Microsoft.VisualStudio.Product.Community
-        channelId: VisualStudio.18.Release
-        components:
-          - Microsoft.VisualStudio.Workload.ManagedDesktop
-          - Microsoft.VisualStudio.Workload.Universal
-          - Microsoft.VisualStudio.ComponentGroup.WindowsAppSDK.Cs
-  configurationVersion: 0.2.0
+# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2
+
+##################################################################################################################################
+# This configuration installs the tools needed to get started building Windows apps with WinUI.                                  #
+#                                                                                                                                #
+# This will:                                                                                                                     #
+#   * Enable Developer Mode                                                                                                      #
+#   * Install Visual Studio Community 2026                                                                                       #
+#   * Install the WinUI / Windows App SDK workloads                                                                              #
+##################################################################################################################################
+properties:
+  assertions:
+    - resource: Microsoft.Windows.Developer/OsVersion
+      directives:
+        description: Verify min OS version requirement
+        allowPrerelease: true
+      settings:
+        MinVersion: '10.0.17763'
+  resources:
+    - resource: Microsoft.Windows.Settings/WindowsSettings
+      directives:
+        description: Enable Developer Mode
+        securityContext: elevated
+        allowPrerelease: true
+      settings:
+        DeveloperMode: true
+    - resource: Microsoft.WinGet.DSC/WinGetPackage
+      id: Visual Studio
+      directives:
+        description: Install Visual Studio Community 2026
+        securityContext: elevated
+      settings:
+        id: Microsoft.VisualStudio.Community
+        source: winget
+    - resource: Microsoft.VisualStudio.DSC/VSComponents
+      id: Workloads ManagedDesktop
+      dependsOn:
+        - Visual Studio
+      directives:
+        description: Install required VS workloads (ManagedDesktop, Windows App SDK)
+        allowPrerelease: true
+        securityContext: elevated
+      settings:
+        productId: Microsoft.VisualStudio.Product.Community
+        channelId: VisualStudio.18.Release
+        components:
+          - Microsoft.VisualStudio.Workload.ManagedDesktop
+          - Microsoft.VisualStudio.Workload.Universal
+          - Microsoft.VisualStudio.ComponentGroup.WindowsAppSDK.Cs
+  configurationVersion: 0.2.0

package/docs/skill-candidates/v0.0.10/winui-app/references/_sections.md

@@ -1,96 +1,96 @@
-# Reference Sections
-
-Use this index to choose the narrowest reference file that fits the current task.
-
-## 1. Foundations
-
-- `foundation-setup-and-project-selection.md`
-  - Priority: CRITICAL
-  - Use for first-project setup, packaged vs unpackaged decisions, and core WinUI prerequisites.
-  - Authority: Microsoft Learn WinUI and Windows App SDK setup docs.
-
-- `foundation-environment-audit-and-remediation.md`
-  - Priority: CRITICAL
-  - Use for machine readiness checks, missing prerequisites, and guided remediation.
-  - Authority: Microsoft Learn setup and system requirements docs, plus the bundled bootstrap workflow.
-
-- `foundation-winui-app-structure.md`
-  - Priority: HIGH
-  - Use for solution layout, shell composition, resources, bindings, and C#-first project structure.
-  - Authority: WinUI Gallery source plus Learn XAML guidance.
-
-- `foundation-template-first-recovery.md`
-  - Priority: CRITICAL
-  - Use for opaque `MSB3073`, `XamlCompiler.exe`, and startup failures that should be recovered by comparing against a fresh `dotnet new winui` scaffold instead of applying alternate baseline files.
-  - Authority: Learn packaged and unpackaged deployment guidance plus recurring template-first recovery patterns.
-
-- `build-run-and-launch-verification.md`
-  - Priority: CRITICAL
-  - Use for build/run workflows, actual launch verification, startup crashes, and packaged-vs-unpackaged local execution choices.
-  - Authority: Learn setup and deployment guidance plus recurring WinUI troubleshooting patterns.
-
-## 2. Shell, Navigation, and Windowing
-
-- `shell-navigation-and-windowing.md`
-  - Priority: HIGH
-  - Use for `NavigationView`, page shells, title bars, `AppWindow`, and multi-window design.
-  - Authority: Learn design guidance, WinUI Gallery samples, Windows App SDK Windowing samples.
-
-## 3. Controls, Layout, and Adaptive UI
-
-- `controls-layout-and-adaptive-ui.md`
-  - Priority: HIGH
-  - Use for control selection, command surfaces, responsive layout, and page composition.
-  - Authority: Learn design guidance and WinUI Gallery control pages.
-
-## 4. Styling, Theming, Materials, and Icons
-
-- `styling-theming-materials-and-icons.md`
-  - Priority: HIGH
-  - Use for Fluent styling, theme resources, Mica, Acrylic, typography, and iconography.
-  - Authority: Learn design/material docs, WinUI Gallery backdrop samples, Windows App SDK Mica samples.
-
-- `motion-animations-and-polish.md`
-  - Priority: MEDIUM
-  - Use for transitions, connected animation, subtle polish, and animation discipline.
-  - Authority: Learn motion guidance, WinUI Gallery transition samples, CommunityToolkit animations.
-
-## 5. Accessibility, Input, and Localization
-
-- `accessibility-input-and-localization.md`
-  - Priority: HIGH
-  - Use for keyboarding, Narrator, high contrast, automation properties, and localization concerns.
-  - Authority: Learn accessibility and globalization guidance, WinUI Gallery automation patterns.
-
-## 6. Performance and Diagnostics
-
-- `performance-diagnostics-and-responsiveness.md`
-  - Priority: HIGH
-  - Use for UI-thread responsiveness, large item collections, rendering cost, and diagnostic tooling.
-  - Authority: Learn WinUI performance docs and XAML frame analysis guidance.
-
-## 7. Windows App SDK Scenarios
-
-- `windows-app-sdk-lifecycle-notifications-and-deployment.md`
-  - Priority: HIGH
-  - Use for lifecycle, activation, notifications, packaged vs unpackaged deployment, and runtime initialization.
-  - Authority: Microsoft Learn Windows App SDK docs and WindowsAppSDK-Samples.
-
-## 8. CommunityToolkit Extensions
-
-- `community-toolkit-controls-and-helpers.md`
-  - Priority: MEDIUM
-  - Use when built-in WinUI controls are not enough and Toolkit packages might close the gap cleanly.
-  - Authority: CommunityToolkit/Windows packages and samples.
-
-## 9. Testing, Debugging, and Review
-
-- `testing-debugging-and-review-checklists.md`
-  - Priority: HIGH
-  - Use for final review passes, debugging workflows, and validation checklists.
-  - Authority: Learn tooling docs plus recurring WinUI review patterns.
-
-- `sample-source-map.md`
-  - Priority: MEDIUM
-  - Use when you need to know which canonical repo or doc to inspect first for a given task.
-  - Authority: Curated map across Learn, WinUI Gallery, WindowsAppSDK-Samples, and CommunityToolkit.
+# Reference Sections
+
+Use this index to choose the narrowest reference file that fits the current task.
+
+## 1. Foundations
+
+- `foundation-setup-and-project-selection.md`
+  - Priority: CRITICAL
+  - Use for first-project setup, packaged vs unpackaged decisions, and core WinUI prerequisites.
+  - Authority: Microsoft Learn WinUI and Windows App SDK setup docs.
+
+- `foundation-environment-audit-and-remediation.md`
+  - Priority: CRITICAL
+  - Use for machine readiness checks, missing prerequisites, and guided remediation.
+  - Authority: Microsoft Learn setup and system requirements docs, plus the bundled bootstrap workflow.
+
+- `foundation-winui-app-structure.md`
+  - Priority: HIGH
+  - Use for solution layout, shell composition, resources, bindings, and C#-first project structure.
+  - Authority: WinUI Gallery source plus Learn XAML guidance.
+
+- `foundation-template-first-recovery.md`
+  - Priority: CRITICAL
+  - Use for opaque `MSB3073`, `XamlCompiler.exe`, and startup failures that should be recovered by comparing against a fresh `dotnet new winui` scaffold instead of applying alternate baseline files.
+  - Authority: Learn packaged and unpackaged deployment guidance plus recurring template-first recovery patterns.
+
+- `build-run-and-launch-verification.md`
+  - Priority: CRITICAL
+  - Use for build/run workflows, actual launch verification, startup crashes, and packaged-vs-unpackaged local execution choices.
+  - Authority: Learn setup and deployment guidance plus recurring WinUI troubleshooting patterns.
+
+## 2. Shell, Navigation, and Windowing
+
+- `shell-navigation-and-windowing.md`
+  - Priority: HIGH
+  - Use for `NavigationView`, page shells, title bars, `AppWindow`, and multi-window design.
+  - Authority: Learn design guidance, WinUI Gallery samples, Windows App SDK Windowing samples.
+
+## 3. Controls, Layout, and Adaptive UI
+
+- `controls-layout-and-adaptive-ui.md`
+  - Priority: HIGH
+  - Use for control selection, command surfaces, responsive layout, and page composition.
+  - Authority: Learn design guidance and WinUI Gallery control pages.
+
+## 4. Styling, Theming, Materials, and Icons
+
+- `styling-theming-materials-and-icons.md`
+  - Priority: HIGH
+  - Use for Fluent styling, theme resources, Mica, Acrylic, typography, and iconography.
+  - Authority: Learn design/material docs, WinUI Gallery backdrop samples, Windows App SDK Mica samples.
+
+- `motion-animations-and-polish.md`
+  - Priority: MEDIUM
+  - Use for transitions, connected animation, subtle polish, and animation discipline.
+  - Authority: Learn motion guidance, WinUI Gallery transition samples, CommunityToolkit animations.
+
+## 5. Accessibility, Input, and Localization
+
+- `accessibility-input-and-localization.md`
+  - Priority: HIGH
+  - Use for keyboarding, Narrator, high contrast, automation properties, and localization concerns.
+  - Authority: Learn accessibility and globalization guidance, WinUI Gallery automation patterns.
+
+## 6. Performance and Diagnostics
+
+- `performance-diagnostics-and-responsiveness.md`
+  - Priority: HIGH
+  - Use for UI-thread responsiveness, large item collections, rendering cost, and diagnostic tooling.
+  - Authority: Learn WinUI performance docs and XAML frame analysis guidance.
+
+## 7. Windows App SDK Scenarios
+
+- `windows-app-sdk-lifecycle-notifications-and-deployment.md`
+  - Priority: HIGH
+  - Use for lifecycle, activation, notifications, packaged vs unpackaged deployment, and runtime initialization.
+  - Authority: Microsoft Learn Windows App SDK docs and WindowsAppSDK-Samples.
+
+## 8. CommunityToolkit Extensions
+
+- `community-toolkit-controls-and-helpers.md`
+  - Priority: MEDIUM
+  - Use when built-in WinUI controls are not enough and Toolkit packages might close the gap cleanly.
+  - Authority: CommunityToolkit/Windows packages and samples.
+
+## 9. Testing, Debugging, and Review
+
+- `testing-debugging-and-review-checklists.md`
+  - Priority: HIGH
+  - Use for final review passes, debugging workflows, and validation checklists.
+  - Authority: Learn tooling docs plus recurring WinUI review patterns.
+
+- `sample-source-map.md`
+  - Priority: MEDIUM
+  - Use when you need to know which canonical repo or doc to inspect first for a given task.
+  - Authority: Curated map across Learn, WinUI Gallery, WindowsAppSDK-Samples, and CommunityToolkit.

package/docs/skill-candidates/v0.0.10/winui-app/references/accessibility-input-and-localization.md

@@ -1,51 +1,51 @@
----
-title: Accessibility, Input, and Localization
-priority: HIGH
-tags: accessibility, keyboard, narrator, automation, localization, high-contrast
-sources:
-  - https://learn.microsoft.com/windows/apps/design/accessibility/accessibility
-  - https://learn.microsoft.com/windows/apps/design/accessibility/keyboard-accessibility
-  - https://learn.microsoft.com/windows/apps/design/accessibility/high-contrast-themes
-  - https://learn.microsoft.com/windows/apps/design/globalizing/globalizing-portal
-  - https://github.com/microsoft/WinUI-Gallery
----
-
-## What This Reference Is For
-
-Use this file for keyboard accessibility, Narrator support, automation properties, input parity, high contrast, and localization-ready UI.
-
-## Prefer
-
-- Accessible names, help text, and landmarks for meaningful UI elements.
-- Full keyboard reachability for the main workflow.
-- High-contrast-safe visuals.
-- Localizable strings and layouts that tolerate growth.
-- Equal support for mouse, touch, pen, and keyboard where the platform expects it.
-
-## Avoid
-
-- Icon-only interactions without accessible naming.
-- Focus traps, hidden tab stops, or keyboard-only dead ends.
-- Hard-coded strings in XAML or code-behind that block localization.
-- Text layouts that collapse when strings expand.
-
-## Guidance
-
-- Use automation properties intentionally.
-- Preserve visible focus and logical tab order.
-- Verify context menus, flyouts, and dialogs by keyboard as well as mouse.
-- Respect text scaling, contrast changes, and RTL where relevant.
-- Keep touch targets and spacing usable on both mouse and touch hardware.
-
-## WinUI Gallery Anchors
-
-- Accessibility-related control samples
-- Automation helper patterns in shell code
-- Standard WinUI controls that already expose useful accessibility behavior
-
-## Review Checklist
-
-- Can a keyboard-only user complete the task?
-- Does Narrator have enough information to describe the important UI?
-- Does the experience stay legible in high contrast?
-- Are strings and layout ready for localization and RTL growth?
+---
+title: Accessibility, Input, and Localization
+priority: HIGH
+tags: accessibility, keyboard, narrator, automation, localization, high-contrast
+sources:
+  - https://learn.microsoft.com/windows/apps/design/accessibility/accessibility
+  - https://learn.microsoft.com/windows/apps/design/accessibility/keyboard-accessibility
+  - https://learn.microsoft.com/windows/apps/design/accessibility/high-contrast-themes
+  - https://learn.microsoft.com/windows/apps/design/globalizing/globalizing-portal
+  - https://github.com/microsoft/WinUI-Gallery
+---
+
+## What This Reference Is For
+
+Use this file for keyboard accessibility, Narrator support, automation properties, input parity, high contrast, and localization-ready UI.
+
+## Prefer
+
+- Accessible names, help text, and landmarks for meaningful UI elements.
+- Full keyboard reachability for the main workflow.
+- High-contrast-safe visuals.
+- Localizable strings and layouts that tolerate growth.
+- Equal support for mouse, touch, pen, and keyboard where the platform expects it.
+
+## Avoid
+
+- Icon-only interactions without accessible naming.
+- Focus traps, hidden tab stops, or keyboard-only dead ends.
+- Hard-coded strings in XAML or code-behind that block localization.
+- Text layouts that collapse when strings expand.
+
+## Guidance
+
+- Use automation properties intentionally.
+- Preserve visible focus and logical tab order.
+- Verify context menus, flyouts, and dialogs by keyboard as well as mouse.
+- Respect text scaling, contrast changes, and RTL where relevant.
+- Keep touch targets and spacing usable on both mouse and touch hardware.
+
+## WinUI Gallery Anchors
+
+- Accessibility-related control samples
+- Automation helper patterns in shell code
+- Standard WinUI controls that already expose useful accessibility behavior
+
+## Review Checklist
+
+- Can a keyboard-only user complete the task?
+- Does Narrator have enough information to describe the important UI?
+- Does the experience stay legible in high contrast?
+- Are strings and layout ready for localization and RTL growth?

package/docs/skill-candidates/v0.0.10/winui-app/references/build-run-and-launch-verification.md

@@ -1,72 +1,72 @@
----
-title: Build, Run, and Launch Verification
-priority: CRITICAL
-tags: build, run, launch, verification, packaged, unpackaged, debugging
-sources:
-  - https://learn.microsoft.com/windows/apps/get-started/start-here
-  - https://learn.microsoft.com/windows/apps/windows-app-sdk/deploy-packaged-apps
-  - https://learn.microsoft.com/windows/apps/windows-app-sdk/deploy-unpackaged-apps
----
-
-## What This Reference Is For
-
-Use this file when the task involves building, running, launch failures, startup crashes, or final verification that a WinUI app actually opens on the current machine.
-
-## Required Workflow
-
-1. Identify the real build target:
-   - solution or project file
-   - configuration
-   - platform
-   - packaged or unpackaged model
-2. Build after each meaningful code edit and again at task completion.
-3. Run the app after changes when feasible. Always do it when the user asked for it or when startup, navigation, resources, or packaging changed.
-4. Use the launch path that matches the deployment model:
-   - packaged local dev: normally Visual Studio deploy or another package-aware flow
-   - unpackaged local dev: normally the built executable the user will actually run
-5. Verify real launch with objective evidence such as:
-   - non-zero main window handle
-   - expected window title
-   - responsive process with visible shell
-   - no immediate startup exception or crash
-6. After completing app work, including a first scaffold or a later build-and-fix cycle, leave a successfully verified final app instance running so the user can see that it worked unless they explicitly asked you not to.
-7. If launch fails or verification is ambiguous, debug the failure before saying the app is ready.
-
-## Packaged vs Unpackaged Rules
-
-- Choose one model intentionally before wiring startup, persistence, and launch instructions.
-- Packaged apps can rely on package identity and package-backed storage.
-- Unpackaged apps must not assume package identity. Guard or replace APIs that require it.
-- APIs such as `Windows.Storage.ApplicationData.Current` can fail in unpackaged runs even when the build succeeds.
-- Do not mix packaged-only assumptions into an unpackaged startup path.
-
-## Build and Launch Guidance
-
-- Prefer explicit platform targets when WinUI output is sensitive to architecture defaults. If `AnyCPU` creates ambiguity, use `x64` for local verification.
-- For unpackaged verification, prefer launching the built `.exe` from `bin\Debug\...\win-x64\` or the project-specific output path.
-- After a successful final launch verification, do not immediately tear the app down just because verification succeeded; keep it open for the user unless it blocks the next required action.
-- If `dotnet run` throws bootstrapper, deployment, or COM activation errors, treat that as a signal that the chosen launch path or packaging setup is wrong for the current app.
-- Stop old app instances before rebuilding if they can lock output files.
-
-## Debugging Startup Failures
-
-- Separate environment problems from app-code startup crashes.
-- If the app exits before showing a window, inspect the startup path first:
-  - `App.xaml`
-  - merged resource dictionaries
-  - converters
-  - `MainWindow`
-  - services used during startup
-- For startup or manifest issues, compare the current app against a fresh `dotnet new winui` scaffold for the same packaging model before broader surgery.
-- For opaque `MSB3073` and `XamlCompiler.exe` failures, simplify back toward the template-generated startup and shared-resource shape before making further structural changes.
-- Restore complex startup pieces incrementally when the failure point is unclear. A minimal `App.xaml` plus minimal `MainWindow` is a valid isolation step.
-- If the diagnostics look stale or inconsistent with the current files, run a clean build once before deeper surgery.
-- Prefer restoring the last known-good template-based shared-resource state over moving styles inline as the long-term fix.
-- When using unpackaged startup, review persistence, notifications, storage, and activation code for hidden package-identity assumptions.
-
-## Exit Criteria
-
-- Build succeeds from the intended local workflow.
-- The app launches from the intended local workflow.
-- A real top-level window or equivalent expected UI is confirmed.
-- No unresolved startup exception remains.
+---
+title: Build, Run, and Launch Verification
+priority: CRITICAL
+tags: build, run, launch, verification, packaged, unpackaged, debugging
+sources:
+  - https://learn.microsoft.com/windows/apps/get-started/start-here
+  - https://learn.microsoft.com/windows/apps/windows-app-sdk/deploy-packaged-apps
+  - https://learn.microsoft.com/windows/apps/windows-app-sdk/deploy-unpackaged-apps
+---
+
+## What This Reference Is For
+
+Use this file when the task involves building, running, launch failures, startup crashes, or final verification that a WinUI app actually opens on the current machine.
+
+## Required Workflow
+
+1. Identify the real build target:
+   - solution or project file
+   - configuration
+   - platform
+   - packaged or unpackaged model
+2. Build after each meaningful code edit and again at task completion.
+3. Run the app after changes when feasible. Always do it when the user asked for it or when startup, navigation, resources, or packaging changed.
+4. Use the launch path that matches the deployment model:
+   - packaged local dev: normally Visual Studio deploy or another package-aware flow
+   - unpackaged local dev: normally the built executable the user will actually run
+5. Verify real launch with objective evidence such as:
+   - non-zero main window handle
+   - expected window title
+   - responsive process with visible shell
+   - no immediate startup exception or crash
+6. After completing app work, including a first scaffold or a later build-and-fix cycle, leave a successfully verified final app instance running so the user can see that it worked unless they explicitly asked you not to.
+7. If launch fails or verification is ambiguous, debug the failure before saying the app is ready.
+
+## Packaged vs Unpackaged Rules
+
+- Choose one model intentionally before wiring startup, persistence, and launch instructions.
+- Packaged apps can rely on package identity and package-backed storage.
+- Unpackaged apps must not assume package identity. Guard or replace APIs that require it.
+- APIs such as `Windows.Storage.ApplicationData.Current` can fail in unpackaged runs even when the build succeeds.
+- Do not mix packaged-only assumptions into an unpackaged startup path.
+
+## Build and Launch Guidance
+
+- Prefer explicit platform targets when WinUI output is sensitive to architecture defaults. If `AnyCPU` creates ambiguity, use `x64` for local verification.
+- For unpackaged verification, prefer launching the built `.exe` from `bin\Debug\...\win-x64\` or the project-specific output path.
+- After a successful final launch verification, do not immediately tear the app down just because verification succeeded; keep it open for the user unless it blocks the next required action.
+- If `dotnet run` throws bootstrapper, deployment, or COM activation errors, treat that as a signal that the chosen launch path or packaging setup is wrong for the current app.
+- Stop old app instances before rebuilding if they can lock output files.
+
+## Debugging Startup Failures
+
+- Separate environment problems from app-code startup crashes.
+- If the app exits before showing a window, inspect the startup path first:
+  - `App.xaml`
+  - merged resource dictionaries
+  - converters
+  - `MainWindow`
+  - services used during startup
+- For startup or manifest issues, compare the current app against a fresh `dotnet new winui` scaffold for the same packaging model before broader surgery.
+- For opaque `MSB3073` and `XamlCompiler.exe` failures, simplify back toward the template-generated startup and shared-resource shape before making further structural changes.
+- Restore complex startup pieces incrementally when the failure point is unclear. A minimal `App.xaml` plus minimal `MainWindow` is a valid isolation step.
+- If the diagnostics look stale or inconsistent with the current files, run a clean build once before deeper surgery.
+- Prefer restoring the last known-good template-based shared-resource state over moving styles inline as the long-term fix.
+- When using unpackaged startup, review persistence, notifications, storage, and activation code for hidden package-identity assumptions.
+
+## Exit Criteria
+
+- Build succeeds from the intended local workflow.
+- The app launches from the intended local workflow.
+- A real top-level window or equivalent expected UI is confirmed.
+- No unresolved startup exception remains.