From wpf-dev-pack
Generates WPF service interface, implementation class, and DI registration in .NET solutions. Detects project structure for file placement (.Abstractions, .Core, .WpfServices). Supports CommunityToolkit.Mvvm/Prism. Usage: /wpf-dev-pack:make-wpf-service <ServiceName> [--no-interface].
How this skill is triggered — by the user, by Claude, or both
Slash command
/wpf-dev-pack:make-wpf-servicesonnetThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**If `$0` is empty, use the AskUserQuestion tool to ask: "Enter the Service name (e.g., DataExport, FileManager)". Do NOT proceed until a valid name is provided. Use the response as the ServiceName for all subsequent steps.**
If $0 is empty, use the AskUserQuestion tool to ask: "Enter the Service name (e.g., DataExport, FileManager)". Do NOT proceed until a valid name is provided. Use the response as the ServiceName for all subsequent steps.
Generate a $0Service with interface + implementation class + DI registration.
Automatically places files in the correct project based on solution structure.
If --no-interface is appended, skip interface generation.
{Namespace} with the project's root namespace detected from csproj or existing code.# Interface + Implementation + DI registration
/wpf-dev-pack:make-wpf-service DataExport
# Implementation only (no interface) — for simple services
/wpf-dev-pack:make-wpf-service FileManager --no-interface
$0 is the service name (without Service suffix — auto-appended)
DataExport → IDataExportService.cs + DataExportService.cs--no-interface flag: Skip interface generation (class-only)Search for solution file and identify projects by naming convention:
| Project Suffix | Purpose | Files Placed |
|---|---|---|
.Abstractions | Interfaces | I$0Service.cs |
.Core | Business logic | $0Service.cs (UI-independent) |
.WpfServices | WPF-dependent services | $0Service.cs (if needs WPF types) |
.WpfApp | Application | DI registration in App.xaml.cs |
Fallback rules:
.Abstractions project → place interface in Services/ folder of main project.Core or .WpfServices → place implementation in Services/ folder of main projectServices/ folderCreate I$0Service.cs:
namespace {Namespace}.Services;
public interface I$0Service
{
// TODO: Define service contract
// TODO: 서비스 계약 정의
}
Create $0Service.cs:
namespace {Namespace}.Services;
public sealed class $0Service : I$0Service
{
// TODO: Implement service
// TODO: 서비스 구현
}
If --no-interface:
namespace {Namespace}.Services;
public sealed class $0Service
{
// TODO: Implement service
// TODO: 서비스 구현
}
Locate App.xaml.cs and add in ConfigureServices:
// With interface
services.AddSingleton<I$0Service, $0Service>();
// Without interface (--no-interface)
services.AddSingleton<$0Service>();
Locate App.xaml.cs and add in RegisterTypes:
// With interface
containerRegistry.RegisterSingleton<I$0Service, $0Service>();
// Without interface (--no-interface)
containerRegistry.RegisterSingleton<$0Service>();
Output list of generated/modified files and next steps guidance.
{AbstractionsProject}/
└── Services/
└── I$0Service.cs
{CoreProject}/
└── Services/
└── $0Service.cs
{WpfAppProject}/
└── App.xaml.cs (DI registration added)
{CoreProject}/
└── Services/
└── $0Service.cs
{WpfAppProject}/
└── App.xaml.cs (DI registration added)
/wpf-dev-pack:make-wpf-project firstnpx claudepluginhub christian289/dotnet-with-claudecode --plugin wpf-dev-packScaffolds WPF project structures with MVVM, DI, and best practices using CommunityToolkit.Mvvm (default) or Prism. Use for new WPF apps, scratch solutions, or setups via /wpf-dev-pack:make-wpf-project.
Covers .NET dependency injection patterns: service lifetimes, keyed services, decorator pattern, and common pitfalls. Useful when registering services or resolving lifetime issues.
Builds and runs WinUI 3 apps with project creation, package installation, and error diagnosis. Use when building, running, or fixing build errors in a WinUI 3 project.