/workflow-foundation
Maintain or assess Workflow Foundation-based solutions on .NET Framework, especially where long-lived process logic or legacy designer artifacts still matter. USE FOR: WF activities and workflows; designer-backed process logic; long-lived workflow state and persistence; keep,
$ npx -y skills add managedcode/dotnet-skills --skill workflow-foundation --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
/workflow-foundation
Context preview
The summary Claude sees to decide when to auto-load this skill.
Maintain or assess Workflow Foundation-based solutions on .NET Framework, especially where long-lived process logic or legacy designer artifacts still matter. USE FOR: WF activities and workflows; designer-backed process logic; long-lived workflow state and persistence; keep,
SKILL.md
workflow-foundation.SKILL.mdname: workflow-foundation
description: "Maintain or assess Workflow Foundation-based solutions on .NET Framework, especially where long-lived process logic or legacy designer artifacts still matter. USE FOR: WF activities and workflows; designer-backed process logic; long-lived workflow state and persistence; keep, isolate, or replace decisions. 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 WF or a migration plan away from it."
Windows Workflow Foundation
Trigger On
- working on WF activities, workflows, or designer-backed process logic
- reviewing long-lived workflow state and persistence behavior
- assessing whether to keep, isolate, or replace Workflow Foundation
Workflow
1. Treat WF as legacy infrastructure and start by understanding what workflow behavior is still business-critical before proposing replacement. 2. Separate workflow host concerns, activity logic, persistence, and integration points so risk is visible. 3. Avoid half-migrations that leave workflow state and business rules split across two orchestration systems without ownership. 4. If replacement is needed, define explicit equivalence for triggers, compensation, persistence, and audit expectations. 5. Stabilize current behavior with targeted tests or scenario captures before changing designer-driven artifacts. 6. Validate with representative long-running and failure scenarios, not just a single successful execution path.
Deliver
- practical maintenance or migration guidance for WF
- clear boundaries around host, workflow, and persistence responsibilities
- risk-aware change plans for legacy process logic
Validate
- business-critical workflow behavior is identified before change
- migration work preserves state and audit expectations
- designer artifacts are treated carefully
References
- [Migration Guidance](references/migration.md) - decision framework for keeping, replacing, or isolating WF; migration targets and steps; common pitfalls
- [Maintenance Patterns](references/patterns.md) - host management, persistence, activity design, testing, and operational patterns for WF systems
Read more
name: workflow-foundation description: "Maintain or assess Workflow Foundation-based solutions on .NET Framework, especially where long-lived process logic or legacy designer artifacts still matter. USE FOR: WF activities and workflows; designer-backed process logic; long-lived workflow state and persistence; keep, isolate, or replace decisions. 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 WF or a migration plan away from it."
Windows Workflow Foundation
Trigger On
- working on WF activities, workflows, or designer-backed process logic
- reviewing long-lived workflow state and persistence behavior
- assessing whether to keep, isolate, or replace Workflow Foundation
Workflow
1. Treat WF as legacy infrastructure and start by understanding what workflow behavior is still business-critical before proposing replacement. 2. Separate workflow host concerns, activity logic, persistence, and integration points so risk is visible. 3. Avoid half-migrations that leave workflow state and business rules split across two orchestration systems without ownership. 4. If replacement is needed, define explicit equivalence for triggers, compensation, persistence, and audit expectations. 5. Stabilize current behavior with targeted tests or scenario captures before changing designer-driven artifacts. 6. Validate with representative long-running and failure scenarios, not just a single successful execution path.
Deliver
- practical maintenance or migration guidance for WF
- clear boundaries around host, workflow, and persistence responsibilities
- risk-aware change plans for legacy process logic
Validate
- business-critical workflow behavior is identified before change
- migration work preserves state and audit expectations
- designer artifacts are treated carefully
References
- [Migration Guidance](references/migration.md) - decision framework for keeping, replacing, or isolating WF; migration targets and steps; common pitfalls
- [Maintenance Patterns](references/patterns.md) - host management, persistence, activity design, testing, and operational patterns for WF systems
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

