building-native-ui

building-native-ui skill 概覽

building-native-ui skill 是做什麼用的

building-native-ui skill 是一份很實用的指南，幫你打造在 Expo Router 上看起來真正有原生感、而不只是「跨平台可用」的介面。當你希望 AI agent 能替 React Native 與 Expo app 做出具體而正確的 UI 判斷時，它特別有價值：包含路由結構、iOS 風格控制項、標題列、分頁、動畫、媒體流程、視覺效果，以及因平台而異的設計模式。

誰適合安裝它

這個 building-native-ui skill 最適合在 Expo 或 React Native 環境工作的前端開發者，尤其是那些不只需要通用元件範例，而是需要更具體實作方向的人。它特別適合正在做 mobile-first 產品的團隊，因為這類產品往往很在意導覽、原生控制項、動態效果與平台慣例。如果你已經在用 Expo Router，或正打算採用它，這個 skill 會比泛泛的「幫我做一個 mobile UI」提示更有方向感。

真正要解決的工作需求

多數人會安裝 building-native-ui，是因為他們想讓 agent 把一個還很粗略的產品想法，轉成可以直接落地的 UI 實作選擇，而且不想在 Expo 的路線上瞎猜。它的真正價值不只是提供範例程式碼，而是幫你減少在 tabs、sheets、search、storage、media、icons、animations 與 route 組織方式上的錯誤起手式。

它和一般 UI prompt 最大的差別

building-native-ui skill 最強的差異，在於它把 Expo 特有的偏好與限制都編進去了。它會引導 agent 朝這些方向做決策：

• Expo Router 的檔案與 layout 慣例
• 更有原生感的 iOS 控制項與 SF Symbols
• 以 Reanimated 為主的動態效果，而不是較舊的動畫作法
• 實際的平台邊界，例如哪些情況 Expo Go 可行、哪些則需要 custom build
• 針對 tabs、search、media、gradients、zoom transitions 與 visual effects 的精準參考文件

在採用前最該先確認什麼

在使用 building-native-ui for Frontend Development 之前，先知道它是有明確立場的。它偏向原生設計模式，而不是通用型跨平台 UI kit；偏好 Expo 友善的 API；也會包含一些受版本或平台限制的功能，例如僅限 iOS 的能力、New Architecture 要求，以及特定 SDK 版本需求。當你想做出高品質、接近原生的體驗時，這是優點；但如果你要做大量與 web 共用的 design system，或偏向 framework-agnostic 的 app scaffold，它就沒那麼適合。

如何使用 building-native-ui skill

安裝 building-native-ui skill

如果你的 agent 支援 Skills，可以直接從 Expo skills repository 加入：

npx skills add https://github.com/expo/skills --skill building-native-ui

如果你的環境裡已經有 Expo skills repo，也可以直接從 plugins/expo/skills/building-native-ui 載入 building-native-ui skill。

先讀這些檔案

想快速上手，不要一開始把所有內容都掃過一遍。建議依照這個順序讀：

1. SKILL.md
2. references/route-structure.md
3. references/tabs.md
4. references/toolbar-and-headers.md
5. references/animations.md

接著，只有在你的功能真的需要時，再往下讀更窄的參考檔：

• references/form-sheet.md
• references/search.md
• references/media.md
• references/storage.md
• references/icons.md
• references/visual-effects.md
• references/zoom-transitions.md
• references/gradients.md
• references/webgpu-three.md

這條閱讀路徑其實很貼近真實 UI 決策流程：先定 app 結構，再定導覽，最後才處理畫面行為與細節打磨。

下 prompt 前先確認安裝情境

要不要做 building-native-ui install，關鍵其實取決於你的 runtime 限制。這個 skill 明確建議：在做 custom build 之前，先試 Expo Go。這點很重要，因為它引用的一些能力並不是每個環境都能用：

• CSS gradients 需要 React Native New Architecture，而且在 Expo Go 不能用
• Apple Zoom transitions 需要 iOS 18+
• 某些 toolbar 與 search 模式是 iOS-only
• Form sheet 範例需要 Expo Router 的 stack 設定，而且部分細節需要較新的 Expo SDK 版本

如果你的 app 必須完整跑在 Expo Go，請在 prompt 裡直接講清楚。不然 agent 很可能會挑到必須用 development build 的功能。

提供 building-native-ui skill 正確的輸入資訊

building-native-ui usage 的輸出品質，高度依賴你提供的上下文。建議至少交代這些資訊：

• 你的 Expo SDK 版本
• 是否必須支援 Expo Go
• 目標平台：iOS、Android、web
• 是否已經使用 Expo Router
• 想要實作的畫面或流程
• 設計目標，例如「像原生 iOS 設定頁」或「Instagram 風格相機」
• 對 storage、media、animations、search 或 tabs 是否有硬性需求

較弱的輸入：
「Build a settings screen.」

較強的輸入：
「Using Expo Router on Expo SDK 55, build a settings area for iOS and Android. Must work in Expo Go. Use native-feeling controls for notification toggles, theme mode selection, and a storage section. Keep route files in app/ only and place reusable UI in components/.」

後者之所以更好，是因為它讓 skill 有足夠資訊去選控制項、避開不支援的 API，並遵守 route 慣例。

把模糊想法轉成完整 prompt

一個可靠的 building-native-ui guide prompt 模板，可以包含：

• Product context
• Platform targets
• Runtime constraints
• Screen list 或 route tree
• Interaction details
• Visual style goals
• 希望回傳的 output format

範例：

「Use the building-native-ui skill to design and implement a photo detail flow in Expo Router. Target iOS first, Android acceptable. Try to stay compatible with Expo Go unless a feature clearly requires a custom build. I need:

• route structure for list, detail, and search
• native tabs if appropriate
• a large collapsing image header
• search in the header
• saved items persisted locally
• smooth Reanimated transitions
  Return:

1. recommended file tree
2. route files to create
3. key component code
4. note any features that require iOS-only APIs or custom builds.」

這種 prompt 有效，是因為它要求 skill 幫你做決策，而不是只吐出 JSX。

依照 building-native-ui skill 偏好的流程來做

實務上，最穩的 building-native-ui usage 工作流程是：

1. 先要求 route 與 navigation 結構。
2. 再要求每個 screen 要用哪些原生控制項。
3. 等結構正確後，再加 motion 與 headers。
4. 等流程清楚後，再加 persistence、media 或 search。
5. 最後再請 agent 標出哪些需要 custom build 或平台限定。

這樣做可以避免常見的重工，特別是當炫目的 UI 概念和 Expo Go、route 慣例或平台支援互相衝突時。

嚴格遵守 route 慣例

這個 skill 最有價值的部分之一，就是它對 Expo Router 的紀律。下 prompt 時，請明確要求 agent 遵守 references/route-structure.md 裡的 route 規則：

• route 檔案只放在 app/
• 非 route 程式碼放在 app/ 外
• stack 使用 _layout.tsx
• 正確使用 [id].tsx 與 [...slug].tsx
• 確保 / 一定能解析到某個 route

這比看起來更重要。一般 prompt 很常把 route 檔與 component 檔混放在 app/ 內，長期下來會造成維護問題。

想要原生感，就要求原生控制項，不要自製 widget

如果你的目標是做出原生感，請明白要求 skill 儘量選用內建或平台原生控制項。參考檔案建議像是：

• Switch 用於二元設定
• segmented control 用於短的模式切換
• picker 用於較長的選項清單
• 透過 expo-symbols 使用 SF Symbols，而不是 FontAwesome 風格 icon packs

這些建議很實用，因為很多泛用 prompt 會預設生成過度客製的控制項，結果反而看起來不夠原生，也增加設計負債。

動畫重要時，優先選 Reanimated

這個 skill 在這點上立場很明確：只要是認真的 UI motion，就優先用 Reanimated v4，而不是 React Native 內建的 Animated API。如果你的畫面需要 entering、exiting、layout 或 scroll-driven animations，請直接講清楚。這能幫 agent 選到參考檔裡已支援的模式，也能避開比較弱的基礎動畫寫法。

把功能需求對應到正確的 reference 檔案

如果第一次輸出太發散，下面這張快速對照表很好用：

• animated transitions 或 gesture 細節打磨 → references/animations.md
• sliders、switches、segmented controls → references/controls.md
• modal card 類型體驗 → references/form-sheet.md
• gradients 與分層背景 → references/gradients.md
• icon 系統 → references/icons.md
• camera、video、audio、檔案儲存 → references/media.md
• app 資料夾設計與 params → references/route-structure.md
• header search 與 filtering → references/search.md
• local persistence → references/storage.md
• native tabs 與 migration 選擇 → references/tabs.md
• stack headers、menus、toolbar actions → references/toolbar-and-headers.md
• blur 與 glass effects → references/visual-effects.md

能提升輸出的實用 prompt 範例

比起：
「Make a tabbed app UI.」

更建議用：
「Apply building-native-ui to recommend whether this app should use Expo Router NativeTabs or JS tabs. The app has Home, Search, Inbox, and Profile. Prioritize native behavior on iOS, keep labels short, and explain any migration tradeoffs.」

比起：
「Add icons and animations.」

更建議用：
「Using building-native-ui, replace generic icon usage with SF Symbols where supported and add Reanimated-based entering and scroll-linked animations for the header. Keep the implementation maintainable and call out any platform fallbacks needed.」

這些 prompt 之所以更好，是因為它們會逼 agent 套用 skill 真正的決策規則，而不是輸出通用型程式碼。

building-native-ui skill 常見問題

building-native-ui 只適合 iOS 風格 app 嗎？

不完全是，但它確實明顯偏向 native-first 的 mobile UI，而且包含不少偏 iOS 的建議，例如 SF Symbols、Apple Zoom transitions、toolbar 模式，以及某些 sheet 行為。不過它對 Android 仍然有幫助，因為 route、animation、media、storage 與 Expo Router 相關指引一樣實用。

building-native-ui skill 對初學者友善嗎？

算友善，但前提是你已經懂基本的 React Native 或 Expo。這個 skill 比較偏實作導向，而不是概念教學，所以初學者若能一次只處理一個 screen 或一段 flow，並且一開始就提供版本與平台資訊，通常會得到更好的結果。

building-native-ui 比一般 prompt 強在哪裡？

主要優勢是它會考慮限制條件。一般 prompt 可能會虛構不對的 navigation structure、選到不夠原生的 icon system、忽略 Expo Router 慣例，或提議一些其實需要 custom build 的功能卻沒有提醒你。building-native-ui 會把這些選擇收斂到 Expo 參考資料支持的模式上。

什麼情況下不該使用 building-native-ui？

如果你的主要目標是以下其中一種，就可以跳過它：

• design-system-agnostic 的 React app
• web-first UI
• 高度客製品牌元件庫，而且幾乎不在意原生平台慣例
• framework-neutral 的 mobile 架構建議

在這些情境下，這個 skill 對 Expo 與原生模式的偏好，可能會顯得太窄。

building-native-ui 一定要搭配 Expo Router 嗎？

實務上若想得到最好結果，幾乎可以說是要。這個 skill 很多內容都是圍繞 Expo Router 概念組織的，例如 _layout.tsx、route folders、native tabs、form sheets 與 headers。你當然還是可以在 Expo Router 之外借用控制項或動畫建議，但它最強的價值還是在 app 確實採用那套 stack 的時候。

想把 building-native-ui 用好，一定要 custom dev build 嗎？

不一定。這個 skill 明確建議先試 Expo Go。但它提到的某些功能，的確可能需要更多條件：

• CSS gradients 需要 New Architecture
• Apple 特定 transitions 需要較新的 iOS 版本
• 某些 package 或 API 在 Expo Go 裡無法使用

如果你非常在意 build 的簡單度，請在 prompt 中明講「Expo Go only」。

如何改善 building-native-ui skill 的使用效果

先講限制條件，再談視覺美感

想提升 building-native-ui 結果，最快的方法就是先講清楚硬性限制，再要求 UI polish：

• 只能用 Expo Go，還是可接受 custom build
• SDK 版本
• 僅限 iOS，還是跨平台
• router 是否已安裝
• 是否已啟用 New Architecture

如果沒先交代，agent 很可能會挑一些看起來漂亮、但實際導入成本很高的模式。

要求它做決策，不只是產生程式碼

這個 skill 最有用的地方，是它能幫你在原生方案之間做選擇。比如：

• 「這裡應該用 segmented control 還是 tabs？」
• 「search 應該放在 header，還是放在內容區？」
• 「這裡該用 NativeTabs 嗎？」
• 「這個 visual effect 能不能留在 Expo Go 裡？」

和「直接幫我生成一個 screen」相比，這種決策型 prompt 通常會得到更好的輸出，因為這個 repo 最強的本質其實是 pattern guide。

提供目標 route tree

很多輸出品質其實取決於 navigation 是否清楚。即使只是粗略的 route tree，也很有幫助：

• /
• /search
• /items/[id]
• /settings/profile

這樣就足夠讓 skill 套用 Expo Router 慣例，並避免把檔案放得亂七八糟。

明確說出你要的互動模式

不要只說「做得高級一點」。請把互動講具體：

• scroll-reactive header
• modal form sheet with footer
• native search in header
• camera with flip and flash controls
• local saved state
• zoom-like image transition

這些描述都能直接對應到 skill 的 reference 檔，因此更容易導向可靠、可落地的實作選擇。

注意這些常見失敗模式

最常見的弱輸出包括：

• route 檔與 component 檔混放在 app/
• 推薦 custom icon packs，而不是 SF Symbols
• 在 Reanimated 更適合的地方用了舊動畫 API
• 提了不支援的功能，卻沒標出平台或 build 要求
• 過度設計控制項，明明用原生控制項會更簡單也更好

如果你看到這些問題，直接要求 agent 依照對應的 reference 檔重新修正。

請 agent 幫每個功能標註平台限制

一個很有價值的 refinement 步驟是：

「Revise this using building-native-ui and annotate each feature as Expo Go compatible, custom-build required, iOS-only, or New Architecture only.」

這能把一個只是看起來不錯的回答，轉成真正可評估是否採用的方案。

用分層迭代，而不是整份重寫

想得到最好結果，建議用分階段方式細修：

1. route structure
2. screen skeletons
3. control selection
4. navigation and headers
5. animation and visual polish
6. storage or media integration

這種分層工作流程很符合 skill 的組織方式，也更容易及早抓出錯誤假設。

要求落到具體檔案實作

如果第一版回答太空泛，就要求它直接改實際檔案：

• app/_layout.tsx
• app/index.tsx
• app/search.tsx
• app/items/[id].tsx
• components/ItemCard.tsx

這會迫使 agent 把 building-native-ui 當成 implementation guide，而不是只當成設計腦暴工具。

用 references 反過來檢驗不夠好的輸出

如果 agent 給你的還是泛泛建議，可以把它拉回 repo 依據：

• 「Rework this using references/route-structure.md conventions.」
• 「Switch this animation approach to the patterns in references/animations.md.」
• 「Replace the icons with the references/icons.md guidance.」
• 「Check whether this should be a form sheet based on references/form-sheet.md.」

這是最實際的做法，能讓你從這個 skill 拿到真正有資訊增益的內容，而不是淺層摘要。

用更好的最終 prompt 提升 building-native-ui 結果

一個夠強的 building-native-ui for Frontend Development 最終 prompt，可以長這樣：

「Use the building-native-ui skill to implement an Expo Router feature for a saved-recipes app. Target iOS and Android, but keep Expo Go compatibility if possible. I need a route structure, native-feeling tabs, a search experience, recipe detail pages, local persistence for favorites, and smooth header animations. Put only routes in app/, use Reanimated for motion, prefer SF Symbols where appropriate, and clearly mark any part that requires iOS-only APIs, New Architecture, or a custom build.」

這個 prompt 之所以有效，是因為它把產品目標、技術限制、route 紀律、UX 期待與審查標準一次講清楚。