migrate-static-to-wrapper
Replace existing static dependency call sites with a wrapper or built-in abstraction that already exists or is registered in DI, across a bounded scope (file, project, namespace). USE FOR: replace DateTime.UtcNow/DateTime.Now with TimeProvider and add the constructor parameter, migrate static call sites to a wrapper already in DI, bulk replace File.* with IFileSystem, scoped migration of statics in only certain files, update unit tests to a fake time source, make an existing static or utility class testable by adding an ambient TimeProvider/IFileSystem seam while every current call site keeps
npx skills add dotnet/skills --skill migrate-static-to-wrapper --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# Migrate Static to Wrapper Perform mechanical, codemod-style replacement of static dependency call sites with calls to injected wrapper interfaces or built-in abstractions. Operates on a bounded scope (single file, project, or namespace) so migrations can be done incrementally. ## When to Use - After wrappers have been generated (via `generate-testability-wrappers`) or built-in abstractions identified - Migrating `DateTime.UtcNow` → `TimeProvider.GetUtcNow()` across a project - Migrating `File.*` → `IFileSystem.File.*` across a namespace - Adding constructor injection for the new abstraction to affected classes - Making a `static` utility class testable by adding an ambient seam (Step 3) while its existing call sites keep compiling unchanged - Incremental migration: one project or namespace at a time ## When Not to Use - No wrapper or abstraction exists yet and one must be designed from scratch (use `generate-testability-wrappers` first). A built-in abstraction such as `TimeProvider` or `IFileSystem` always counts as existing. - The user wants to detect statics, not migrate them (use `detect-static-dependencies`) - Migrating between test frameworks (use the appropriate migration s
- When to Use
- When Not to Use
- Inputs
- Workflow
- Step 1: Verify prerequisites
- Step 2: Plan the migration for each file
- Step 3: Add constructor injection
- Step 4: Replace call sites
- Step 5: Update affected test files
- Step 6: Build verification
- Step 7: Report changes
- Validation
- Common Pitfalls
dotnet build <project.csproj>
What does the migrate-static-to-wrapper skill do?
Replace existing static dependency call sites with a wrapper or built-in abstraction that already exists or is registered in DI, across a bounded scope (file, project, namespace). USE FOR: replace DateTime.UtcNow/DateTime.Now with TimeProvider and add the constructor parameter, migrate static call sites to a wrapper already in DI, bulk replace File.* with IFileSystem, scoped migration of statics in only certain files, update unit tests to a fake time source, make an existing static or utility class testable by adding an ambient TimeProvider/IFileSystem seam while every current call site keeps
How do I install it?
Run `npx skills add dotnet/skills --skill migrate-static-to-wrapper --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From dotnet/skills, a repository with 4,927 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.