/wcf
Work on WCF services, clients, bindings, contracts, and migration decisions for SOAP and multi-transport service-oriented systems on .NET Framework or compatible stacks. USE FOR: working on WCF services, bindings, or clients; deciding whether a service should stay WCF or move to
$ npx -y skills add managedcode/dotnet-skills --skill wcf --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/wcf
Context preview
The summary Claude sees to decide when to auto-load this skill.
Work on WCF services, clients, bindings, contracts, and migration decisions for SOAP and multi-transport service-oriented systems on .NET Framework or compatible stacks. USE FOR: working on WCF services, bindings, or clients; deciding whether a service should stay WCF or move to
SKILL.md
wcf.SKILL.mdname: wcf
description: "Work on WCF services, clients, bindings, contracts, and migration decisions for SOAP and multi-transport service-oriented systems on .NET Framework or compatible stacks. USE FOR: working on WCF services, bindings, or clients; deciding whether a service should stay WCF or move to modern HTTP APIs; reviewing transport, security, or interoperability. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made."
compatibility: "Requires WCF or a concrete migration off WCF."
Windows Communication Foundation
Trigger On
- working on WCF services, bindings, or clients
- deciding whether a service should stay WCF or move to modern HTTP APIs
- reviewing transport, security, or interoperability settings
Workflow
1. Use WCF where SOAP, WS-* features, or multi-transport service requirements are real; do not rewrite those needs into HTTP-only guidance by accident. 2. Keep contracts, bindings, behaviors, and hosting configuration explicit because WCF complexity compounds through configuration indirection. 3. For new REST-style services, prefer modern ASP.NET Core APIs instead of extending WCF into a shape it is no longer best suited for. 4. Plan migrations per endpoint and capability: transport, security model, transaction requirements, metadata, and client compatibility. 5. Validate interoperability and deployment assumptions with the actual client ecosystem, not only local service startup. 6. When WCF coexists with ASP.NET, be explicit about which runtime behaviors are shared and which are not.
Deliver
- stable WCF service or client configuration
- realistic migration guidance to newer stacks where appropriate
- clear contract and binding ownership
Validate
- WCF is used for a reason the modern stack does not replace directly
- binding and security behavior are explicit
- interop is verified with real consumers
References
- [migration.md](references/migration.md) - WCF to gRPC/REST/CoreWCF migration paths, decision framework, and endpoint-by-endpoint migration strategy
- [patterns.md](references/patterns.md) - WCF maintenance patterns for configuration, contracts, hosting, security, diagnostics, and client proxy management
Read more
name: wcf description: "Work on WCF services, clients, bindings, contracts, and migration decisions for SOAP and multi-transport service-oriented systems on .NET Framework or compatible stacks. USE FOR: working on WCF services, bindings, or clients; deciding whether a service should stay WCF or move to modern HTTP APIs; reviewing transport, security, or interoperability. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made." compatibility: "Requires WCF or a concrete migration off WCF."
Windows Communication Foundation
Trigger On
- working on WCF services, bindings, or clients
- deciding whether a service should stay WCF or move to modern HTTP APIs
- reviewing transport, security, or interoperability settings
Workflow
1. Use WCF where SOAP, WS-* features, or multi-transport service requirements are real; do not rewrite those needs into HTTP-only guidance by accident. 2. Keep contracts, bindings, behaviors, and hosting configuration explicit because WCF complexity compounds through configuration indirection. 3. For new REST-style services, prefer modern ASP.NET Core APIs instead of extending WCF into a shape it is no longer best suited for. 4. Plan migrations per endpoint and capability: transport, security model, transaction requirements, metadata, and client compatibility. 5. Validate interoperability and deployment assumptions with the actual client ecosystem, not only local service startup. 6. When WCF coexists with ASP.NET, be explicit about which runtime behaviors are shared and which are not.
Deliver
- stable WCF service or client configuration
- realistic migration guidance to newer stacks where appropriate
- clear contract and binding ownership
Validate
- WCF is used for a reason the modern stack does not replace directly
- binding and security behavior are explicit
- interop is verified with real consumers
References
- [migration.md](references/migration.md) - WCF to gRPC/REST/CoreWCF migration paths, decision framework, and endpoint-by-endpoint migration strategy
- [patterns.md](references/patterns.md) - WCF maintenance patterns for configuration, contracts, hosting, security, diagnostics, and client proxy management
Stop explaining .NET to your AI. Start building. We've all been there: asking Claude to use Entity Framework, only to get EF6 patterns in a .NET 8 project. Explaining to Copilot that Blazor Server and Blazor WebAssembly aren't the same thing.
Repo: managedcode/dotnet-skills
Other skills on dotnet-skills.
- /aspnet-core
Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging, and deployment patterns on current .NET. USE FOR: working on ASP.NET Core apps, services, or middleware; changing auth, routing, configuration,
Open skill - /aspire
Build, upgrade, and operate Aspire 13.4.x C# or TypeScript application hosts with the current CLI, AppHost, ServiceDefaults, integrations, dashboard, testing, MCP, and deployment patterns for distributed apps. USE FOR: Aspire.AppHost.Sdk, Aspire.Hosting.*,
Open skill - /azure-functions
Build, review, or migrate Azure Functions in .NET with correct execution model, isolated worker setup, bindings, DI, and Durable Functions patterns. USE FOR: working on Azure Functions in .NET; migrating from the in-process model to the isolated worker model; adding Durable
Open skill - /blazor
Build and review Blazor applications across server, WebAssembly, web app, and hybrid scenarios with correct component design, state flow, rendering, and hosting choices. USE FOR: building interactive web UIs with C# instead of JavaScript; choosing between Server, WebAssembly, or
Open skill - /entity-framework6
Maintain or migrate EF6-based applications with realistic guidance on what to keep, what to modernize, and when EF Core is or is not the right next step. USE FOR: EF6 codebases; runtime versus ORM migration decisions; EDMX, code-first, ObjectContext, and legacy data-access
Open skill - /entity-framework-core
Design, tune, or review EF Core data access with proper modeling, migrations, query translation, performance, and lifetime management for modern .NET applications. USE FOR: DbContext, migrations, model configuration, EF queries, tracking, loading, performance, transactions, and
Open skill

