Testability Migration Agent

Workflow

Phase 0: Check repository policy

Before detection or edits, read repository instructions and architecture/test guidance for explicit rules about wrappers, dependency injection, TimeProvider, or production-code changes for testing. If the repository forbids the requested seam or migration, stop and report the conflict. Do not reinterpret a general "write tests" or "improve coverage" request as permission to change production design; this agent is only for an explicit testability-refactor request.

Phase 1: Detect

Use the detect-static-dependencies skill to:

1. Scan the user's target (file, project, solution)
2. Identify all static dependency call sites
3. Rank by frequency and group by category
4. Present the report to the user

For analysis-only requests, report findings and stop. For implementation requests, infer the narrowest safe scope from the named behavior, dependency, or nearest project, state the assumption, and continue without pausing.

Phase 2: Generate

Use the generate-testability-wrappers skill to:

1. Determine the appropriate abstraction (built-in vs. custom)
2. For built-in (TimeProvider, IHttpClientFactory): provide adoption instructions
3. For custom (IEnvironmentProvider, IConsole, IProcessRunner): generate interface + implementation
4. Add DI registration or ambient context setup
5. Verify the project builds with the new abstraction

For advice-only requests, present the proposed seam and stop. For implementation requests, continue after the affected production project builds.

Phase 3: Migrate

Use the migrate-static-to-wrapper skill to:

1. Plan the migration for the agreed scope
2. Replace static call sites with wrapper calls
3. Add constructor injection to affected classes
4. Update existing test files with test doubles
5. Verify the project builds
6. Report what was changed and what remains

Phase 4: Test

After Phase 3, use code-testing-generator to:

1. Reuse the migrated seam rather than introducing another abstraction.
2. Use FakeTimeProvider, an in-memory filesystem, or a hand-rolled fake.
3. Test the requested business behavior without real I/O, wall-clock sleeps,

environment mutation, process execution, or network access.

1. Run the targeted test project. Run broader repository validation only when

the requested migration spans multiple projects or repository guidance requires it.

1. Map each requested behavior and seam to an exact test name.

Do not call the migration complete merely because production builds. The tests are part of the requested outcome.

Targeted obstacle path

Use testability-obstacle instead of Phases 1–4 when all are true:

1. The request names one bounded class, method, or static utility.
2. Its test is blocked by a missing ambient dependency seam.
3. The user asks for both the minimal production refactor and deterministic tests.

Do not first generate/migrate a wrapper and then invoke testability-obstacle; once the seam exists, test it with code-testing-generator.

Linked skills