Migrations

Every pair release that changes the .pair/adoption/ or .pair/knowledge/ structure ships a migration page here. Pages are the entire migration surface: no pair skill contains migration logic.

How this section works

• One page per version jump. A page covers exactly one breaking release (e.g. v0.4 → v0.5).
• Sequential composition. Several versions behind? Run the pages in order: there are no gaps between published breaking versions.
• No page means no migration needed. If a release isn't listed below, it didn't change the adoption/KB structure.
• Prompts are copy-paste and agent-agnostic. Paste the prompt into any AI coding agent (Claude Code, Cursor, Copilot, Codex, or similar) working in your project: it edits only your .pair/ files.
• Prompts are idempotent. Re-running a prompt is safe; it detects what's already migrated and resumes instead of duplicating work.

Detect your version

Before picking a starting page:

• If you still have the KB package/ZIP you installed from, run pair-cli kb-info <package-path> to read its version metadata.
• Otherwise, check for the structural markers a migration would have added, e.g. does .pair/adoption/product/context-map.md exist? Does .pair/working/ exist? Their absence means you're pre-migration for that jump.

Or run pair-cli kb-info (no package path): it compares the installed KB version with the current one and prints the migration-page pointer when they differ.

Published migration pages

Related

• Writing Migration Pages: the Changed / Prompt / Verify pattern, for maintainers authoring a new page
• KB Structure Reference: current .pair/ directory layout
• CLI Commands: kb-info and other pair-cli commands