@fprad0/skill-master-mcp 0.0.12 → 1.0.1

package/docs/skill-candidates/v0.0.10/winui-app/references/styling-theming-materials-and-icons.md

@@ -1,71 +1,71 @@
----
-title: Styling, Theming, Materials, and Icons
-priority: HIGH
-tags: styling, theme-resources, mica, acrylic, typography, icons
-sources:
-  - https://learn.microsoft.com/windows/apps/design/style/mica
-  - https://learn.microsoft.com/windows/apps/design/style/acrylic
-  - https://learn.microsoft.com/windows/apps/design/signature-experiences/typography
-  - https://learn.microsoft.com/windows/apps/design/signature-experiences/iconography
-  - https://github.com/microsoft/WinUI-Gallery
-  - https://github.com/microsoft/WindowsAppSDK-Samples/tree/main/Samples/Mica
----
-
-## What This Reference Is For
-
-Use this file for Fluent styling choices, theme resources, Mica or Acrylic usage, custom title bar visuals, typography, and iconography.
-
-## Prefer
-
-- Theme resources and system brushes over hard-coded colors.
-- Standard WinUI surface resources and default control chrome before custom panel systems.
-- Mica on long-lived surfaces such as the main window background or title bar region.
-- Acrylic on transient or light-dismiss surfaces.
-- Segoe UI Variable or platform-default typography choices.
-- Fluent iconography that matches the platform language.
-- When metadata needs a visual container, prefer small rounded rectangles or subtle badges over bright oval pills.
-
-## Avoid
-
-- Hard-coded light-theme colors that break dark or high-contrast themes.
-- Wrapping every region in a custom `Border` with a bespoke corner radius, stroke, and fill when standard WinUI surfaces would do the job.
-- Adding an outer section `Border` around content that is already visually grouped by card controls, spacing, or headers; this often creates a redundant "card around cards" effect.
-- Using Acrylic where Mica or a simple theme-aware surface would be cheaper and clearer.
-- Mixing unrelated icon styles.
-- Filling lists or cards with rows of decorative oval chips for routine metadata. Use tag treatments sparingly, and default to rounded rectangles when they are justified.
-
-## Theming Guidance
-
-- Support light, dark, and high-contrast by default.
-- Centralize brushes, typography, and corner/spacing decisions in shared resource dictionaries.
-- Let built-in controls keep their platform behavior unless there is a strong design reason to customize them.
-- When a grouped surface is needed, prefer system resources such as `CardBackgroundFillColorDefaultBrush`, `CardStrokeColorDefaultBrush`, and `LayerFillColorDefaultBrush` instead of inventing a parallel surface language.
-- If child content already uses card-like surfaces, prefer removing the outer section border and relying on layout spacing and typography for grouping unless the section needs its own distinct background, inset, or stroke.
-
-## Materials Guidance
-
-- Use Mica for long-lived base layers.
-- Use Acrylic for transient surfaces such as flyouts and menus.
-- Verify fallback behavior on older Windows versions or unsupported scenarios.
-
-## Icon and Typography Guidance
-
-- Use standard Windows iconography and keep visual weight consistent.
-- Use typography to create hierarchy instead of adding extra borders or decoration.
-- Keep title bar text and document titles aligned with Windows guidance.
-
-## Sample and Source Anchors
-
-- Learn material, typography, and iconography guidance
-- WinUI Gallery system backdrop and styling pages
-- WindowsAppSDK-Samples `Samples/Mica`
-
-## Review Checklist
-
-- Are colors and brushes theme-aware?
-- Does the app look correct in light, dark, and high contrast?
-- Is the selected material appropriate for the surface lifetime?
-- Are icon and typography choices consistent with Fluent design?
-- Are standard WinUI surfaces doing most of the visual work, with custom borders limited to clearly justified cases?
-- Are there any redundant outer borders that could be removed without losing hierarchy or usability?
-- Are tag or chip treatments sparse, visually quiet, and not rendered as default oval pills unless the product explicitly calls for that style?
+---
+title: Styling, Theming, Materials, and Icons
+priority: HIGH
+tags: styling, theme-resources, mica, acrylic, typography, icons
+sources:
+  - https://learn.microsoft.com/windows/apps/design/style/mica
+  - https://learn.microsoft.com/windows/apps/design/style/acrylic
+  - https://learn.microsoft.com/windows/apps/design/signature-experiences/typography
+  - https://learn.microsoft.com/windows/apps/design/signature-experiences/iconography
+  - https://github.com/microsoft/WinUI-Gallery
+  - https://github.com/microsoft/WindowsAppSDK-Samples/tree/main/Samples/Mica
+---
+
+## What This Reference Is For
+
+Use this file for Fluent styling choices, theme resources, Mica or Acrylic usage, custom title bar visuals, typography, and iconography.
+
+## Prefer
+
+- Theme resources and system brushes over hard-coded colors.
+- Standard WinUI surface resources and default control chrome before custom panel systems.
+- Mica on long-lived surfaces such as the main window background or title bar region.
+- Acrylic on transient or light-dismiss surfaces.
+- Segoe UI Variable or platform-default typography choices.
+- Fluent iconography that matches the platform language.
+- When metadata needs a visual container, prefer small rounded rectangles or subtle badges over bright oval pills.
+
+## Avoid
+
+- Hard-coded light-theme colors that break dark or high-contrast themes.
+- Wrapping every region in a custom `Border` with a bespoke corner radius, stroke, and fill when standard WinUI surfaces would do the job.
+- Adding an outer section `Border` around content that is already visually grouped by card controls, spacing, or headers; this often creates a redundant "card around cards" effect.
+- Using Acrylic where Mica or a simple theme-aware surface would be cheaper and clearer.
+- Mixing unrelated icon styles.
+- Filling lists or cards with rows of decorative oval chips for routine metadata. Use tag treatments sparingly, and default to rounded rectangles when they are justified.
+
+## Theming Guidance
+
+- Support light, dark, and high-contrast by default.
+- Centralize brushes, typography, and corner/spacing decisions in shared resource dictionaries.
+- Let built-in controls keep their platform behavior unless there is a strong design reason to customize them.
+- When a grouped surface is needed, prefer system resources such as `CardBackgroundFillColorDefaultBrush`, `CardStrokeColorDefaultBrush`, and `LayerFillColorDefaultBrush` instead of inventing a parallel surface language.
+- If child content already uses card-like surfaces, prefer removing the outer section border and relying on layout spacing and typography for grouping unless the section needs its own distinct background, inset, or stroke.
+
+## Materials Guidance
+
+- Use Mica for long-lived base layers.
+- Use Acrylic for transient surfaces such as flyouts and menus.
+- Verify fallback behavior on older Windows versions or unsupported scenarios.
+
+## Icon and Typography Guidance
+
+- Use standard Windows iconography and keep visual weight consistent.
+- Use typography to create hierarchy instead of adding extra borders or decoration.
+- Keep title bar text and document titles aligned with Windows guidance.
+
+## Sample and Source Anchors
+
+- Learn material, typography, and iconography guidance
+- WinUI Gallery system backdrop and styling pages
+- WindowsAppSDK-Samples `Samples/Mica`
+
+## Review Checklist
+
+- Are colors and brushes theme-aware?
+- Does the app look correct in light, dark, and high contrast?
+- Is the selected material appropriate for the surface lifetime?
+- Are icon and typography choices consistent with Fluent design?
+- Are standard WinUI surfaces doing most of the visual work, with custom borders limited to clearly justified cases?
+- Are there any redundant outer borders that could be removed without losing hierarchy or usability?
+- Are tag or chip treatments sparse, visually quiet, and not rendered as default oval pills unless the product explicitly calls for that style?

package/docs/skill-candidates/v0.0.10/winui-app/references/testing-debugging-and-review-checklists.md

@@ -1,77 +1,77 @@
----
-title: Testing, Debugging, and Review Checklists
-priority: HIGH
-tags: testing, debugging, review, hot-reload, live-visual-tree, checklists
-sources:
-  - https://learn.microsoft.com/windows/apps/get-started/start-here
-  - https://learn.microsoft.com/windows/apps/get-started/developer-mode-features-and-debugging
-  - https://learn.microsoft.com/windows/apps/performance/winui-perf
----
-
-## What This Reference Is For
-
-Use this file for final review passes, debugging sessions, and "what should I verify before I call this done?" prompts.
-
-## Required Verification Loop
-
-- Build after each meaningful edit, not only at the end.
-- Run the app after changes when the user asked for it or when startup-sensitive files changed.
-- Verify actual launch instead of assuming success from a spawned process.
-- If the app fails before showing a window, debug the startup path before continuing feature work.
-
-## Design Review Checklist
-
-- Shell and navigation are simple and predictable.
-- `NavigationView` still reads like standard WinUI shell chrome unless the product explicitly calls for branded pane content or custom shell composition.
-- Layout stays usable when the window is narrow.
-- Layout has been checked at more than one breakpoint, including a genuinely phone-like width when the app can be resized that far.
-- Collection pages with mixed scroll regions have been checked at runtime so shelves still render in the intended direction and do not collapse into a single vertical column.
-- Theme, contrast, hierarchy, and interactive state visibility hold up in both light and dark mode, and typography and iconography still feel native to Windows.
-- Command placement and hierarchy are clear.
-- Default WinUI surfaces and control templates carry most of the layout instead of a custom border/card system.
-- Search and filter workflows avoid redundant controls when live local filtering would be clearer.
-- At narrow and phone widths, nonessential controls are simplified, hidden, or moved behind shell affordances instead of merely compressed.
-
-## Code Review Checklist
-
-- App structure is coherent and scalable.
-- Resource dictionaries and styles are centralized where they should be.
-- Platform controls are preferred over unnecessary custom control work.
-- New dependencies are justified.
-- The packaging model matches the startup, storage, and launch code.
-- The app builds cleanly from the workflow the user will actually use.
-
-## Accessibility Checklist
-
-- Keyboard-only flow works end to end.
-- Focus states are visible and sensible.
-- Automation properties are present where needed.
-- High contrast and text scaling do not break the UI.
-
-## Performance Checklist
-
-- No obvious UI-thread blocking work in interactive paths.
-- Large collections use an appropriate control and layout.
-- Scroll ownership is intentional for collection-heavy pages; nested `GridView` plus outer `ScrollViewer` combinations have been justified or replaced.
-- Expensive styling or template choices are justified.
-- Profiling data exists for non-obvious performance claims.
-
-## Debugging Tools
-
-- Use Hot Reload for fast visual iteration.
-- Use Live Visual Tree and Live Property Explorer for layout and property debugging.
-- Use WPR and WPA when diagnosing frame or responsiveness issues.
-- Reproduce resize, theme, and input-mode changes before concluding the issue is fixed.
-- When resize behavior is part of the task, verify wide, medium, and phone-width states against the running app rather than trusting the XAML structure alone.
-- When a collection page looks wrong, inspect the live tree for nested `ScrollViewer` ownership before rewriting the item template; the bug may be layout ownership rather than card markup.
-- Use startup exception details, debugger output, or Event Viewer when the process dies before any window appears.
-
-## Exit Criteria
-
-- The build succeeds from the intended local workflow.
-- The feature works on the intended machine configuration.
-- The app launches and shows the expected shell or window.
-- The app remains usable in light, dark, and high contrast.
-- Primary flows are keyboard-accessible.
-- Resize behavior, startup, and interactive responsiveness have been checked.
-- If the window can become phone-width, the shell and content have been verified there too.
+---
+title: Testing, Debugging, and Review Checklists
+priority: HIGH
+tags: testing, debugging, review, hot-reload, live-visual-tree, checklists
+sources:
+  - https://learn.microsoft.com/windows/apps/get-started/start-here
+  - https://learn.microsoft.com/windows/apps/get-started/developer-mode-features-and-debugging
+  - https://learn.microsoft.com/windows/apps/performance/winui-perf
+---
+
+## What This Reference Is For
+
+Use this file for final review passes, debugging sessions, and "what should I verify before I call this done?" prompts.
+
+## Required Verification Loop
+
+- Build after each meaningful edit, not only at the end.
+- Run the app after changes when the user asked for it or when startup-sensitive files changed.
+- Verify actual launch instead of assuming success from a spawned process.
+- If the app fails before showing a window, debug the startup path before continuing feature work.
+
+## Design Review Checklist
+
+- Shell and navigation are simple and predictable.
+- `NavigationView` still reads like standard WinUI shell chrome unless the product explicitly calls for branded pane content or custom shell composition.
+- Layout stays usable when the window is narrow.
+- Layout has been checked at more than one breakpoint, including a genuinely phone-like width when the app can be resized that far.
+- Collection pages with mixed scroll regions have been checked at runtime so shelves still render in the intended direction and do not collapse into a single vertical column.
+- Theme, contrast, hierarchy, and interactive state visibility hold up in both light and dark mode, and typography and iconography still feel native to Windows.
+- Command placement and hierarchy are clear.
+- Default WinUI surfaces and control templates carry most of the layout instead of a custom border/card system.
+- Search and filter workflows avoid redundant controls when live local filtering would be clearer.
+- At narrow and phone widths, nonessential controls are simplified, hidden, or moved behind shell affordances instead of merely compressed.
+
+## Code Review Checklist
+
+- App structure is coherent and scalable.
+- Resource dictionaries and styles are centralized where they should be.
+- Platform controls are preferred over unnecessary custom control work.
+- New dependencies are justified.
+- The packaging model matches the startup, storage, and launch code.
+- The app builds cleanly from the workflow the user will actually use.
+
+## Accessibility Checklist
+
+- Keyboard-only flow works end to end.
+- Focus states are visible and sensible.
+- Automation properties are present where needed.
+- High contrast and text scaling do not break the UI.
+
+## Performance Checklist
+
+- No obvious UI-thread blocking work in interactive paths.
+- Large collections use an appropriate control and layout.
+- Scroll ownership is intentional for collection-heavy pages; nested `GridView` plus outer `ScrollViewer` combinations have been justified or replaced.
+- Expensive styling or template choices are justified.
+- Profiling data exists for non-obvious performance claims.
+
+## Debugging Tools
+
+- Use Hot Reload for fast visual iteration.
+- Use Live Visual Tree and Live Property Explorer for layout and property debugging.
+- Use WPR and WPA when diagnosing frame or responsiveness issues.
+- Reproduce resize, theme, and input-mode changes before concluding the issue is fixed.
+- When resize behavior is part of the task, verify wide, medium, and phone-width states against the running app rather than trusting the XAML structure alone.
+- When a collection page looks wrong, inspect the live tree for nested `ScrollViewer` ownership before rewriting the item template; the bug may be layout ownership rather than card markup.
+- Use startup exception details, debugger output, or Event Viewer when the process dies before any window appears.
+
+## Exit Criteria
+
+- The build succeeds from the intended local workflow.
+- The feature works on the intended machine configuration.
+- The app launches and shows the expected shell or window.
+- The app remains usable in light, dark, and high contrast.
+- Primary flows are keyboard-accessible.
+- Resize behavior, startup, and interactive responsiveness have been checked.
+- If the window can become phone-width, the shell and content have been verified there too.

package/docs/skill-candidates/v0.0.10/winui-app/references/windows-app-sdk-lifecycle-notifications-and-deployment.md

@@ -1,52 +1,52 @@
----
-title: Windows App SDK Lifecycle, Notifications, and Deployment
-priority: HIGH
-tags: windows-app-sdk, lifecycle, activation, notifications, deployment, packaged, unpackaged
-sources:
-  - https://learn.microsoft.com/windows/apps/windows-app-sdk/
-  - https://learn.microsoft.com/windows/apps/windows-app-sdk/deploy-packaged-apps
-  - https://learn.microsoft.com/windows/apps/windows-app-sdk/deploy-unpackaged-apps
-  - https://github.com/microsoft/WindowsAppSDK-Samples
----
-
-## What This Reference Is For
-
-Use this file when the user needs lifecycle, activation, notification, packaged vs unpackaged, or runtime initialization guidance that goes beyond plain XAML UI work.
-
-## Prefer
-
-- Learning the scenario from the matching WindowsAppSDK sample before designing an abstraction.
-- Packaged deployment when it fits the product constraints.
-- Explicit unpackaged guidance when the user has an installer, external-location requirement, or expects repeatable direct executable launches during development.
-
-## Avoid
-
-- Mixing packaged and unpackaged guidance in one answer without stating which path applies.
-- Treating deployment requirements as optional details.
-- Re-implementing lifecycle behavior already covered by Windows App SDK APIs.
-- Using package-identity-dependent APIs in unpackaged startup code without an explicit guard or replacement path.
-
-## Guidance
-
-- Use AppLifecycle guidance and samples for activation, instancing, restart, and state notifications.
-- Use notifications samples for push or app notifications rather than inventing custom delivery logic.
-- For packaged apps, account for framework-dependent deployment and runtime package requirements.
-- For unpackaged apps, account for bootstrapper and runtime initialization requirements.
-- For unpackaged apps, treat package identity as absent unless the app deliberately establishes it through the chosen deployment model.
-- Keep storage, settings, and startup services aligned with the deployment model. If a service assumes packaged storage or activation, redesign it before local unpackaged verification.
-- Explain the deployment model before giving build or publish steps.
-
-## Sample and Source Anchors
-
-- WindowsAppSDK-Samples `Samples/AppLifecycle`
-- WindowsAppSDK-Samples `Samples/Notifications`
-- WindowsAppSDK-Samples `Samples/Unpackaged`
-- WindowsAppSDK-Samples `Samples/CustomControls`
-- Learn packaged and unpackaged deployment guides
-
-## Review Checklist
-
-- Is the app’s deployment model explicit?
-- Are lifecycle and activation behaviors using platform APIs rather than ad hoc workarounds?
-- Are notification requirements matched to the correct sample and runtime guidance?
-- Does the recommendation match packaged or unpackaged constraints?
+---
+title: Windows App SDK Lifecycle, Notifications, and Deployment
+priority: HIGH
+tags: windows-app-sdk, lifecycle, activation, notifications, deployment, packaged, unpackaged
+sources:
+  - https://learn.microsoft.com/windows/apps/windows-app-sdk/
+  - https://learn.microsoft.com/windows/apps/windows-app-sdk/deploy-packaged-apps
+  - https://learn.microsoft.com/windows/apps/windows-app-sdk/deploy-unpackaged-apps
+  - https://github.com/microsoft/WindowsAppSDK-Samples
+---
+
+## What This Reference Is For
+
+Use this file when the user needs lifecycle, activation, notification, packaged vs unpackaged, or runtime initialization guidance that goes beyond plain XAML UI work.
+
+## Prefer
+
+- Learning the scenario from the matching WindowsAppSDK sample before designing an abstraction.
+- Packaged deployment when it fits the product constraints.
+- Explicit unpackaged guidance when the user has an installer, external-location requirement, or expects repeatable direct executable launches during development.
+
+## Avoid
+
+- Mixing packaged and unpackaged guidance in one answer without stating which path applies.
+- Treating deployment requirements as optional details.
+- Re-implementing lifecycle behavior already covered by Windows App SDK APIs.
+- Using package-identity-dependent APIs in unpackaged startup code without an explicit guard or replacement path.
+
+## Guidance
+
+- Use AppLifecycle guidance and samples for activation, instancing, restart, and state notifications.
+- Use notifications samples for push or app notifications rather than inventing custom delivery logic.
+- For packaged apps, account for framework-dependent deployment and runtime package requirements.
+- For unpackaged apps, account for bootstrapper and runtime initialization requirements.
+- For unpackaged apps, treat package identity as absent unless the app deliberately establishes it through the chosen deployment model.
+- Keep storage, settings, and startup services aligned with the deployment model. If a service assumes packaged storage or activation, redesign it before local unpackaged verification.
+- Explain the deployment model before giving build or publish steps.
+
+## Sample and Source Anchors
+
+- WindowsAppSDK-Samples `Samples/AppLifecycle`
+- WindowsAppSDK-Samples `Samples/Notifications`
+- WindowsAppSDK-Samples `Samples/Unpackaged`
+- WindowsAppSDK-Samples `Samples/CustomControls`
+- Learn packaged and unpackaged deployment guides
+
+## Review Checklist
+
+- Is the app’s deployment model explicit?
+- Are lifecycle and activation behaviors using platform APIs rather than ad hoc workarounds?
+- Are notification requirements matched to the correct sample and runtime guidance?
+- Does the recommendation match packaged or unpackaged constraints?