Latitude migrate (V1 to V2)

Latitude V1 hosted prompts (PromptL) and ran them through a gateway; the app called prompts.run(). Latitude V2 observes an agent the app runs itself: prompts live in the codebase, the app calls the model provider directly, and Latitude sees traffic through OpenTelemetry. This skill takes an app from one to the other and leaves it verified: real traces in a V2 project, the V1 evaluations recreated as signals, the V1 datasets imported, and a regression replay that runs locally.

The human-readable version of this flow is the docs page Migrate from Latitude V1. Read concept-map.md in this folder for the V1 to V2 mapping and promptl-to-code.md for the prompt conversion rules.

Preflight

Confirm the app is on V1 before doing anything. Any of these is enough:

• latitude-sdk below 6 in requirements.txt / pyproject.toml, or @latitude-data/sdk below 6 in package.json.
• Calls to prompts.run, prompts.chat, prompts.get, prompts.getAll, runs.*, logs.create, evaluations.annotate, or HTTP requests to gateway.latitude.so/api/v3.
• LATITUDE_PROJECT_ID or LATITUDE_VERSION_UUID in env or config. V2 uses LATITUDE_PROJECT_SLUG.
• .promptl files, or {{ variables }} with a provider: / model: frontmatter block.

Then find out what V2 access exists, in this order: a connected and authenticated Latitude MCP; a LATITUDE_API_KEY that works against https://api.latitude.so/v1/account; nothing. With nothing, hand the account creation to latitude-setup (temporary account and claim link) and come back here. Do not run latitude-setup's delete-and-recreate cleanup on a project the user already owns.

You also need the V1 API key and V1 project id (from the app's env). If the V1 key returns 402 or 401, the V1 workspace has lapsed; ask the user for a UI export of prompts and datasets, or reconstruct the prompts from the call sites and tell the user that is what you did.