mvvm-toolkit — GitHub Copilot rule: what it does, how to install
Guides GitHub Copilot on CommunityToolkit.Mvvm 8.x conventions across WPF, WinUI 3, .NET MAUI, and Avalonia. Eliminates boilerplate for properties, commands, and validation.
.github/instructions/mvvm-toolkit.instructions.mdWhat mvvm-toolkit does
This instruction set activates for .cs, .xaml, and .csproj files. It enforces CommunityToolkit.Mvvm 8.x or newer and explicitly blocks the legacy Microsoft.Toolkit.Mvvm package. Classes utilizing [ObservableProperty] must remain partial. The attribute attaches exclusively to lowerCamelCase private fields, letting source generators emit the public properties.
Methods use [RelayCommand] and must return void or Task. Returning async void is prohibited because exceptions turn unobserved. Asynchronous handlers should accept a CancellationToken to support cancellation. Without C# source generator support in your compiler SDK, the toolkit attributes will not generate code.
Dependency injection stays clean by requiring constructor injection over Ioc.Default.GetService<T>(). For messaging, the rule defaults to WeakReferenceMessenger with static lambdas to prevent closure leaks. When forms require validation, ViewModels inherit from ObservableValidator and run ValidateAllProperties() prior to submission.
What it helps with
- generate reactive properties via
[ObservableProperty]without boilerplate - configure async commands with cancellation tokens using
[RelayCommand] - decouple ViewModel communication with
WeakReferenceMessenger - validate form inputs across XAML platforms with
ObservableValidator
Example prompts for the agent
- Create an edit profile ViewModel with input validation via ObservableValidator
- Add an async save command with a CancellationToken and cancellation support
- Set up message handling with WeakReferenceMessenger to broadcast item selection
How to install mvvm-toolkit
Manually: put the files in place
.github/instructions/mvvm-toolkit.instructions.mdThe applyTo field sets which files it applies to
Manually: put the files in place
.claude/rules/mvvm-toolkit.mdThe paths frontmatter field limits the files: move applyTo from the source into paths
AGENTS.md
Codex reads AGENTS.md: paste the rule text there
Manually: put the files in place
.cursor/rules/mvvm-toolkit.mdcFrontmatter: description, globs, alwaysApply. Move applyTo from the source into globs, or the rule will not attach on its own
Manually: put the files in place
.devin/rules/mvvm-toolkit.mdManually: put the files in place
.clinerules/mvvm-toolkit.mdStep by step, with commands for each platform: AGENTS.md vs CLAUDE.md: what they are and which one to use
Questions about mvvm-toolkit
How to install mvvm-toolkit in GitHub Copilot?
Create a .github/instructions/mvvm-toolkit.instructions.md file in your repository root and paste the rule content into it.
What does the mvvm-toolkit rule do?
It configures GitHub Copilot to write correct C# code with CommunityToolkit.Mvvm 8.x or newer. The assistant follows strict patterns for source generators, commands, messaging, and dependency injection.
Can a ViewModel inherit from both ObservableValidator and ObservableRecipient?
No, C# does not allow multiple class inheritance. The rule instructs you to choose one base class and resolve the other via composition, such as injecting IMessenger into the constructor.
Source text
mvvm-toolkit.instructions.md · MIT
---
description: 'CommunityToolkit.Mvvm (MVVM Toolkit) coding conventions for ViewModels, commands, messaging, validation, and DI across WPF, WinUI 3, .NET MAUI, Uno Platform, and Avalonia.'
applyTo: '**/*.cs, **/*.xaml, **/*.csproj'
---
# CommunityToolkit.Mvvm (MVVM Toolkit)
These rules apply whenever a project references `CommunityToolkit.Mvvm`.
For deep reference and end-to-end examples, load the `mvvm-toolkit` skill.
## Package & language
- Reference `CommunityToolkit.Mvvm` 8.x (or newer) in `.csproj`. Do not
install the legacy `Microsoft.Toolkit.Mvvm` (7.x) for new projects.
- C# `LangVersion` must support source generators (default in modern SDKs).
## ViewModel base class
- Inherit ViewModels from `ObservableObject` by default.
- Use `ObservableValidator` only when the ViewModel needs
`INotifyDataErrorInfo` (forms, settings, input validation).
- Use `ObservableRecipient` only when the ViewModel sends or receives
`IMessenger` messages.
- Never hand-implement `INotifyPropertyChanged` when one of the toolkit
base classes can be used. If the type cannot inherit from a toolkit base
(e.g., a custom control), apply the class-level `[ObservableObject]` or
`[INotifyPropertyChanged]` attribute instead.
## Properties
- Declare every type that uses `[ObservableProperty]` as `partial` (and
every enclosing type, if nested).
- Apply `[ObservableProperty]` to private fields named `name`, `_name`, or
`m_name` — never PascalCase. Let the generator emit the public property.
- Do not write manual `SetProperty(ref field, value)` boilerplate when the
field qualifies for `[ObservableProperty]`.
- Use `[NotifyPropertyChangedFor(nameof(Derived))]` to raise change
notifications for derived/computed properties.
- Use `[NotifyCanExecuteChangedFor(nameof(XxxCommand))]` so commands
re-evaluate `CanExecute` when their inputs change.
- Implement `OnXxxChanging` / `OnXxxChanged` partial-method hooks for
side-effects on property changes — do not subscribe to your own
`PropertyChanged` event.
- Use `[property: SomeAttribute]` to forward an attribute (e.g.,
`[JsonIgnore]`, `[JsonPropertyName(...)]`) onto the generated property.
## Commands
- Use `[RelayCommand]` on instance methods over manually constructed
`RelayCommand` / `AsyncRelayCommand` instances.
- `[RelayCommand]` methods must return `void` or `Task` (or `Task<T>`).
Never use `async void` — exceptions become unobserved.
- For cancellable async work, declare a `CancellationToken` parameter and
optionally set `IncludeCancelCommand = true` to expose a paired
`XxxCancelCommand`.
- Use `CanExecute = nameof(...)` plus `[NotifyCanExecuteChangedFor]` on the
inputs to keep button enable/disable state in sync.
- Default `AllowConcurrentExecutions` to `false` (the default). Only set
`true` when overlapping invocations are explicitly safe and intended.
- Default error policy is await-and-rethrow. Only set
`FlowExceptionsToTaskScheduler = true` when the UI binds to
`ExecutionTask` to render error states.
## Messaging
- Default to `WeakReferenceMessenger.Default`. Only switch to
`StrongReferenceMessenger.Default` when profiling shows the messenger is
hot, and document the lifetime guarantees.
- Register handlers with the `(recipient, message)` lambda form using the
`static` modifier — never capture `this` in the lambda.
- Prefer `IRecipient<TMessage>` interfaces on `ObservableRecipient`
ViewModels so `RegisterAll(this)` wires everything automatically when
`IsActive = true`.
- Set `IsActive = true` on activation (e.g., `OnNavigatedTo`) and
`IsActive = false` on deactivation (e.g., `OnNavigatedFrom`).
- Inheritance is not considered when delivering messages — register each
concrete message type explicitly.
- Use channel tokens (the `int` / `string` / `Guid` overloads) to scope
messages to a sub-system or window when more than one consumer would
otherwise collide.
## Dependency injection
- Use `Microsoft.Extensions.DependencyInjection` for service and ViewModel
registration. Prefer the .NET Generic Host
(`Host.CreateDefaultBuilder()`) so configuration, logging, and scope
validation are wired automatically.
- Register services and ViewModels in the composition root (typically
`App.xaml.cs`). Resolve the page's root ViewModel from DI in the page
constructor or via the navigation framework.
- Inject services and child ViewModels through constructors. Do not call
`Ioc.Default.GetService<T>()` from inside ViewModels, services, or any
type the DI container can construct.
- Lifetimes:
- `AddSingleton<T>()` — shell/main-window VMs, settings, file/HTTP
services, the shared `IMessenger`.
- `AddTransient<T>()` — per-page or per-document VMs.
- `AddScoped<T>()` — only with explicit `IServiceScope` usage; rarely
needed in client apps.
- Register `IMessenger` once
(`services.AddSingleton<IMessenger>(WeakReferenceMessenger.Default)`)
and inject it via `ObservableRecipient(messenger)` constructors.
## Validation
- Use `ObservableValidator` plus `[NotifyDataErrorInfo]` and DataAnnotation
attributes (`[Required]`, `[Range]`, `[EmailAddress]`, `[MinLength]`,
`[MaxLength]`, `[CustomValidation]`).
- Call `ValidateAllProperties()` before submitting a form; check
`HasErrors` and bail out if `true`.
- Reset error state with `ClearAllErrors()` after a successful submit or
when resetting a form.
- For cross-property rules, call `ValidateProperty(value, nameof(Other))`
from the changed property's `OnXxxChanged` hook.
## XAML
- For WinUI 3 / UWP, prefer `{x:Bind}` (compiled bindings) over
`{Binding}`. Set `Mode=OneWay` or `Mode=TwoWay` explicitly — `{x:Bind}`
defaults to `OneTime`.
- Bind `Command="{x:Bind ViewModel.SaveCommand}"` directly to the
generated command property.
- Bind async-command status (`IsRunning`, `ExecutionTask.Status`,
`ExecutionTask.Exception`) to surface progress/errors instead of
blocking the UI thread.
## Things to avoid
- `[ObservableProperty] private string Name;` — PascalCase field collides
with the generated property; use lowerCamel.
- Manual `RaisePropertyChanged(nameof(X))` calls alongside
`[ObservableProperty]` — produces duplicate notifications.
- `Ioc.Default.GetService<T>()` from inside a ViewModel constructor —
hides dependencies, breaks unit tests.
- `StrongReferenceMessenger` without `OnDeactivated` / `UnregisterAll` —
pins recipients and leaks them.
- Capturing `this` in messenger lambdas — closure allocation and
lifetime confusion. Always use `(r, m) => r.OnX(m)` with `static`.
- `async void` on `[RelayCommand]` methods — return `Task` instead.
- Mutating the same reference held by an `[ObservableProperty]` field —
the equality comparer returns `true` and no change notification fires.
Replace the instance instead.
- Inheriting from both `ObservableValidator` and `ObservableRecipient` —
not possible; use composition (inject `IMessenger` or implement
validation manually).
© github · MIT · github/awesome-copilot