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.

Rank a migration plan by correctness risk and the behavior it unlocks, not call frequency alone. Inspect how ambient values interact within each operation: multiple clock reads can make related timestamps drift. Name that defect and its acceptance criterion explicitly, but separate a proposed single-instant correction from a mechanical migration that must preserve reads one-for-one. Likewise preserve configuration fallback timing, exception propagation, and observable output unless their correction is explicitly in scope. Recommend only seams needed by the bounded behavior; pure path/serialization helpers do not need wrappers merely because they are static.

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

Production wiring is part of the migration, not an optional follow-up. Before edits, trace construction and composition in the affected project: existing DI registrations, Program.cs/Startup.cs, factories, manual new calls, and affected test constructors. An explicit dependency migration authorizes the minimal wiring needed to keep those callers working unless the user or repository forbids those edits. For TimeProvider, preserve an existing registration or register TimeProvider.System at the real composition root; for manual construction, supply the production default there. No DI container does not require introducing one or choosing process-global ambient state. If a caller is outside the permitted edit boundary, report that exact blocker rather than leaving an undisclosed runtime failure.

Do not treat an absent package as available. Reuse a selected/existing seam; when first-time dependency adoption is needed, use Generate only if authorized, otherwise report the missing prerequisite before changing call sites.

Phase 4: Test

After Phase 3, write the requested tests inline. Do not invoke code-testing or test-engineer; this agent is already running under the public orchestrator.

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.
4. The user has not already selected an available replacement seam.

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

Linked skills