MigrationMedium risk
Migration Loop
Migrate code to a new API, framework, or version until every call site compiles and tests pass.
What this Loop Engineering template does
Migrate the target code to the new API until every call site compiles and the test suite passes, without changing behavior.
The target stack and constraints are clear. Migrate call site by call site and run the tests after each checkpoint. Name one objective and one stopping condition before starting.
When to use it
Migrating a module to a new API
Framework or version upgrades with a clear target
Call-site-by-call-site migrations
When not to use it
Migrations with an unclear target or constraints
Big-bang migrations without a test safety net
Validation checks
validation
✓Every call site compiles against the new API
✓Test suite passes
✓No deprecated API usage remains
✓Behavior is unchanged
Boundaries & stop rule
!Do not change behavior during the migration
!Do not leave a silent mix of old and new APIs
!Do not delete tests
!Do not skip call sites
Stop rule — Stop when all call sites are migrated and tests pass, or after the agreed checkpoint budget. If a call site cannot be migrated safely, leave it, document why, and escalate for a human decision.
Copy the loop prompt
claude-goal.txt
/goal Migrate the target code to the new API until every call site compiles and the test suite passes, without changing behavior.Work toward this goal until all validation checks pass or the stop rule is reached.Loop cycle:1. Discovery — Read the latest signal for this template before acting: CI output, issue detail, review comment, dataset report, or content brief.2. Handoff — Hand the work to one agent in an isolated branch, worktree, or clearly scoped session. Keep final approval with a human.3. Verification — Use an independent review pass to confirm the result, inspect the diff or artifact, and reject shortcut work.4. Persistence — Save a short run note with the signal reviewed, actions taken, validation result, and next recommended step.5. Scheduling — Run manually until the loop is reliable; only then consider a scheduled or event-triggered run.Context:The target stack and constraints are clear. Migrate call site by call site and run the tests after each checkpoint. Name one objective and one stopping condition before starting.Validation:Every call site compiles against the new APITest suite passesNo deprecated API usage remainsBehavior is unchangedIndependent checker:Use an independent review pass to confirm the result, inspect the diff or artifact, and reject shortcut work.Boundaries:Do not change behavior during the migrationDo not leave a silent mix of old and new APIsDo not delete testsDo not skip call sitesStop rule:Stop when all call sites are migrated and tests pass, or after the agreed checkpoint budget.Maximum iterations: 8Budget:Stop before exceeding the agreed per-run token budget.Human approval:Required before merge, deploy, delete, purchase, or external communication.Fallback:If a call site cannot be migrated safely, leave it, document why, and escalate for a human decision.Do not delete tests, bypass checks, or modify unrelated files just to satisfy the validation condition. If blocked, stop and summarize the blocker, attempted fixes, and recommended next action.
Failure modes to watch
Half-migrated code with a mix of old and new APIs
Behavior drift during the migration
Skipped call sites
Dropped tests
Loop Engineering FAQ
Incremental migration with tests after each checkpoint keeps the codebase working throughout. A big-bang migration is hard to verify and hard to roll back.