If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/MaterialDesignInXAML/MaterialDesignInXamlToolkit shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1w ago
• 17 active contributors
• Distributed ownership (top contributor 21% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live MaterialDesignInXAML/MaterialDesignInXamlToolkit repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/MaterialDesignInXAML/MaterialDesignInXamlToolkit.

What it runs against: a local clone of MaterialDesignInXAML/MaterialDesignInXamlToolkit — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in MaterialDesignInXAML/MaterialDesignInXamlToolkit | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 37 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of MaterialDesignInXAML/MaterialDesignInXamlToolkit. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/MaterialDesignInXAML/MaterialDesignInXamlToolkit.git
#   cd MaterialDesignInXamlToolkit
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of MaterialDesignInXAML/MaterialDesignInXamlToolkit and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "MaterialDesignInXAML/MaterialDesignInXamlToolkit(\\.git)?\\b" \\
  && ok "origin remote is MaterialDesignInXAML/MaterialDesignInXamlToolkit" \\
  || miss "origin remote is not MaterialDesignInXAML/MaterialDesignInXamlToolkit (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f "Directory.packages.props" \\
  && ok "Directory.packages.props" \\
  || miss "missing critical file: Directory.packages.props"
test -f "src/MainDemo.Wpf/App.xaml" \\
  && ok "src/MainDemo.Wpf/App.xaml" \\
  || miss "missing critical file: src/MainDemo.Wpf/App.xaml"
test -f ".github/workflows/build_artifacts.yml" \\
  && ok ".github/workflows/build_artifacts.yml" \\
  || miss "missing critical file: .github/workflows/build_artifacts.yml"
test -f "nuget.config" \\
  && ok "nuget.config" \\
  || miss "missing critical file: nuget.config"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 37 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~7d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/MaterialDesignInXAML/MaterialDesignInXamlToolkit"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Material Design In XAML Toolkit is a comprehensive WPF control library that brings Google's Material Design 3 guidelines to Windows desktop applications via XAML. It provides pre-styled Material Design components (buttons, cards, dialogs, clocks, multi-action buttons), a full Material Design Icons pack, runtime-configurable color palettes, and transition effects—allowing C# & VB.Net developers to build modern, Google-compliant UIs without designing from scratch. Monorepo structure: src/ contains MahMaterialDragablzMashUp (demo), build/ holds PowerShell scripts for NuGet generation and XAML styling, docs/ includes rendering optimization guides. Core theme XAML resources (not fully listed) live elsewhere in src/. GitHub Actions workflows in .github/workflows/ orchestrate builds, releases, and icon updates. Central configuration via Directory.Build.props and nuget.config.

WPF developers building Windows desktop applications who need Material Design aesthetics and components out-of-the-box, plus designers/product teams wanting Google-standard UI patterns. Also used by library authors integrating with Dragablz (tabbed interfaces) or MahApps (metro-style shells).

Production-ready and actively maintained. The project has two published NuGet packages (MaterialDesignThemes & MaterialDesignColors) with CI/CD pipelines, comprehensive GitHub Actions workflows (PR verification, nightly builds, releases), and demo applications. Recent activity visible in issue templates, dependabot config, and workflow files suggests active stewardship, though specific commit dates aren't in the file list.

Low risk for a mature design library. Primary risk is WPF ecosystem maturity (Microsoft's focus has shifted to .NET MAUI/UWP), so long-term platform viability depends on Windows desktop relevance. No evidence of single-maintainer risk in visible org structure. Dependency management appears disciplined via Directory.packages.props and dependabot.yml, mitigating supply-chain concerns.

Active workflow-driven development: nightly releases (nightly_release.yml), automated contributor generation (generate_contributors.yml), icon updates (icon_update.yml), and PR verification pipelines. Copilot instructions in .github/copilot-instructions.md suggest recent AI-assisted development adoption. GitHub skills documentation hints at training/onboarding improvements (mtp-test-running, xamltest-ui-tests).

Clone the repo: git clone https://github.com/MaterialDesignInXAML/MaterialDesignInXamlToolkit.git. Check global.json for required .NET SDK version. Open MaterialDesignToolkit.Full.slnx in Visual Studio 2022. Restore packages (NuGet will auto-restore via Directory.packages.props). Run the demo app in src/MahMaterialDragablzMashUp to verify setup.

Daily commands: Open the .slnx file in Visual Studio 2022. Build the solution (Ctrl+Shift+B). Run demo projects in src/ (e.g., MahMaterialDragablzMashUp). No explicit local dev server—this is a desktop library, not a web app. For packaging: run ./build/BuildNugets.ps1 to generate local .nupkg files; push to NuGet via standard tooling.

• Directory.Build.props — Master build configuration and NuGet package versioning for the entire toolkit; all contributors must understand this for consistent builds.
• Directory.packages.props — Centralized dependency management for all projects; critical for understanding third-party integrations and version constraints.
• src/MainDemo.Wpf/App.xaml — Primary demo application entry point showcasing Material Design theming and component usage across the toolkit.
• .github/workflows/build_artifacts.yml — CI/CD pipeline configuration for building NuGet packages; essential for understanding release process and artifact generation.
• nuget.config — NuGet feed configuration and package sources; critical for proper package resolution during builds.
• .editorconfig — Code style and formatting standards enforced across the codebase; must be understood to maintain consistency.
• .github/CONTRIBUTING.md — Contribution guidelines and workflow for the project; required reading for all new contributors.

Add a New Material Design Control Demo

1. Create a new XAML file in src/MainDemo.Wpf/ named after your control (e.g., MyNewControl.xaml) with Grid layout and control examples. (src/MainDemo.Wpf/MyNewControl.xaml)
2. Create corresponding code-behind class inheriting from UserControl and add any event handlers. (src/MainDemo.Wpf/MyNewControl.xaml.cs)
3. Register the new demo item in MainWindowViewModel.cs by adding a DemoItem to the appropriate category with Name, Description, and content source. (src/MainDemo.Wpf/Domain/MainWindowViewModel.cs)
4. Add control styles to the Material Design theme XAML files if creating a new control type (use Material Design color scheme and elevation patterns). (src/MaterialDesignThemes.Wpf/Themes/Generic.xaml)

Add a New Color Palette or Theme Variant

1. Define new color resources in the Material Design Colors palette following Material Design 3 color specifications. (src/MaterialDesignColors.Wpf/ColorPalettes/MyPalette.xaml)
2. Create corresponding XAML resource dictionary in the theme library that applies the palette colors to all theme brushes. (src/MaterialDesignThemes.Wpf/Themes/MyTheme.xaml)
3. Register the new theme in App.xaml with a ResourceDictionary.MergedDictionaries entry for dynamic theme switching. (src/MainDemo.Wpf/App.xaml)
4. Add the new palette to PaletteSelectorViewModel.cs to make it selectable in the demo application. (src/MainDemo.Wpf/Domain/PaletteSelectorViewModel.cs)

Extend the Demo with a New Feature Tab

1. Create a new XAML UserControl in src/MainDemo.Wpf/ following the pattern of existing tabs (e.g., Buttons.xaml, Cards.xaml). (src/MainDemo.Wpf/MyFeatureTab.xaml)
2. Create a corresponding ViewModel class in Domain/ if the tab requires state management or data binding. (src/MainDemo.Wpf/Domain/MyFeatureViewModel.cs)
3. Register the feature in MainWindowViewModel.cs within the appropriate DemoItem category with documentation links. (src/MainDemo.Wpf/Domain/MainWindowViewModel.cs)
4. Update the tab navigation structure in App.xaml or the main window to include your new feature tab. (src/MainDemo.Wpf/App.xaml)

Build and Release a NuGet Package

1. Update version numbers in Directory.Build.props and verify all projects build without errors. (Directory.Build.props)
2. Run the build artifacts workflow in GitHub Actions or execute build/BuildNugets.ps1 locally to generate .nupkg files. (.github/workflows/build_artifacts.yml)
3. Verify package contents include all XAML resources, theme dictionaries, and compiled assemblies as expected. (nuget.config)
4. Trigger the release workflow which automatically publishes packages to NuGet.org with proper versioning and documentation. (.github/workflows/release.yml)

• WPF (Windows Presentation Foundation) — Platform for creating desktop applications with XAML-based UI; Microsoft's primary framework for rich Windows clients.
• XAML (Extensible Application Markup Language) — Declarative UI markup language enabling clean separation of design from code; ideal for implementing Material Design visual patterns.
• C# and VB.NET — Primary .NET languages for business logic, ViewModels, and code-behind; toolkit targets both language communities.
• Material Design 3 Specification — Google's modern design system providing cohesive color, typography, and component patterns applied consistently across WPF.
• NuGet Package Management — Standard .NET package distribution; toolkit published as MaterialDesignThemes and MaterialDesignColors for easy integration.
• GitHub Actions CI/CD — Automated build, test, and release workflows ensuring quality and consistency; handles NuGet publishing automatically.

• Single monolithic theme XAML dictionary over modular, plugin-based theme system

  • Why: Simplifies initial learning curve and guarantees consistent Material Design implementation across all controls.
  • Consequence: Customization requires forking or extensive ResourceDictionary overrides; less flexible for highly specialized enterprise theming.

• Demo-first architecture with heavy

  • Why: undefined
  • Consequence: undefined

XAML styling is strict: ApplyXamlStyler.ps1 must be run before commits (Settings.XamlStyler config is very particular about formatting). WPF requires proper thread affinity for UI updates—async/await patterns differ from async frameworks. Brush/Color palette system uses custom trigger logic; modifying theme colors requires understanding the brush hierarchy (MigrateBrushes.ps1 hints at breaking changes during theme migrations). Demo app (MahMaterialDragablzMashUp) has dependencies on external packages (Dragablz, MahApps)—ensure those versions match expectations in Directory.packages.props. Icon updates are automated (icon_update.yml)—manual changes to icon files may be overwritten.

• XAML Resource Dictionaries & Merged Dictionaries — The entire Material Design theme is delivered as nested XAML resource dictionaries that are merged at app startup; understanding dictionary scope and precedence is critical for custom theme extensions.
• WPF Attached Behaviors & Attached Properties — Material Design controls use attached properties for theme configuration (palette, contrast, animation) without requiring code-behind; essential pattern for non-intrusive customization.
• Style Inheritance & Template Triggers in WPF — The toolkit's Material Design styles are implemented via ControlTemplates with triggers (data triggers, multi-triggers) to handle states like hover, focus, disabled; mastering this pattern is required to modify or extend control styles.
• Color Palette & HSL/Material Design Color System — Material Design defines colors via hue, saturation, lightness + tonal variations (primary, secondary, tertiary, error); the toolkit implements runtime palette swapping (MigrateBrushes.ps1 hint) requiring understanding of this spec.
• Routed Events & Event Bubbling in WPF — Dialog, card, and button controls rely on routed events for user interaction; contributors must understand tunneling vs. bubbling to correctly handle nested control events.
• Transition/Storyboard Animations — The toolkit provides Material Design transition effects via XAML storyboards; the docs/ folder hints at rendering performance optimization, suggesting contributors must balance animation smoothness with CPU usage.
• NuGet Package Structure & Multi-Targeting — The dual-package strategy (MaterialDesignThemes vs. MaterialDesignColors) and Directory.packages.props suggest centralized versioning; understanding transitive dependency management and package separation is crucial for release processes.

• ButchersBoy/Dragablz — Companion library for tabbed UI; this repo has explicit integration (MahMaterialDragablzMashUp demo) and is listed in the README as compatible.
• MahApps/MahApps.Metro — Parallel WPF theming library; Material Design Toolkit is designed to coexist with MahApps for window chrome + content theming.
• materialdesignicons/materialdesignicons — Source of the Material Design Icons pack bundled in this toolkit; tracking changes ensures icon library stays current.
• google/material-design-icons — Official Material Design reference; this repo implements Google's design system for WPF, so understanding the spec is essential.
• MaterialDesignInXAML/MaterialDesignInXamlToolkit.Samples — Official sample applications and use-case demonstrations (if separate repo); users often reference samples for integration patterns.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive UI tests for Material Design control styles using XamlTest

The repo has a GitHub skill for XamlTest UI testing (.github/skills/xamltest-ui-tests/SKILL.md) and a control_styles.yml workflow, but there's no evidence of actual XamlTest test files in the src/ directory. This is critical for a UI toolkit where visual correctness matters. New contributors could create XamlTest test cases for core controls (Button, TextBox, Card, etc.) to ensure Material Design styles render correctly across different configurations.

• [ ] Review .github/skills/xamltest-ui-tests/SKILL.md to understand the testing framework
• [ ] Create src/Tests/XamlTests/ directory structure for control rendering tests
• [ ] Implement XamlTest cases for 3-5 core Material Design controls (e.g., MaterialButton, MaterialCard, MaterialTextBox)
• [ ] Update .github/workflows/control_styles.yml to run these new tests in CI
• [ ] Document test patterns in .github/CONTRIBUTING.md

Create integration tests for theme switching and brush customization

The repo has theme and brush documentation (docs/ folder) and build scripts for migrating themes (build/MigrateThemes.ps1, build/MigrateBrushes.ps1), but no visible test suite validating that themes apply correctly at runtime. A new contributor could create unit/integration tests ensuring theme switching, custom brush application, and palette updates work correctly—critical for a design toolkit.

• [ ] Create src/Tests/ThemeTests/ directory for theme integration tests
• [ ] Implement tests for loading and switching between Material Design themes
• [ ] Add tests for custom brush/color palette application using MaterialDesignColors package
• [ ] Test that theme changes propagate correctly to bound controls
• [ ] Integrate tests into pr_verification.yml workflow

Build API reference documentation generator from XAML markup extensions and attached behaviors

The toolkit exposes Material Design behaviors and custom markup extensions in XAML, but the README is incomplete (ends abruptly). A contributor could create a documentation generator that parses src/ XAML files and C# code to auto-generate markdown API reference docs for: attached properties, custom markup extensions, and control behaviors—making the toolkit more discoverable for WPF developers.

• [ ] Analyze src/ structure to identify XAML markup extensions and attached behavior classes
• [ ] Create a PowerShell/C# script in build/ (similar to GenerateThemesWikiMarkdown.ps1) to extract and document these APIs
• [ ] Generate markdown files in docs/ categorized by feature (e.g., docs/MarkupExtensions.md, docs/AttachedBehaviors.md)
• [ ] Add build script to generate_contributors.yml or create dedicated workflow
• [ ] Update README.md with links to generated API documentation

• Add XML documentation comments to public APIs in src/MahMaterialDragablzMashUp/AnotherCommandImplementation.cs and other core control classes—many appear to lack them, blocking API IntelliSense.
• Create a Getting Started guide for contributors in .github/ that explains the theme XAML structure and how to add custom Material Design colors (gaps visible: copilot-instructions.md exists but theme architecture docs are missing).
• Write integration tests for dialog and card controls using the XamlTest framework hinted at in .github/skills/xamltest-ui-tests/SKILL.md; currently no test files visible in top-60 list.

The Material Design In XAML Toolkit codebase demonstrates good security practices overall as a public open-source project. No critical vulnerabilities were identified in the visible structure. The main concerns are: 1) A strong name key file in the repository requiring verification of its purpose and access controls, 2) PowerShell build scripts that should have execution safeguards, and 3) GitHub Actions workflows that need detailed security auditing. Dependencies should be regularly scanned for vulnerabilities. The project follows good practices with Dependabot integration, CONTRIBUTING guidelines, and issue templates. Recommend implementing automated security scanning, dependency auditing, and formal code review policies for critical components.

• Medium · Signed Assembly Key in Repository — build/key.snk. The file 'build/key.snk' appears to be a strong name key file stored in the repository. While this is sometimes necessary for open-source projects, it should be reviewed to ensure it's not a production key and that access is properly controlled. Fix: Verify this is a development-only key. Consider using a separate production key stored in secure key management systems. Document the key's purpose and access controls.
• Low · Missing CODEOWNERS File — .github/. No CODEOWNERS file found in the .github directory. This file helps ensure code review by designated maintainers and prevents unauthorized changes to critical files. Fix: Create a CODEOWNERS file to define who must review changes to critical sections, particularly build scripts, configuration files, and security-related code.
• Low · PowerShell Build Scripts Without Execution Policy Guards — build/*.ps1 files (ApplyXamlStyler.ps1, BuildNugets.ps1, etc.). Multiple PowerShell scripts exist in the build directory (.ps1 files) that could be executed. Without proper execution controls, there's a risk of unauthorized script execution. Fix: Implement script signing, code review processes for all PowerShell scripts, and document execution requirements. Consider using script hashing in CI/CD pipelines.
• Low · Limited Visibility of Dependency Management — Directory.packages.props, nuget.config. While Directory.packages.props and nuget.config are present, the actual dependency versions and audit status cannot be fully assessed from the provided file structure. NuGet packages should be regularly audited. Fix: Implement automated dependency scanning using tools like NuGet package security audits, Snyk, or GitHub Dependabot. Review the nuget.config for any suspicious package sources.
• Low · GitHub Actions Workflow Security — .github/workflows/. Multiple GitHub Actions workflows are present but their detailed content cannot be reviewed. Workflows that trigger on pull requests or have elevated permissions need careful security review. Fix: Audit all workflows for: 1) Least privilege permissions, 2) Pinned action versions (avoid 'latest'), 3) Secret management, 4) Third-party action review. Enable branch protection rules.
• Low · Potential Stale Issue Management Risk — .github/workflows/stale_issues_and_prs.yml. A stale issues workflow exists which could potentially close security-related issues without proper review if misconfigured. Fix: Ensure the stale issues workflow has exemptions for security-labeled issues and high-priority bug reports. Review the workflow configuration to prevent premature closure of critical issues.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.