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/MahApps/MahApps.Metro 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 all four use cases

• Last commit 3w ago
• 9 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 87% of recent commits

_{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 MahApps/MahApps.Metro repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/MahApps/MahApps.Metro.

What it runs against: a local clone of MahApps/MahApps.Metro — 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 MahApps/MahApps.Metro | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch develop exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 54 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of MahApps/MahApps.Metro. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/MahApps/MahApps.Metro.git
#   cd MahApps.Metro
#
# 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 MahApps/MahApps.Metro and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "MahApps/MahApps.Metro(\\.git)?\\b" \\
  && ok "origin remote is MahApps/MahApps.Metro" \\
  || miss "origin remote is not MahApps/MahApps.Metro (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 develop >/dev/null 2>&1 \\
  && ok "default branch develop exists" \\
  || miss "default branch develop no longer exists"

# 4. Critical files exist
test -f "src/Directory.Build.Props" \\
  && ok "src/Directory.Build.Props" \\
  || miss "missing critical file: src/Directory.Build.Props"
test -f "src/Directory.packages.props" \\
  && ok "src/Directory.packages.props" \\
  || miss "missing critical file: src/Directory.packages.props"
test -f "build.cake" \\
  && ok "build.cake" \\
  || miss "missing critical file: build.cake"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"
test -f "src/MahApps.Metro.Samples/MahApps.Metro.Demo/App.xaml" \\
  && ok "src/MahApps.Metro.Samples/MahApps.Metro.Demo/App.xaml" \\
  || miss "missing critical file: src/MahApps.Metro.Samples/MahApps.Metro.Demo/App.xaml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 54 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~24d)"
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/MahApps/MahApps.Metro"
  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).

MahApps.Metro is a WPF toolkit providing modern, Metro-style UI controls and theming for .NET applications (supporting .NET Framework 4.6.2+, .NET Core 3.1, .NET 5, and .NET 6 on Windows). It enables developers to build polished Windows desktop applications with Material Design–inspired controls without building UI components from scratch. Monorepo structure: /src/MahApps.Metro contains the core toolkit with XAML themes and controls; /src/MahApps.Metro.Samples includes multiple demo projects (e.g., Caliburn.Micro integration at src/MahApps.Metro.Samples/MahApps.Metro.Caliburn.Demo/). Theme resources are centralized (logo.xaml, XAML StyleSettings), and templates are packaged separately (Visual Studio Templates/Templates.zip).

WPF developers building Windows desktop applications who want modern, pre-built UI controls and consistent theming out-of-the-box, without investing time in custom control development or design systems.

Production-ready and actively maintained. The project uses professional CI/CD (AppVeyor), semantic versioning (GitVersion.yml), and has multi-year longevity with recent development activity. Supports multiple .NET versions and ships as a NuGet package with substantial downloads.

Low risk overall, but watch for: WPF is a mature but aging Microsoft platform with declining investment; the project appears to have a small core team (primary maintainer visible in CI configs: punker76); .NET Framework support is legacy and constrains modernization. No obvious security concerns from the structure shown.

Unable to determine from the file snapshot provided—no recent commit timestamps, branch activity, or open PR counts are visible. Check the GitHub Actions workflow (.github/workflows/ci.yml) and AppVeyor CI status badges in the README for current build/release activity.

git clone https://github.com/MahApps/MahApps.Metro.git && cd MahApps.Metro && dotnet restore src/ && dotnet build src/MahApps.Metro/ (uses Cake build system via build.ps1 for advanced scenarios).

Daily commands: Debug: Open src/MahApps.Metro.sln in Visual Studio, build the core library, then run a sample project from src/MahApps.Metro.Samples/. Command line: ./build.ps1 (PowerShell, Windows-only) or dotnet build src/ for a quick build.

• src/Directory.Build.Props — Centralized project configuration and property definitions that apply to all compiled assemblies in the solution.
• src/Directory.packages.props — Central NuGet package version management for all projects, ensuring consistent dependency versions across the codebase.
• build.cake — Cake build script that orchestrates compilation, testing, and packaging; critical for understanding the build pipeline.
• .github/workflows/ci.yml — GitHub Actions CI/CD pipeline definition that validates all pull requests and controls release automation.
• src/MahApps.Metro.Samples/MahApps.Metro.Demo/App.xaml — Primary demo application entry point showing how to integrate and use MahApps.Metro theming and controls.
• GitVersion.yml — Semantic versioning configuration that automates version assignment based on git history and branch strategy.

Add a new themed UI control example

1. Create a new XAML view file under ExampleViews/ folder (src/MahApps.Metro.Samples/MahApps.Metro.Demo/ExampleViews/NewControlExample.xaml)
2. Create the code-behind file following the existing pattern (e.g., ButtonsExample.xaml.cs) (src/MahApps.Metro.Samples/MahApps.Metro.Demo/ExampleViews/NewControlExample.xaml.cs)
3. Reference the new example view in the main App.xaml or navigation structure (src/MahApps.Metro.Samples/MahApps.Metro.Demo/App.xaml)

Add a new custom behavior

1. Create a new behavior class in the Behaviors folder inheriting from Behavior<T> (src/MahApps.Metro.Samples/MahApps.Metro.Demo/Behaviors/YourNewBehavior.cs)
2. Use the behavior in XAML by attaching it to a control using the i:Interaction.Behaviors collection (src/MahApps.Metro.Samples/MahApps.Metro.Demo/ExampleViews/ButtonsExample.xaml)

Create a new sample with Caliburn.Micro integration

1. Create a ViewModel class in ViewModels/ folder following Caliburn conventions (src/MahApps.Metro.Samples/MahApps.Metro.Caliburn.Demo/ViewModels/YourFeatureViewModel.cs)
2. Create a corresponding View.xaml in Views/ folder with matching namespace convention (src/MahApps.Metro.Samples/MahApps.Metro.Caliburn.Demo/Views/YourFeatureView.xaml)
3. Register the ViewModel/View in the AppBootstrapper's Configure method (src/MahApps.Metro.Samples/MahApps.Metro.Caliburn.Demo/AppBootstrapper.cs)

Customize theme colors

1. Create or edit a theme XAML resource file in the Resources folder (src/MahApps.Metro.Samples/MahApps.Metro.Caliburn.Demo/Resources/Theme1.xaml)
2. Define color brushes and control templates following Metro design patterns (src/MahApps.Metro.Samples/MahApps.Metro.Caliburn.Demo/Resources/Theme1.xaml)
3. Load the theme in App.xaml using ResourceDictionary merging (src/MahApps.Metro.Samples/MahApps.Metro.Caliburn.Demo/App.xaml)

• WPF (Windows Presentation Foundation) — Cross-version Windows desktop UI framework with XAML support; enables rich theming and control styling
• .NET Framework 4.6.2+, .NET Core 3.1, .NET 5, .NET 6 — Supports both legacy enterprise environments and modern .NET while maintaining backward compatibility
• XAML (eXtensible Application Markup Language) — Declarative UI markup enables separation of design (themes/resources) from application logic
• Caliburn.Micro (optional MVVM framework) — Lightweight MVVM toolkit for view/viewmodel composition and action binding in the demo
• Cake (C# Make) — Cross-platform build automation in C# for compilation, testing, and NuGet packaging
• GitHub Actions — CI/CD automation for PR validation and automated release management

• WPF-only targeting (Windows desktop only)

  • Why: WPF is the native Windows UI framework with the richest theming capabilities
  • Consequence: Cannot target mobile, web, or non-Windows platforms; limits audience but ensures deep OS integration

• Multiple .NET versions in single codebase

  • Why: Supports both .NET Framework legacy codebases and modern .NET runtimes
  • Consequence: Build complexity increases; must avoid APIs unavailable in older frameworks

• Centralized package versioning via Directory.packages.props

  • Why: Prevents dependency version conflicts across 600+ files
  • Consequence: Requires discipline when adding packages; version bumps affect entire solution

• Theming via XAML ResourceDictionaries rather than runtime theme engine

  • Why: XAML-native approach leverages WPF's declarative strengths
  • Consequence: Theme changes typically require app restart; less dynamic than UI frameworks with runtime theme APIs

• Does not support Linux, macOS, or non-Windows platforms
• Does not provide cross-platform UI framework (WPF is Windows-only)
• Does not implement web/mobile UI targets
• Does not provide built-in authentication or security infrastructure
• Does not handle real-time synchronization or networking (application responsibility)

Platform constraint: WPF is Windows-only; no macOS or Linux support. Build tooling: build.ps1 is PowerShell and requires Windows + PowerShell; cross-platform builds use dotnet directly but may have undocumented framework-specific nuances. Theme binding: XAML themes are tightly coupled to WPF's resource dictionary system—changes to theme structure can break downstream applications silently if not version-bumped carefully. No explicit dependency lock file: src/Directory.packages.props centralizes NuGet versions, but ensure it's updated when adding new dependencies across projects.

• XAML Resource Dictionaries — MahApps.Metro's entire theming system (colors, brushes, control templates) is built on merged XAML resource dictionaries; understanding how WPF resolves and inherits resources is critical for customizing or extending themes.
• WPF Control Templating — All Metro controls are defined as templates applied via ControlTemplate; modifying or creating new controls requires familiarity with XAML template syntax, attached properties, and template binding.
• Semantic Versioning via GitVersion — The project uses GitVersion (GitVersion.yml config) to automatically calculate version numbers from git commit history and branch names; understanding SemVer and GitFlow conventions is essential for release management.
• Attached Behaviors — WPF uses attached behaviors (AttachedBehavior pattern) to extend control functionality without subclassing; MahApps examples like Controls/IThemeManager.cs show this pattern for dynamic theme switching.
• Cake Build Automation — The project uses Cake (C# build DSL in build.cake) for cross-platform build orchestration; contributors must understand Cake tasks for building, testing, and packaging.
• Multi-Targeting (.NET Framework + Core + 5+) — MahApps.Metro supports .NET Framework 4.6.2, .NET Core 3.1, and .NET 5/6 via src/Directory.Build.Props; maintainers must test across all targets and handle framework-specific APIs carefully.
• GitFlow & Branch Protection — CI configs (AppVeyor, GitHub Actions) enforce different workflows for main vs develop branches; contributors must understand the feature-branch → develop → main release flow visible in the CI badges.

• MaterialDesignInXamlToolkit/MaterialDesignInXamlToolkit — Direct competitor providing Material Design controls for WPF with similar goals but separate theme/styling approach.
• HandyOrg/HandyControl — Alternative WPF control library offering modern UI components with theming, targets similar developer audience.
• Caliburn-Micro/Caliburn.Micro — MVVM framework tightly integrated via the Caliburn demo sample; many MahApps users pair it with Caliburn for application architecture.
• jamesmontemagno/mvvm-helpers — Lightweight MVVM utilities frequently used alongside MahApps in WPF projects for data binding and command handling.
• punker76/MahApps.Metro.SimpleChildWindow — Official companion library by the lead maintainer providing enhanced child window controls for MahApps-themed applications.

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 unit tests for MahApps.Metro.Caliburn.Demo sample application

The Caliburn.Micro demo sample (src/MahApps.Metro.Samples/MahApps.Metro.Caliburn.Demo) lacks unit tests for its custom controls, services, and ViewModels. This is valuable because: (1) it serves as a reference implementation for users, (2) it demonstrates best practices for testing MahApps + Caliburn.Micro integration, (3) it validates that the ThemeManager, ViewLocator, and ServiceLocator implementations work correctly. A test project would help contributors understand the framework's extensibility patterns.

• [ ] Create src/MahApps.Metro.Samples/MahApps.Metro.Caliburn.Demo.Tests/.csproj file
• [ ] Add unit tests for src/MahApps.Metro.Samples/MahApps.Metro.Caliburn.Demo/Controls/ThemeManager.cs
• [ ] Add unit tests for src/MahApps.Metro.Samples/MahApps.Metro.Caliburn.Demo/Services/MefServiceLocator.cs
• [ ] Add unit tests for ViewModels in src/MahApps.Metro.Samples/MahApps.Metro.Caliburn.Demo/ViewModels/
• [ ] Update build.cake to include the new test project in CI pipeline

Create a .NET 7 and .NET 8 compatibility CI workflow and update supported versions documentation

The README currently states support for '.NET Framework 4.6.2, .NET Core 3.1, .NET 5 and .NET 6' but .NET 7 and .NET 8 are now stable LTS/current releases. The existing .github/workflows/ci.yml likely doesn't test these versions. This PR would: (1) add matrix builds for .NET 7 and .NET 8 in the CI workflow, (2) verify all samples build and run on newer TFMs, (3) update README.md and GitVersion.yml to reflect current support matrix. High value because it keeps the framework modern and prevents breaking changes from going undetected.

• [ ] Update .github/workflows/ci.yml to add .NET 7 and .NET 8 to the build matrix (find the existing dotnet-version array)
• [ ] Update README.md supported frameworks section
• [ ] Update global.json if needed to specify which .NET SDK versions to use locally
• [ ] Verify src/Directory.Build.Props and src/Directory.packages.props have compatible versions for newer TFMs
• [ ] Test that MahApps.Metro.Caliburn.Demo sample builds successfully on .NET 7 and .NET 8

Add missing contributor documentation for extending MahApps.Metro theming system

The repo has .github/CONTRIBUTING.md but lacks specific technical documentation about how to create custom themes or extend the theming system. Evidence: src/MahApps.Metro.Samples/MahApps.Metro.Caliburn.Demo/Resources/Theme1.xaml exists but there's no documented pattern for this. Creating a XAML-focused developer guide would help contributors understand: (1) the color/brush naming conventions used by MahApps, (2) how to properly extend AccentColor and ThemeColor, (3) how Theme1.xaml in the sample integrates with the ThemeManager. This reduces friction for theme contributions and customization PRs.

• [ ] Create docs/THEMING_GUIDE.md with explanation of MahApps theme architecture
• [ ] Document the color/brush naming conventions by analyzing src/MahApps.Metro/Resources/ XAML files
• [ ] Add example showing how to create a custom theme extending the Caliburn demo's Theme1.xaml pattern
• [ ] Document the relationship between ThemeManager.cs and XAML theme resources
• [ ] Link the new guide from .github/CONTRIBUTING.md in a 'Theming' section

• Add unit tests for controls in /src/MahApps.Metro/Controls/ that currently lack dedicated test coverage—start with a simple control like Button or TextBox wrapper and create tests in a new /src/MahApps.Metro.Tests/ project following xUnit conventions (visible in Directory.Build.Props setup).
• Create documentation for the Caliburn.Micro sample at /src/MahApps.Metro.Samples/MahApps.Metro.Caliburn.Demo/—the IThemeManager.cs and IViewLocator.cs interfaces have no inline XML docs; add /// summary tags and reference the wiki from the README.
• Expand the theme customization examples in /docs/ with a markdown guide showing how to override colors in a derived theme—the repo has theme XAML files but no step-by-step tutorial for creating custom themes matching brand colors.

MahApps.Metro demonstrates reasonable security practices as an open-source UI framework project. Key findings: (1) Dependency analysis cannot be completed without package file contents—this is the primary gap requiring immediate attention. (2) Build automation files are present but appear properly structured for CI/CD. (3) WPF/XAML-based applications require careful handling of deserialization, particularly with untrusted sources. (4) No explicit security policy or vulnerability reporting mechanism is documented. The codebase structure suggests good separation of concerns (samples, core library), but actual code review would be needed to assess for injection vulnerabilities, unsafe WPF bindings, or other runtime security issues. Recommend implementing automated dependency scanning via GitHub Dependabot and establishing a security.md policy.

• Medium · Missing Dependency Vulnerability Information — src/Directory.packages.props, NuGet.Config, *.csproj files. The dependency file content was not provided for analysis. Cannot assess for known vulnerable packages or outdated versions that may contain CVEs. Fix: Provide package dependency files for analysis. Use 'dotnet list package --vulnerable' to check for known vulnerabilities. Consider using GitHub Dependabot or OWASP Dependency-Check for continuous monitoring.
• Low · Build Configuration Exposure — build.cake, build.ps1, appveyor.yml. Build scripts and configuration files (build.cake, build.ps1, appveyor.yml) are present in the repository. These may contain sensitive build environment information or tokens if not properly configured. Fix: Ensure no secrets are hardcoded in build scripts. Use secure environment variables for CI/CD pipelines. Regularly audit build configuration files for sensitive data.
• Low · Missing Security Policy Documentation — Repository root. No SECURITY.md or security policy file was identified in the repository structure. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: Create a SECURITY.md file at the repository root with instructions for reporting security vulnerabilities privately (e.g., GitHub Security Advisory feature).
• Low · Potential Insecure Deserialization Risk — src/MahApps.Metro.Samples (XAML files throughout). WPF applications commonly use XAML deserialization. If untrusted XAML is processed, it could lead to code execution vulnerabilities (similar to ObjectDataProvider attacks). Fix: Validate and sanitize all XAML sources. Avoid loading XAML from untrusted sources. Use XamlReader.Load with appropriate sandboxing. Implement input validation for dynamic XAML content.
• Low · No License Verification Mechanism — LICENSE, NuGet.Config. The project is distributed as a NuGet package without apparent license verification or digital signing documentation visible in the file structure. Fix: Ensure NuGet packages are signed and published from verified sources. Document the license (MIT appears to be used) clearly. Consider implementing package integrity verification.

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.