Onboarding Teardown 是 Adapty 团队对头部订阅制应用所执行的引导流程拆解方法，被封装为一个技能。它的用途是帮助开发者诊断和改进移动应用的 onboarding 流程。当有人希望改善、修复、测试或批评自己的引导流程时，只需提供描述、屏幕截图、渲染图或 Flow Builder 配置，技能就会给出一组按优先级排序的、可测试的假设。每条假设都建立在头部应用中观察到的模式之上，并附带预期的效果区间。它的价值不在于泛泛的建议，而在于“模式 + 具体应用 + 依据 + 数字”的组合。
主要能力包括：将 onboarding 与付费墙视为同一条漏斗，重点寻找两者接缝处的发现，例如 onboarding 中获取了目标但付费墙从未提及，或加载页承诺了个性化而下一屏并未兑现。技能强调绝不退化为通用技巧。它支持多种输入形式，并首先判断输入类型，因为输入形式决定了是否需要进行访谈。描述是默认形式，会触发六问访谈；截图是描述的补充而非替代；Flow Builder JSON 配置可直接读取顺序与跳转逻辑，无需再询问其中已有的信息；渲染图则被当作截图处理，为配置的结构增加执行层面的判断。
使用方式上，六问访谈要求一次只问一个问题，等待回答后再问下一个，避免一次性抛出六个问题造成负担。有交互式多选工具时优先使用，否则以纯文本逐条提问，但始终保留自由文本与跳过选项。六个问题分别是：应用品类、引导流程长度、用户看到的第一屏内容、是否询问用户目标并在付费墙前给出个性化结果、付费墙何时出现、何时请求权限。访谈规则要求从已有信息中提取而非重复询问，部分回答时只追问缺失部分，能合理推断的就推断并说明，尊重跳过，从不为缺失答案设障，且绝不问第七个问题。访谈过程中不做即时评论，所有发现留到最终拆解中输出。
该技能区分两个方向：Audit（审计）用于流程已存在且不由使用者改动的情况，运行流程后输出排序表格；Design（设计）用于使用者自己构建或编辑流程、且没有可参照的设计稿的情况，这时模式库就是参照，需要完成三个不可省略的环节：先选骨架与长度、再前向搭建模式、最后对自己的产出做回检。骨架选择是一个带有前提条件的决策，包括个性化循环、价值走查、问题→方法→证明、承诺引导、权限预备设置、短功能型等，选择依据是应用实际能力与目录情况，而非向用户提问。
适用场景为订阅制移动应用的引导流程优化、转化率诊断与付费墙前的漏斗衔接分析。限制方面，技能明确禁止编造功能、收费、价格、平台、效果或使用步骤；配置无法展示应用是否真正兑现承诺、品类信息以及权限请求的机制细节；对于无法修复、依赖真实数据或资产的问题，只能保留为发现而非直接给出解决方案。资料中未提供具体的分类标识、价格或平台信息。