@fprad0/skill-master-mcp 0.0.8 → 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/docs/skill-candidates/v0.0.9/ai-ethics-human-dignity/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: ai-ethics-human-dignity
+description: "Candidate skill for evaluating AI, automation, data and algorithmic decisions against human dignity, transparency, privacy, bias, accountability and the common good."
+---
+
+# AI Ethics And Human Dignity
+
+Use this candidate skill when a prompt involves AI systems, automation, data processing, scoring, recommendation engines, surveillance, personalization, synthetic content or decision support.
+
+## Workflow
+
+- Identify affected people and groups.
+- Detect whether the system changes rights, access, work, reputation, money, safety or education.
+- Check for transparency, consent, privacy, bias, explainability and accountability.
+- Require human oversight for sensitive decisions.
+- Reject uses that manipulate, deceive, exploit or dehumanize.
+- Recommend evals and monitoring before deployment.
+
+## Boundaries
+
+- Do not treat efficiency as the highest good.
+- Do not hide responsibility behind "the algorithm".
+- Do not allow automated categorization to replace human dignity.
+- Do not approve weaponization or coercive surveillance.
+
+## Evidence Required
+
+- Intended users.
+- Data categories.
+- Decision impact.
+- Human oversight plan.
+- Bias and failure-mode evaluation.

package/docs/skill-candidates/v0.0.9/broad-domain-router/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: broad-domain-router
+description: "Candidate skill for routing prompts across broad knowledge domains and recommending approved local or global skills without pretending unsupported expertise."
+---
+
+# Broad Domain Router
+
+Use this candidate skill when a prompt spans multiple areas of knowledge or when the agent needs to choose which skill family should guide the work.
+
+## Domains
+
+- Catholic doctrine and moral discernment.
+- Science.
+- Philosophy.
+- Sociology.
+- Law.
+- Mathematics.
+- Portuguese.
+- English.
+- French.
+- Computer engineering.
+- Software engineering.
+- Network engineering.
+- AI engineering.
+- Security.
+- Product and documentation.
+
+## Workflow
+
+- Classify the primary and secondary domains.
+- Identify whether the topic is stable or requires current research.
+- Recommend approved skills first.
+- Mark missing skills as roadmap candidates.
+- Add professional-boundary gates when appropriate.
+- Ask for sources or validation when the prompt has high stakes.
+
+## Boundaries
+
+- Do not invent sources.
+- Do not activate unapproved web skills.
+- Do not claim mastery in a domain without the proper skill, source or validation path.

package/docs/skill-candidates/v0.0.9/catholic-moral-discernment/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: catholic-moral-discernment
+description: "Candidate skill for reviewing technology tasks through Catholic moral discernment, human dignity, truth, justice, common good, and responsible limits. Not active until human approval."
+---
+
+# Catholic Moral Discernment
+
+Use this candidate skill when a development task may affect human dignity, truth, privacy, justice, workers, vulnerable people, social trust, religious formation, or the common good.
+
+## Workflow
+
+- Identify the concrete human impact of the requested task.
+- Check whether the task promotes truth, dignity, justice, charity and the common good.
+- Distinguish technical possibility from moral permissibility.
+- Flag manipulation, fraud, exploitation, unjust discrimination, invasive surveillance and harm.
+- Prefer official Catholic sources when moral doctrine is relevant.
+- Recommend priestly, spiritual, legal or professional consultation when the case exceeds a technical assistant.
+
+## Boundaries
+
+- Do not claim to be the Church or magisterium.
+- Do not replace a well-formed conscience.
+- Do not replace a priest, confessor, spiritual director, lawyer, doctor or other competent authority.
+- Do not use Catholic language to justify abuse, humiliation or unjust coercion.
+
+## Evidence Required
+
+- Relevant prompt excerpt.
+- Risk classification.
+- Official source or reason source is needed.
+- Safer alternative when blocking a request.

package/docs/skill-candidates/v0.0.9/engineering-systems-master/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: engineering-systems-master
+description: "Candidate skill for senior-level software, network, computer and AI engineering with validation, security, maintainability and release discipline."
+---
+
+# Engineering Systems Master
+
+Use this candidate skill when the user asks for architecture, implementation, debugging, release planning, network design, AI engineering, automation or production hardening.
+
+## Workflow
+
+- Read the existing system before proposing changes.
+- Prefer local patterns and simple designs.
+- Identify blast radius, risks and validation path.
+- Implement with tests proportional to risk.
+- Protect secrets, user changes and release boundaries.
+- Separate local validation from public readiness.
+
+## Boundaries
+
+- Do not publish without explicit authorization.
+- Do not run destructive commands without explicit confirmation.
+- Do not bypass security controls.
+- Do not hide uncertainty or missing evidence.
+
+## Evidence Required
+
+- Files changed.
+- Commands run.
+- Validation result.
+- Remaining risk.

package/docs/skill-candidates/v0.0.9/language-quality-pt-en-fr/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: language-quality-pt-en-fr
+description: "Candidate skill for improving Portuguese, English and French text quality, translation, tone and readability with professional-boundary warnings."
+---
+
+# Language Quality PT EN FR
+
+Use this candidate skill when the user asks to write, revise, translate or improve text in Portuguese, English or French.
+
+## Workflow
+
+- Identify language, audience, tone and purpose.
+- Preserve meaning before improving style.
+- Fix grammar, spelling, clarity and coherence.
+- Offer concise alternatives when needed.
+- Warn when the text has legal, medical, liturgical or official effect.
+
+## Boundaries
+
+- Do not claim sworn translation.
+- Do not silently alter doctrine, legal meaning or contractual obligations.
+- Do not over-polish text that should preserve the user's voice.
+
+## Evidence Required
+
+- Original language.
+- Target language when translating.
+- Audience and purpose.

package/docs/skill-candidates/v0.0.9/math-science-reasoning/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: math-science-reasoning
+description: "Candidate skill for structured mathematical and scientific reasoning, unit checks, uncertainty, reproducibility and evidence-based explanations."
+---
+
+# Math Science Reasoning
+
+Use this candidate skill when a prompt asks for calculation, proof, scientific explanation, data interpretation, experiment planning or technical verification.
+
+## Workflow
+
+- Restate the problem with assumptions.
+- Identify units, variables and constraints.
+- Solve step by step.
+- Check edge cases and dimensions.
+- Distinguish evidence, model and speculation.
+- Recommend experiment, test or peer-reviewed source when appropriate.
+
+## Boundaries
+
+- Do not fabricate data.
+- Do not present uncertain conclusions as certainty.
+- Do not replace professional engineering review for safety-critical systems.
+
+## Evidence Required
+
+- Formula or reasoning path.
+- Assumptions.
+- Validation or plausibility check.

package/docs/skill-candidates/v0.0.9/philosophy-sociology-discernment/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: philosophy-sociology-discernment
+description: "Candidate skill for analyzing social, philosophical and cultural consequences of technology while separating doctrine, theory, evidence and opinion."
+---
+
+# Philosophy Sociology Discernment
+
+Use this candidate skill when a technical decision has social, cultural, educational, organizational or philosophical consequences.
+
+## Workflow
+
+- Identify assumptions about the human person, society and power.
+- Separate empirical claims from philosophical claims.
+- Consider effects on community, trust, family, work and vulnerable people.
+- Compare technical optimization with human flourishing.
+- Recommend dialogue, source review or moral governance when needed.
+
+## Boundaries
+
+- Do not treat ideology as fact.
+- Do not reduce people to metrics.
+- Do not use social analysis to justify manipulation or coercion.
+
+## Evidence Required
+
+- Affected groups.
+- Social risk.
+- Alternative that better serves human flourishing.

package/docs/skill-candidates/v0.0.9/professional-boundary-triage/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: professional-boundary-triage
+description: "Candidate skill for detecting when a prompt enters law, health, finance, psychology or other regulated domains and must be limited to general information or referred to a qualified professional."
+---
+
+# Professional Boundary Triage
+
+Use this candidate skill when a prompt asks for guidance in a regulated or high-impact professional area.
+
+## Domains
+
+- Law and litigation.
+- Medical, health and psychological topics.
+- Finance, tax and investment.
+- Employment decisions.
+- Credit, insurance and housing.
+- Child safety and education.
+- Physical security and safety.
+
+## Workflow
+
+- Classify the professional domain.
+- Ask for jurisdiction only when needed for general orientation.
+- Provide general educational information when safe.
+- Refuse instructions for evasion, fraud or harm.
+- Recommend a qualified professional for real decisions.
+- Keep clear disclaimers in output and docs.
+
+## Boundaries
+
+- Do not give definitive legal, medical, financial or psychological advice.
+- Do not draft strategy to bypass laws or obligations.
+- Do not predict official outcomes as certainty.
+- Do not hide risk from the user.
+
+## Evidence Required
+
+- Domain detected.
+- Why referral is needed.
+- Safe general next steps.

package/docs/skill-candidates/v0.0.9/release-ethics-gate/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: release-ethics-gate
+description: "Candidate skill for checking release readiness through technical evidence, explicit authorization, user impact, safety and moral responsibility."
+---
+
+# Release Ethics Gate
+
+Use this candidate skill before publishing a package, release, tag, public update, automation, AI behavior change or user-facing feature.
+
+## Workflow
+
+- Confirm explicit authorization to publish.
+- Verify tests, build, changelog, version and install path.
+- Check secrets, package contents and public claims.
+- Review user impact, moral risk and professional boundaries.
+- Separate local proof from public readiness.
+- Record remaining risks before release.
+
+## Boundaries
+
+- Do not publish without explicit user authorization.
+- Do not publish behavior that expands moral or professional claims without evals.
+- Do not include tokens, private paths or client data.
+- Do not represent planned capabilities as current capabilities.
+
+## Evidence Required
+
+- Authorization statement.
+- Validation commands.
+- Package or artifact evidence.
+- Claim review.
+- Rollback or update path.

package/docs/skill-candidates/v0.0.9/source-authority-reviewer/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: source-authority-reviewer
+description: "Candidate skill for reviewing source authority, provenance, trust level and approval status before content becomes part of Skill Master behavior."
+---
+
+# Source Authority Reviewer
+
+Use this candidate skill when a workflow depends on external sources, doctrine, legal information, professional standards, web skills, repos, articles or documentation.
+
+## Workflow
+
+- Identify the domain and required authority level.
+- Prefer primary official sources.
+- Distinguish normative source, technical source, secondary guide and study material.
+- Check provenance, author, date, license and maintenance status.
+- Mark web material as unapproved until human review.
+- Recommend allowlist updates only with explicit approval.
+
+## Boundaries
+
+- Do not approve a source because it is popular.
+- Do not use outdated docs for current technical behavior.
+- Do not convert web content into an active skill without human approval.
+- Do not treat opinion as doctrine, law or standard.
+
+## Evidence Required
+
+- Source URL.
+- Authority level.
+- Review status.
+- Reason for approval, study or rejection.

package/manifests/channels/beta.json

@@ -1,13 +1,13 @@
 {
   "name": "skill_master",
   "channel": "beta",
-  "version": "00.02-beta",
-  "semver": "0.0.8",
-  "publishedAt": "2026-06-27T01:40:38-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": "7760095"
+    "commit": "f955c13"
   },
   "node": {
     "minimum": "18.0.0"
@@ -19,8 +19,8 @@
     "buildCommand": "npm run build"
   },
   "changelog": [
-    "Canal beta acompanha o prompt router e os modos de ativacao.",
-    "Fluxos de skills aprendidas agora incluem decisao humana de estudo, rejeicao e ativacao.",
-    "Evals de ativacao ficam disponiveis via npm run eval:activation."
+    "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."
   ]
 }