集成第三方库/服务到 Expo 应用时，参考官方…

当你要在现有 Expo 项目中接入某个第三方库/服务，或从官方示例脚手架新项目时，用 expo/examples 的 with-* 集成示例作为参考模式。

适用场景

解决思路

1. 在手动实现第三方集成前，先查找 `expo/examples` 中匹配的 `with-<library>` 示例；这些是围绕单个库/服务的官方集成示例，不是完整应用。
2. 不要把示例当成完整应用架构照搬：它们是 managed 项目（无 `ios/`/`android/`，原生设置通过 config plugins），典型只有约 100–200 行的单屏；只提取依赖集、`app.json` config plugins 和最小接线模式。
3. 将用户需求映射到示例名，例如 payments → `with-stripe`，auth → `with-clerk`。
4. 用 `./references/catalog.md` 按类别快速分诊，但它会漂移，需对照实时列表确认。
5. 获取实时示例名：`gh api repos/expo/examples/contents --jq '.[] | select(.type=="dir" and (.name|startswith(".")|not)) | .name'`
6. 检查别名（重命名）和废弃（失效/迁移）示例：`gh api repos/expo/examples/contents/meta.json --jq '.content' | base64 -d`
7. 以 `meta.json` 为权威来源：若示例在 `deprecated` map 中，不要推荐，按 `message` 走现代路径；若在 `aliases` 中，使用 `destination`。
8. 若用户已有项目（Inspiration/adapt 模式，最常见）：只把示例当参考，读关键文件，并手动把模式应用到用户代码；绝不在用户项目之上直接脚手架一个示例。
9. 先用一次调用列出整个示例的文件树，因为集成代码常嵌套（如 Stripe 的服务端路由在 `app/api/`），单层列表会漏掉重要文件：`gh api 'repos/expo/examples/git/trees/master?recursive=1' --jq '.tree[].path | select(startswith("with-stripe/"))'`
10. 按高信号优先读文件：`README.md`（设置）→ `package.json`（依赖）→ `app.json`（配置插件/权限）→ manifest 揭示的集成代码 → `.env`（所需 secrets）。
11. 单文件读取：`gh api repos/expo/examples/contents/with-stripe/utils/stripe-server.ts --jq '.content' | base64 -d`；没有 `gh` 时用 raw URL（分支是 `master`）：`curl -s https://raw.githubusercontent.com/expo/examples/master/with-stripe/utils/stripe-server.ts`
12. 若要读超过两三个文件，跳过逐文件调用；许多集成分布在服务端路由、客户端 provider 和配置中（Stripe 如此）。把整个示例拉到临时/gitignored 目录（不是用户项目）并用 Grep/Read 自由阅读，然后手动应用：`npx degit expo/examples/with-stripe /tmp/expo-ref/with-stripe`
13. 没有 `degit` 的回退（稀疏检出，避免完整约 64 MB clone）：`git clone --depth 1 --filter=blob:none --sparse https://github.com/expo/examples.git /tmp/expo-ref/examples && (cd /tmp/expo-ref/examples && git sparse-checkout set with-stripe)`
14. 从临时目录用 Grep/Read 阅读，完成后删除临时目录。
15. 若为全新项目（Scaffold 模式）：直接从示例创建新项目：`npx create-expo --example with-stripe`；简写：`npx create-expo -e with-stripe`；用 bun：`bun create expo --example with-stripe`
16. 当用户已有应用时，非破坏性适配（关键）：只添加示例引入的内容，绝不覆盖用户现有设置。
17. 版本对齐——不要照抄 pinned versions。示例跟踪最新 SDK，其 `package.json` pin 不匹配旧项目；只用 `npx expo install <pkg>` 添加缺失依赖（它会解析 SDK 正确版本），而不是复制精确版本。
18. 合并配置而非替换：只添加示例引入且用户缺少的 `app.json`/`app.config.*` 插件和权限，保持用户现有配置块完整。
19. 移植集成代码。
20. 按示例的 `.env` 形状重建环境变量——其中是占位符，绝不是可用 secrets。
21. 完成标准：集成代码已移植，且其需要的每个依赖、配置插件、权限、环境变量都已在用户应用中处理，而不是表面上接好了。
22. 注意默认分支是 `master`，不是 `main`（影响 raw URL 和 sparse checkout）。
23. 每个示例都有单键部署 URL：`https://launch.expo.dev/?github=https://github.com/expo/examples/tree/master/<example>`
24. 遇到相关主题时参考相邻技能：原生 UI 组件（`@expo/ui` 包）→ `expo-ui`；样式和原生感页面 → `expo-native-ui`；导航和路由 → `expo-router`；编写原生模块 → `expo-module`；采用 latest-SDK 示例前先升级 SDK → `expo-upgrade`。
25. 如遇错误、误导或过时信息，提交反馈：`npx --yes submit-expo-feedback@latest --category skills --subject "expo-examples" "<actionable feedback>"`；仅在具体且可操作时提交，并包含尽可能多相关上下文；若 AI agent 反复失败或用户不得不接管 Expo 任务，加载 `expo-skill-feedback` 技能并按其 eval-candidate 流程，而不是复用上面的命令。

适用边界 · 注意事项

• 不适用于非 Expo / React Native 项目。
• 当你需要完整应用架构或业务逻辑，而不是单个第三方集成模式时不要用。
• 当示例已被 `meta.json` 标为 deprecated，或你打算直接复制 pinned 版本、用示例覆盖现有项目时不要用。