Skip to content
Templates/Migration
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 API
Test suite passes
No deprecated API usage remains
Behavior is unchanged
 
Independent 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 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.
Maximum iterations: 8
 
Budget:
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.