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 compiling, behavior-preserving time refactors that must keep the same DateTimeKind. DO NOT USE FOR: detecting statics (use detect-static-dependencies), designing a brand-new wrapper interface that does not exist yet (use generate-testability-wrappers), migrating between test frameworks.

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

81%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a highly actionable, well-sequenced migration workflow with concrete tables, code, and a real build-verification feedback loop. Its main weakness is conciseness — the DateTimeKind guidance and some emphatic prose are repeated across multiple sections.

Suggestions

Consolidate the DateTimeKind guidance into one place (e.g., keep the detailed callout in Step 2 and reference it from the Common Pitfalls and Validation checklist instead of restating it) to cut repetition.

Trim emphatic padding such as 'this is the most common silent regression' and 'A false success claim is worse than an unfinished migration' — the surrounding imperative already conveys the requirement.

Consider moving the full replacement-mapping table or the ambient-seam deep-dive into a reference file under ./references/ so SKILL.md stays a lean overview, which would also let progressive_disclosure reach 5.

Dimension	Reasoning	Score
Conciseness	Mostly efficient and avoids explaining basic concepts Claude already knows, but the DateTimeKind point is repeated in Step 2, the Common Pitfalls table, and the Validation checklist, and emphatic prose like 'this is the most common silent regression' adds padding that could be tightened.	3 / 5
Actionability	Fully executable guidance: a concrete original-to-replacement mapping table, copy-paste ambient-seam code, using-directive table, exact test-double package names (Microsoft.Extensions.TimeProvider.Testing), and specific build-failure fixes — covering the common cases copy-paste ready.	5 / 5
Workflow Clarity	A clear 7-step sequence with prerequisite verification in Step 1 and explicit build verification in Step 6 ('Report the build result you actually observed') plus a fix-or-surface feedback loop, so the destructive/batch cap does not apply.	5 / 5
Progressive Disclosure	No bundle files exist, so all content is inlined; however the body is well-organized with clear section headers (When to Use, Inputs, Workflow, Validation, Common Pitfalls) and the inlined material is coherent as a single workflow document, leaving only minor organization gaps.	4 / 5
	Total	17 / 20 Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is exemplary: third-person, specific, with concrete USE FOR/DO NOT USE FOR trigger guidance and clear boundaries against sibling skills. It answers what and when with natural phrasing a user would actually say.

Dimension	Reasoning	Score
Specificity	Lists multiple specific concrete actions across categories — 'Replace existing static dependency call sites with a wrapper', 'bulk replace File.* with IFileSystem', 'update unit tests to a fake time source', 'add an ambient TimeProvider/IFileSystem seam' — giving comprehensive coverage rather than just 1-2 actions.	5 / 5
Completeness	Explicitly answers both what (replace static call sites with a wrapper/built-in abstraction across a bounded scope) and when (USE FOR with concrete triggers plus a DO NOT USE FOR boundary), matching the anchor for clearly answering both with concrete trigger phrases.	5 / 5
Trigger Term Quality	Comprehensive natural trigger terms including synonyms and concrete API names users would actually say: 'replace DateTime.UtcNow/DateTime.Now with TimeProvider', 'migrate static call sites to a wrapper already in DI', 'File.* with IFileSystem', 'make a static class testable'.	5 / 5
Distinctiveness Conflict Risk	Occupies a clear niche (static-to-wrapper migration) with an explicit DO NOT USE FOR clause distinguishing it from detect-static-dependencies and generate-testability-wrappers, minimizing conflict risk.	5 / 5
	Total	20 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: dotnet/skills
Path: plugins/dotnet-test/skills/migrate-static-to-wrapper/SKILL.md
Commit: 1b896e9

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.