Develop: Migrate

Move an app off a prompt-to-app platform and into the member's own repo, stack, and coding agent — completely, safely, and once. The output is docs/MIGRATION.md: a phased plan in the standard ProductOS task format, executable by the coding agent, that ends with a verification gate. Nothing on the old platform is paused or deleted until that gate passes.

Two rules frame the whole session:

1. Migration is not refactoring. This skill moves and rewires what exists; it does not restructure or improve it. Code-quality work (service layers, dead platform shims, prop drilling, styling convergence) belongs to studio-develop-refactor-plan, run after the app is living safely in its new home. Keeping the two separate keeps both plans small and verifiable.
2. Clean break. The moment export happens, the old platform's editor is retired — the repo becomes the single source of truth. Editing in both places loses work silently: platform exports are point-in-time snapshots, and changes made platform-side after export are gone.

Session shape: one sitting to inventory, decide the stack, and write the plan (45–60 min); the coding agent then executes the plan over one to a few sessions depending on how much backend the platform owned. Small frontend-only apps migrate in an hour or two; apps where the platform owns the database, auth, and functions are a half-day of careful work.

Inputs

Locate in the ProductOS folder (productos/ at the app repo root, or the current folder in a standalone checkout) and the repo-root docs/:

1. docs/PRODUCT.md — if present, the canon for what the app is; useful for the verification gate's core-flow list. Not required.
2. productos/develop/guides/TECH-STACK-OPTIONS.md — the stack recommendations the target should be chosen from.
3. The platform project itself — the user demonstrates or describes it; if a repo export already exists, read it directly.