@fprad0/skill-master-mcp 0.0.9 → 0.0.10

package/docs/skill-candidates/v0.0.10/winui-app/references/shell-navigation-and-windowing.md

@@ -0,0 +1,67 @@
+---
+title: Shell, Navigation, and Windowing
+priority: HIGH
+tags: navigationview, titlebar, appwindow, multi-window, shell
+sources:
+  - https://learn.microsoft.com/windows/apps/design/basics/navigation-basics
+  - https://learn.microsoft.com/windows/apps/design/basics/titlebar-design
+  - https://github.com/microsoft/WinUI-Gallery
+  - https://github.com/microsoft/WindowsAppSDK-Samples/tree/main/Samples/Windowing
+---
+
+## What This Reference Is For
+
+Use this file for top-level app shells, page navigation models, custom title bars, and multi-window decisions.
+
+## Prefer
+
+- `NavigationView` for standard desktop shells with clear top-level destinations.
+- A small, stable set of primary destinations.
+- Built-in back navigation behavior that matches user expectations.
+- `AppWindow` and Windows App SDK windowing APIs for modern window management.
+
+## Avoid
+
+- Overloading the nav surface with every command and secondary action.
+- Turning the `NavigationView` pane into a branded hero area when the user did not ask for custom shell treatment.
+- Custom title bar layouts that break drag regions or caption button clarity.
+- Multi-window designs unless the workflow clearly benefits from them.
+
+## Navigation Guidance
+
+- Use left navigation when the app has several stable, high-level destinations.
+- Use top navigation when there are few peer destinations and width is available.
+- Use a single-page or document-first layout when navigation is shallow and the user mostly stays in one workflow.
+- Keep naming and iconography stable across pages.
+- Treat `NavigationView` as functional shell chrome first. Keep pane headers, footer content, and decorative branding minimal unless the product requirements clearly call for them.
+- Prefer the platform's normal pane structure before adding custom logo blocks, taglines, or non-navigation content that changes the shell's native feel.
+- For narrow or phone-like widths, stop reserving permanent pane width for desktop navigation. Prefer a minimal or overlay navigation mode, show the pane toggle when needed, close the pane by default after navigation, and give content the width back.
+- When a shell enters a phone-width mode, reduce content padding and decorative chrome so the page reads as one primary column instead of a desktop shell with a squeezed content strip.
+
+## Title Bar Guidance
+
+- Treat the title bar as functional chrome first, branding surface second.
+- Keep empty non-interactive areas draggable.
+- Blend title bar visuals with the rest of the app when possible.
+- Respect light, dark, and high-contrast states.
+
+## Windowing Guidance
+
+- Start with one main window.
+- Add secondary windows only for workflows such as document detachment, inspection panes, or tool windows.
+- Use Windows App SDK samples for resizing, placement, and window-specific behaviors instead of inventing custom platform abstractions.
+
+## Sample and Source Anchors
+
+- WinUI Gallery `NavigationView`, `TitleBar`, `AppWindow`, and windowing sample pages
+- WindowsAppSDK-Samples `Samples/Windowing`
+- Learn navigation and title bar guidance
+
+## Review Checklist
+
+- Is the navigation model simple and intentional?
+- Does the shell still look and behave like a normal WinUI `NavigationView` unless there is an explicit reason to diverge?
+- Does the title bar still behave like a Windows title bar?
+- Are back, search, and pane behaviors consistent?
+- Is multi-window use justified by the workflow?
+- Does the shell intentionally switch behavior at narrow or phone widths instead of leaving a full desktop pane open?

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

@@ -0,0 +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?

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

@@ -0,0 +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.

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

@@ -0,0 +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?

package/manifests/channels/beta.json

@@ -1,13 +1,13 @@
 {
   "name": "skill_master",
   "channel": "beta",
-  "version": "00.03-beta",
-  "semver": "0.0.9",
-  "publishedAt": "2026-06-28T00:02:47-03:00",
+  "version": "00.04-beta",
+  "semver": "0.0.10",
+  "publishedAt": "2026-06-28T14:00:39-03:00",
   "git": {
     "repo": "https://github.com/FPrad0/skill-master-mcp",
     "branch": "main",
-    "commit": "69c220f"
+    "commit": "f955c13"
   },
   "node": {
     "minimum": "18.0.0"
@@ -19,8 +19,8 @@
     "buildCommand": "npm run build"
   },
   "changelog": [
-    "Canal beta acompanha governanca moral, roteamento amplo e bootstrap global.",
-    "Skills globais candidatas ficam empacotadas para validacao e estudo.",
-    "Menu exibe alerta forte quando o MCP ainda nao esta aplicado globalmente."
+    "Canal beta acompanha o bundle global ampliado e a nova apresentacao cyberpunk do menu.",
+    "Fluxo interativo volta selecionavel apos executar acoes e retornar ao TUI.",
+    "Doctor, bootstrap global e registro multi-cliente continuam prontos para notebooks novos."
   ]
 }

package/manifests/channels/stable.json

@@ -1,13 +1,13 @@
 {
   "name": "skill_master",
   "channel": "stable",
-  "version": "00.03",
-  "semver": "0.0.9",
-  "publishedAt": "2026-06-28T00:02:47-03:00",
+  "version": "00.04",
+  "semver": "0.0.10",
+  "publishedAt": "2026-06-28T14:00:39-03:00",
   "git": {
     "repo": "https://github.com/FPrad0/skill-master-mcp",
     "branch": "main",
-    "commit": "69c220f"
+    "commit": "f955c13"
   },
   "node": {
     "minimum": "18.0.0"
@@ -19,9 +19,9 @@
     "buildCommand": "npm run build"
   },
   "changelog": [
-    "Governanca moral adiciona discernimento, gates de dignidade humana, verdade, bem comum e limites profissionais.",
-    "Roteamento amplo recomenda skills globais aprovadas por dominio tecnico, linguagem, ciencia, filosofia e engenharia.",
-    "Skills globais embutidas podem ser instaladas em CODEX_HOME/skills ou ~/.codex/skills.",
-    "Bootstrap global registra o MCP para Codex, Claude Desktop e Gemini com alerta visual no menu."
+    "Catalogo global embutido cresce com skills de frontend, backend, CLI, GitHub, OpenAI docs, design, idiomas, ciencia e MCP.",
+    "Menu visual exibe totais do bundle, dominios, metadata da acao selecionada e telemetria operacional em layout cyberpunk.",
+    "Retorno ao menu volta a aceitar selecao por teclado depois de executar uma acao.",
+    "Doctor e bootstrap continuam validando e preparando Codex, Claude, Gemini e Antigravity para uso global."
   ]
 }

package/network/unapproved-skill-candidates.json

@@ -1,5 +1,5 @@
 {
-  "generatedAt": "2026-06-26T00:00:00.000Z",
+  "generatedAt": "2026-06-28T15:18:09.013Z",
   "policyVersion": "success-learning-human-approval-v1",
   "note": "External skills or skill references reviewed by skill_master. Entries can be approved for active local wrapper use, study reference use, or remain blocked.",
   "candidates": [
@@ -72,6 +72,39 @@
       "localSkillName": "openai-evals-guidance",
       "reason": "Approved as a study-reference wrapper for validation methodology and approval-gate design.",
       "riskFlags": []
+    },
+    {
+      "name": "charmbracelet-bubbletea-renderer-patterns",
+      "description": "Go TUI framework with renderer and terminal app patterns useful for studying low-flicker terminal UI architecture.",
+      "sourceUrl": "https://github.com/charmbracelet/bubbletea",
+      "creatorName": "Charmbracelet",
+      "creatorUrl": "https://charm.sh",
+      "reviewStatus": "unapproved",
+      "approvalScope": "study-reference-candidate",
+      "reason": "Study renderer architecture, keyboard handling and full-window terminal application patterns. Not imported because it is external and uses a different runtime.",
+      "riskFlags": ["external-source", "different-runtime-go", "not-imported"]
+    },
+    {
+      "name": "blessed-contrib-terminal-dashboard-patterns",
+      "description": "JavaScript terminal dashboard library with ANSI/ascii widgets useful for studying Node.js terminal dashboards.",
+      "sourceUrl": "https://github.com/yaronn/blessed-contrib",
+      "creatorName": "Yaron Naveh and contributors",
+      "creatorUrl": "https://github.com/yaronn/blessed-contrib",
+      "reviewStatus": "unapproved",
+      "approvalScope": "study-reference-candidate",
+      "reason": "Study dashboard composition and Node.js terminal visual panels. Not imported because adding dependency risk needs separate approval.",
+      "riskFlags": ["external-source", "dependency-risk", "not-imported"]
+    },
+    {
+      "name": "notcurses-character-graphics-patterns",
+      "description": "Character graphics/TUI project useful for studying high-density Unicode terminal graphics and modern terminal limits.",
+      "sourceUrl": "https://github.com/dankamongmen/notcurses",
+      "creatorName": "Nick Black and contributors",
+      "creatorUrl": "https://github.com/dankamongmen/notcurses",
+      "reviewStatus": "unapproved",
+      "approvalScope": "study-reference-candidate",
+      "reason": "Study dense terminal graphics concepts before future advanced renderer work. Not imported because it is an external C/native ecosystem.",
+      "riskFlags": ["external-source", "different-runtime-c", "not-imported"]
     }
   ]
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fprad0/skill-master-mcp",
-  "version": "0.0.9",
+  "version": "0.0.10",
   "private": false,
   "type": "module",
   "description": "Personal MCP server that catalogs, recommends and reports skills with update-aware metadata.",
@@ -8,6 +8,7 @@
   "bin": {
     "skill-master-activation": "./bin/skill-master-activation.mjs",
     "skill-master-configure-private-registry": "./bin/skill-master-configure-private-registry.mjs",
+    "skill-master-doctor": "./bin/skill-master-doctor.mjs",
     "skill-master-eval-activation": "./bin/skill-master-eval-activation.mjs",
     "skill-master-bootstrap-global": "./bin/skill-master-bootstrap-global.mjs",
     "skill-master-install-global-skills": "./bin/skill-master-install-global-skills.mjs",