migrate-placements 属于 Adapty 团队维护的 Adapty Skills 集合，来源标识为 adaptyteam/adapty-skills，技能页面为 https://www.skills.sh/adaptyteam/adapty-skills/migrate-placements。从资料描述看，它适用于这样的场景：用户希望把应用中的付费墙位（paywall placements）迁移到 Flow Builder 的 flows，例如表达「migrate my placements to flows」「switch my paywalls to flows」之类需求时。
用途与产出 该技能的交付物是新的 flow placements，以及一张旧 paywall placement ID 到新 flow placement ID 的映射表，并附带代码修改的交接说明。也就是说，迁移不会在仪表盘内完成：在应用发布调用变更之前，用户不会受到影响，旧 placement 会继续服务，因此「什么都不发布」本身就是回滚手段。
主要能力与关键约束 资料给出了两个决定该技能整体形态的、经过测量的事实（api-surface.md）。第一，placement 的内容类型在创建后无法更改：在 paywall placement 上带 flow audience 执行 placements update 会被拒绝，提示 Placement type can not be changed.；这是在已部署 audience union 的环境上发生的，因此属于后端规则而非 CLI 功能缺失，不存在转换操作。每次迁移都是一次 placements create，原有 paywall placement 保持原样。第二，placement ID 是永久的：文档原文说明 Placement IDs are unique across every placement in the app, whatever the type, so the same ID can't serve a flow in one place and a paywall in another.。由于 placements delete 不在范围内，新 placement 不能复用旧 ID，错误创建的 placement 会永久留在应用中。因此每个 ID 都会在创建任何内容之前完整展示并获得确认。
工作流程（分阶段） 技能按阶段推进，资料中可见以下阶段：
- 阶段 1「解析与探测」：需要 flows publish。该阶段要求一次性解析 $ADAPTY，例如 npm i -g adapty@latest >/dev/null 2>&1 && ADAPTY="adapty" || ADAPTY="npx --yes adapty@latest"，然后运行 $ADAPTY --version 与 $ADAPTY auth whoami 检查命令是否存在，而不是以某个版本号作为门槛；因为 flows publish 的发布历史出现过版本反复（0.8.3-beta.0、0.8.3-beta.1 有，0.8.3 没有，之后又回来）。若安装最新版后命令仍缺失，可尝试 npx --yes adapty@beta；若仍缺失，说明该路由尚未发布，应告知用户并给出仪表盘步骤（Migrate to flows）。资料强调安装一次即可，不要用 npx 包裹每次调用；npx 回退时 --yes 是必需的；在 zsh 中多词 $ADAPTY 不会被分词，需要 setopt shwordsplit，command not found: npx --yes adapty@latest 是 shell 问题而非 CLI 缺失。随后通过 $ADAPTY apps list --json 获取应用 UUID。
- 阶段 2「库存清点」：属于只读且穷尽的步骤。资料指出 --page-size 默认为 20，响应中的 meta.pagination {count, page, pages} 是唯一说明这一点的地方，因此不能只读第 1 页。示例命令：python3 <skill>/references/migrate.py inventory --app "$APP" --adapty "$ADAPTY" --scope active --out inventory.json，或使用 --scope all。该阶段也会读取 flows list 与 paywalls list；--no-existing 会跳过它们，仅在读取失败时使用。资料还说明了 migrate.py 的退出码：2 表示未成功且原因未被明确判定为内部问题；3 表示脚本内部不变量被破坏，此时输入几乎肯定没问题，应停止并报告。
- 阶段 3「分类与分组」：示例命令为 python3 <skill>/references/migrate.py plan --inventory inventory.json。按 audience 分类：paywall_id → migratable；flow_id → already done；两者都没有 → skip。可迁移的 audience 按 paywall_id 分组，这就是 flow 计划：每个不同的 paywall 对应一个可复用 flow。报告应以计数和分组呈现，而不是逐行罗列。当 summary.unwritable_multi_segment 不为零时，这些 placement 视为受阻，且不应建议拆分或丢弃 segment，因为那会改变谁能看到什么，属于用户决策。资料还提到需要披露计数是「API 返回内容」的计数，因为 placements get 只返回 paywall 与 flow audience，会静默省略其他类型（例如 A/B test audience）。
- 阶段 4「两个问题」：在一条消息中同时提出两个问题然后停下。第一个是范围（Scope），在 is_active 存在时是真正的三选一：Active only（is_active: true）、All（不过滤）、A named list（用户提供 id）。第二个是按 paywall 逐个询问，应以一张表格呈现，每行给出推荐路线，而不是每个 paywall 发一条消息。资料还说明 summary.existing 会影响阶段 4 的提问：每个 flows_needed 行带有 paywall 的 paywall_title，以及匹配名称的 existing_flow_candidates，每个候选带有 status 和 next_step（attach 或 publish_then_attach）；匹配仅基于名称，因此可能是巧合，而没有匹配也不能证明没有转换过（流程被改名后就没有可匹配的东西）。
边界 资料明确列出该技能的边界：它不设计或构建 flow 内容（那是 flow-generator 负责，包括 flows config update、预览循环和发布）；它不把 paywall 转换成 flow（那是仪表盘上的按钮，由用户点击，没有 CLI 等价物）；它不实现应用端调用点（那是 adapty-integration）；它不删除或修改任何现有 placement、paywall 或 flow。
适用场景与限制 该技能适用于需要把现有付费墙位迁移到 Flow Builder flows 的应用，且偏好分阶段、可确认、可回滚的迁移流程。限制包括：迁移在仪表盘外无法单独完成，最终需要应用发布调用变更；placement 类型不可更改、ID 永久且不可删除，导致误建无法撤销；audience union 部署状态会影响可写性，某些部署可能只能走仪表盘操作；多 segment audience 不可写且需先在仪表盘解决。资料显示更多细节（如完整版语气规范、逐条命令行提示等）已在原技能文档中给出；本介绍未涵盖的内容，暂未提供进一步信息。