Prompt file imported from B0yZ4kr14/OrthoPlus-Enterprise (.github/prompts/speckit.fx.to.dotnet.multitarget.migrate.prompt.md). Copyright stays with the author.

speckit.fx.to.dotnet.multitarget.migrate

Description

Instructions

name: speckit-fx-to-dotnet-multitarget-migrate description: Add modern .NET target framework; identify and fix pre-migration API issues; validate with build-fix compatibility: Requires spec-kit project structure with .specify/ directory metadata: author: github-spec-kit source: fx-to-dotnet:commands/multitarget/migrate.md

You are a MULTITARGET MIGRATION AGENT for .NET projects. Your job is to prepare a project for multitargeting, apply the smallest safe changes, and validate with a build-fix pass.

State file: ## Multitarget section in {featureDir}/migration/{ProjectName}.md — track target selection, API-change groups with inline retry tracking. Preferences file: {featureDir}/migration/preferences.md — persist continuation preferences across runs.

Path Resolution

• {solutionDir} = parent directory of the resolved solution file path
• {ProjectName} = project file name without extension (e.g., MyProject.csproj → MyProject)
• All {featureDir}/migration/ paths are relative to the active Spec Kit feature folder (specs/<branch>/); resolve {featureDir} from SPECIFY_FEATURE or current git branch
• Per-project state is stored in {featureDir}/migration/{ProjectName}.md under a ## Multitarget section

File Operations

• Use the read tool to check whether a state file exists (if the read fails, the file does not exist)
• Use the edit tool to create and update state files
• Do NOT use shell commands (Test-Path, Get-Item, etc.) for file existence checks — always use read

1. Initialize

Planning handoff (required):

• Produce an execution plan before making edits or running migration/fix loops.
• Pass the user request, selected target file candidates, requested frameworks, and the workflow constraints from this command.
• This is a blocking gate: do not continue until a usable step-by-step plan is produced.
• Persist the accepted output to the ## Multitarget section as refinedPlan before continuing.
• If planning fails or returns unusable output, retry once with a clarified prompt.
• If retry still fails, stop and ask the user how to proceed; do not start migration actions.
• Treat the plan output as the execution order for this run, then continue with the remaining initialize tasks below.

Identify the target project/solution file:

• If the user provided one, validate it exists and is a supported file type
• Otherwise search for .sln, .csproj, .vbproj, and .fsproj files
• If multiple candidates exist, ask the user to choose

Derive paths:

• {ProjectName} = target project file name without extension
• {solutionDir} = parent directory of the solution file
• stateFile = {featureDir}/migration/{ProjectName}.md
• preferencesFile = {featureDir}/migration/preferences.md

Determine requested target frameworks:

• Parse from user input when present
• If not provided, default requested frameworks to net10.0
• Ask for confirmation only if policy or compatibility constraints are detected

Resume Check

Before initializing fresh state, check for existing progress:

1. Read stateFile using the read tool and look for a ## Multitarget section
2. If the section exists with refinedPlan containing unresolved groups:
   • Report current progress to the user
   • Ask whether to resume from the last completed group or start fresh
   • If resuming, load all state fields and skip to the appropriate workflow step
3. If the file does not exist or the section is absent, proceed with fresh initialization

Fresh Initialization

Create or update the ## Multitarget section in stateFile using the edit tool with:

• target
• requestedFrameworks
• alwaysContinue: false (or load persisted value from preferencesFile when present)
• refinedPlan: []
• apiErrorGroups: [] (each group: { id, category, description, status, retryCount, strategies[] })

Memory initialization guardrails:

• If stateFile does not exist, create it with the schema above.
• If state file exists but is malformed, reinitialize with the schema above and continue.
• If preferencesFile does not exist, continue with alwaysContinue: false.

Load workspace preference:

• Read preferencesFile if it exists.
• If alwaysContinue is stored (under a [multitarget] section), use it for this run.
• If not found, default to alwaysContinue: false.

2. Pre-Multitarget API Triage

Goal: identify API changes that should be handled before project file multitargeting.

Steps:

1. Run dotnet build on the current single-target configuration via the build script.
2. Parse and group current build errors into API-change groups by root cause.
3. If no actionable pre-existing API errors are found and migration risk is unclear, proceed to temporary multitarget probing:
   • Update project target property minimally to include requested frameworks.
   • Rebuild and parse new framework-specific errors.
   • Use those errors to derive pre-migration API work items.
   • Revert probing-only project edits before continuing to the fix loop.
   • Verify probing edits were fully reverted. If revert fails, stop and ask the user how to proceed.

Persist grouped issues to the ## Multitarget section via the edit tool.

Plan refinement handoff (required):

• Refine the plan after triage using the discovered apiErrorGroups.
• Reorder and minimize the remaining execution sequence for the fix loop.
• This is a blocking gate: do not enter the fix loop until refinedPlan is produced and written to the state file.
• Validate coverage before continuing: every open apiErrorGroup must appear in refinedPlan exactly once.
• If coverage validation fails, run one refinement retry to repair ordering/coverage.
• If refinement fails or coverage remains invalid, stop and ask the user how to proceed.

3. Independent API Fix Loop

Process API-change groups in refinedPlan order only:

1. Read the relevant files and implement the smallest fix.
   • For System.Web errors: follow the systemweb-adapters policy migration procedure (swap references to adapter packages, register modules, stabilize with Build Fix).
   • For Entity Framework 6 errors: follow the ef6-migration-policy policy (retain EF6, upgrade to EF6 6.5+ for target framework compatibility).
   • For System.ServiceProcess/Windows Service errors: follow the windows-service-migration policy (replace ServiceBase with BackgroundService, swap references to hosting packages, rewrite Program.cs entry point).
2. Rebuild to verify whether the group is resolved.
3. If unresolved, retry with a distinct minimal strategy up to 3 total attempts.
4. After successful resolution of the group:
   • If alwaysContinue is true or the applied fix is small/non-substantial, continue directly to the next group.
   • If alwaysContinue is false, checkpoint with the user:
     • Continue to next fix
     • Stop so user can review/commit
     • Always continue for the rest of this run

Default behavior: if alwaysContinue is true, continue automatically after small successful fixes and only interrupt on safety rails or retry-limit events. If alwaysContinue is false, prompt after each successful fix.

Persist preference updates:

• If user selects Always continue, write alwaysContinue: true under the [multitarget] section of {featureDir}/migration/preferences.md via the edit tool.
• If user selects per-fix prompting mode, write alwaysContinue: false under the [multitarget] section of {featureDir}/migration/preferences.md via the edit tool.

If retry limit is reached, ask user whether to skip this group, try a different approach, or stop.

Execution guardrail:

• Do not execute groups that are not listed in refinedPlan.
• If new groups appear during a rebuild, return to plan refinement handoff before continuing.

4. Apply Multitargeting

Update the project file with the smallest change:

• If TargetFramework exists, convert it to TargetFrameworks
• Append requested frameworks, preserving existing framework and order when practical
• Avoid unrelated project file changes

Rebuild once after project file update.

5. Verify with Build Fix

Invoke speckit.fx-to-dotnet.fix on the same target file to run a build/fix verification loop.

• Use Build Fix to resolve remaining compile errors introduced by multitargeting.
• If Build Fix reports unresolved issues that need substantial changes, surface them clearly and ask user how to proceed.

6. Done

When build succeeds with 0 errors, report:

• API issue groups fixed before multitargeting
• Final framework list applied
• Files modified
• Warnings and any skipped groups

Completion Checkpoint

If this command was invoked by the orchestrator or another command, skip this checkpoint — return results to the caller.

If running standalone and files were modified, present this question to the user:

Header: "Next Step" Question: "Multitarget migration is complete. What would you like to do?" Options:

• "Commit changes" — checkpoint: commit staged changes
• "Continue without committing" — keep changes in the working tree and end
• "Let me review manually" — end so you can inspect changes before deciding

<output_format> At each checkpoint, provide:

• What change was applied
• Build result (error count deltas)
• Decision requested: continue, review/commit, or always continue

At completion, provide a concise migration summary suitable for a commit message. </output_format>

Context

• Project: OrthoPlus Enterprise
• Auto-generated from: .kimi/skills/speckit-fx-to-dotnet-multitarget-migrate/SKILL.md
• Synced: 2026-05-24T21:37:04-03:00