building-native-ui

building-native-uiスキルの概要

building-native-uiスキルは何に使うのか

building-native-ui は、単なるクロスプラットフォームUIではなく、ネイティブアプリらしい完成度の高い Expo Router インターフェースを作るための実践ガイドです。React Native / Expo アプリで、AIエージェントに具体的なUI判断を任せたいときに特に役立ちます。たとえば、ルート構成、iOS風コントロール、ヘッダー、タブ、アニメーション、メディアフロー、視覚効果、プラットフォームを踏まえたUIパターンなどです。

どんな人が導入すべきか

この building-native-ui skill は、Expo や React Native で開発していて、汎用的なコンポーネントコード以上のものを必要としているフロントエンド開発者に向いています。特に、ナビゲーション、ネイティブコントロール、モーション、プラットフォーム慣習が重要なモバイルファースト製品を作るチームと相性が良いです。すでに Expo Router を使っている、またはこれから使う予定なら、単に「モバイルUIを作って」と投げるよりも、このスキルのほうがはるかに的確な方向性を出してくれます。

実際に解決してくれる仕事

多くのユーザーが building-native-ui を導入するのは、粗いプロダクトアイデアを、Expo 前提の実装可能なUI設計まで落とし込ませたいときです。価値があるのはサンプルコードそのものだけではありません。タブ、シート、検索、保存、メディア、アイコン、アニメーション、ルート整理といった論点で、Expo に合わない進め方を最初から避けやすくなる点にあります。

汎用UIプロンプトと何が違うのか

このスキルの最大の差別化ポイントは、Expo 固有の前提と制約が織り込まれていることです。エージェントを次の方向へ自然に導きます。

• Expo Router のファイル配置とレイアウト規約
• ネイティブらしい iOS コントロールと SF Symbols
• 古いアニメーション手法ではなく Reanimated ベースのモーション
• Expo Go で動く範囲と、custom build が必要になる境界
• tabs、search、media、gradients、zoom transitions、visual effects 向けの絞られた参照ドキュメント

導入前に最も重要なこと

building-native-ui for Frontend Development を使う前に知っておきたいのは、このスキルには明確な思想があるということです。汎用的なクロスプラットフォームUIキットよりネイティブパターンを優先し、Expo と相性の良い API を好みます。また、iOS限定機能、New Architecture 前提、SDK 要件など、バージョンやプラットフォームに依存する機能も含まれています。ネイティブらしい高品質な体験を狙うなら強みになりますが、Web との共通化を重視したデザインシステムや、フレームワーク非依存のアプリ土台づくりにはやや不向きです。

building-native-uiスキルの使い方

building-native-uiスキルをインストールする

エージェントが Skills をサポートしている場合は、Expo skills リポジトリから追加します。

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

すでに環境内で Expo skills repo が使えるなら、plugins/expo/skills/building-native-ui から building-native-ui スキルを読み込んでください。

最初に読むべきファイル

素早く使い始めたいなら、最初から全部を流し読みしないほうが得策です。次の順で読むのがおすすめです。

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設計の進み方に沿っています。まずアプリ構造、その次にナビゲーション、最後に画面の挙動や仕上げを詰める流れです。

プロンプト前に導入条件を確認する

適切な building-native-ui install 判断は、実行環境の制約に大きく左右されます。このスキルは、custom build に進む前にまず Expo Go を試すことを明示的に勧めています。というのも、参照される機能の中にはどこでも使えるわけではないものがあるからです。

• CSS gradients は React Native New Architecture が必要で、Expo Go では使えません
• Apple Zoom transitions は iOS 18+ が前提です
• toolbar や search の一部パターンは iOS 限定です
• form sheet の例は Expo Router の stack 構成が必要で、細かな点では新しめの Expo SDK が求められます

アプリを完全に Expo Go 内で動かす必要があるなら、その条件をプロンプトに必ず書いてください。書かないと、エージェントが development build 前提の機能を選ぶ可能性があります。

building-native-uiに渡す入力を適切にする

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/.”

後者のように具体的だと、このスキルは適切なコントロールを選び、非対応 API を避け、ルート規約にも沿った提案をしやすくなります。

大まかなアイデアを完成度の高いプロンプトにする

building-native-ui guide を安定して使うためのプロンプトテンプレートは次のとおりです。

• プロダクトの文脈
• 対象プラットフォーム
• 実行時制約
• 画面一覧または route tree
• インタラクションの詳細
• ビジュアルの方向性
• 欲しい出力形式

例:

“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.”

このプロンプトが有効なのは、単に JSX を生成させるのではなく、このスキルに「どう設計すべきか」を判断させているからです。

building-native-uiの推奨ワークフローに沿って進める

実運用では、building-native-ui usage は次の順で使うのが最も安定します。

1. まず route と navigation の構造を決める
2. 次に各画面で使うネイティブコントロールを決める
3. 構造が固まってから motion と headers を足す
4. persistence、media、search はフローが明確になってから加える
5. 最後に、custom build や platform-only の要件を洗い出させる

この進め方をすると、見た目重視のアイデアが Expo Go、route 規約、プラットフォーム対応とぶつかって手戻りになるのを防ぎやすくなります。

ルート規約は厳密に守る

このスキルの価値が特に高い部分のひとつが、Expo Router の規律です。プロンプトでは、references/route-structure.md のルールに従うよう明示してください。

• route ファイルは app/ に置く
• route 以外のコードは app/ の外に出す
• stack には _layout.tsx を使う
• [id].tsx と [...slug].tsx を正しく使い分ける
• / が必ず route に解決されるようにする

これは見た目以上に重要です。汎用プロンプトだと、app/ の中に route ファイルと UI コンポーネントが混在した構成を出しがちで、後から保守しづらくなります。

カスタムウィジェットではなくネイティブコントロールを指定する

ネイティブ感を重視するなら、可能な限り組み込みまたはプラットフォームネイティブなコントロールを選ばせるよう、明示して依頼してください。参照ファイルでは次のような指針が示されています。

• 2値設定には Switch
• 短いモード切り替えには segmented control
• 選択肢が長い場合は picker
• FontAwesome 系のアイコンパックではなく expo-symbols 経由の SF Symbols

この指針が有効なのは、一般的なプロンプトだと過度に作り込んだカスタムコントロールに寄りやすく、結果的にネイティブ感を損ない、設計負債も増えやすいからです。

モーションが重要なら Reanimated を優先する

この点でこのスキルはかなり明確です。本格的なUIモーションには、React Native 標準の Animated API より Reanimated v4 を使う前提で考えます。画面に entering、exiting、layout、scroll-driven animation が必要なら、その要件をプロンプトに直接書いてください。そうすると、参照ファイルに沿った実装パターンを選びやすくなり、弱いベースラインのアニメーションコードに流れにくくなります。

機能アイデアを正しい参照ファイルに対応づける

最初の出力が広すぎると感じたら、次のリポジトリ読解マップが役立ちます。

• 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、file saving → references/media.md
• app フォルダ設計と params → references/route-structure.md
• header search と filtering → references/search.md
• ローカル保存 → references/storage.md
• native tabs と移行判断 → references/tabs.md
• stack headers、menus、toolbar actions → references/toolbar-and-headers.md
• blur や glass effect → references/visual-effects.md

出力品質を上げる実践的なプロンプト例

次のように書くより:

“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.”

こうしたプロンプトが効くのは、エージェントに汎用コードを吐かせるのではなく、このスキルが持つ実際の判断ルールを使わせられるからです。

building-native-uiスキル FAQ

building-native-uiはiOS風アプリ専用ですか？

いいえ。ただし、ネイティブファーストのモバイルUIに強く寄っており、SF Symbols、Apple Zoom transitions、toolbar パターン、一部の sheet 挙動など、iOS 寄りの推奨がいくつか含まれます。それでも Android で無意味になるわけではありません。route、animation、media、storage、Expo Router 周りの指針は Android でも十分役立ちます。

building-native-uiスキルは初心者向けですか？

はい。ただし、React Native または Expo の基本がわかっていることが前提です。このスキルは概念説明より実装寄りなので、初心者ほど一度に全部を聞くより、1画面・1フロー単位で依頼し、最初にバージョンと対象プラットフォームを明示するほうが成果を出しやすいです。

building-native-uiは通常のプロンプトより何が優れていますか？

最大の利点は、制約を踏まえた出力になることです。通常のプロンプトだと、ナビゲーション構造を誤る、ネイティブらしくないアイコンシステムを選ぶ、Expo Router の規約を無視する、custom build が必要な機能を警告なしで勧める、といったことが起こりがちです。building-native-ui は、そうした選択肢を Expo の参照に基づく現実的なパターンへ絞り込みます。

どんな場合はbuilding-native-uiを使わないほうがよいですか？

主目的が次のいずれかなら、見送ったほうがよいです。

• デザインシステム非依存の React アプリ
• Web ファーストの UI
• ネイティブ慣習をあまり重視しない、完全カスタムのブランドコンポーネントライブラリ
• フレームワークに依存しないモバイルアーキテクチャ設計

こうしたケースでは、このスキルの Expo / ネイティブ寄りのバイアスが狭すぎる可能性があります。

building-native-uiはExpo Router必須ですか？

実用上は、ベストな結果を得るならほぼ必須です。スキルの大部分が _layout.tsx、route folders、native tabs、form sheets、headers など Expo Router の概念を軸に整理されています。Expo Router なしでも control や animation の知見を一部流用することはできますが、最も大きな価値はそのスタックを前提にしたときに出ます。

このスキルを使いこなすにはcustom dev buildが必要ですか？

必ずしも必要ではありません。このスキル自体、まず Expo Go を試すことを勧めています。ただし、スキルが参照する機能の中には追加条件があるものもあります。

• CSS gradients には New Architecture が必要
• Apple 固有の transitions には新しめの iOS バージョンが必要
• Expo Go では利用できない packages や APIs がある

ビルドの単純さを優先したいなら、プロンプトに “Expo Go only” と明記してください。

building-native-uiスキルを改善する方法

見た目より先に制約を書く

building-native-ui の結果を最短で良くする方法は、UI の見栄えを頼む前に、厳しい制約条件を先に書くことです。

• Expo Go only なのか、custom build 可なのか
• SDK バージョン
• iOS 専用か、クロスプラットフォームか
• router 導入済みかどうか
• New Architecture を有効にしているか

ここが曖昧だと、見栄えは良くても導入コストの高い案をエージェントが選びやすくなります。

コード生成だけでなく判断を求める

このスキルは、ネイティブな選択肢の中から何を採るべきかを判断させるときに最も力を発揮します。たとえば次のような聞き方です。

• “Should this be segmented control or tabs?”
• “Should search live in the header or in-content?”
• “Should I use NativeTabs here?”
• “Can this visual effect stay in Expo Go?”

単に「画面を生成して」と頼むより、こうした判断ベースの依頼のほうが良い結果になりやすいです。リポジトリ自体が、コード生成器というよりパターンガイドとして強いからです。

目標のroute treeを渡す

出力品質は、ナビゲーションの明確さでかなり変わります。ざっくりでも route tree があると役立ちます。

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

これだけでも、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

こうした言い回しは、このスキルの参照ファイルと対応しやすく、実装に落ちる提案が返りやすくなります。

よくある失敗パターンを確認する

弱い出力でよくあるのは次のパターンです。

• route ファイルと component ファイルが app/ 内で混在している
• SF Symbols ではなくカスタム icon packs を勧めている
• Reanimated が適切な場面でも古い animation API を使っている
• 非対応機能なのに platform や build 条件を明示していない
• ネイティブコントロールで十分な場面で過剰に作り込んでいる

こうした兆候があれば、該当する参照ファイルに照らして修正するようエージェントへ依頼してください。

プラットフォーム制約を注記させる

価値の高い仕上げ手順として、次のように頼むのが有効です。

“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

このレイヤー型の進め方は、スキルの構成とも噛み合っており、初期段階での誤った前提に気づきやすくなります。

ファイル単位の実装を依頼する

最初の回答が抽象的すぎる場合は、実ファイルを指定して修正依頼してください。

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

こうすると、エージェントに building-native-ui をデザイン相談ではなく実装ガイドとして使わせやすくなります。

参照ファイルを使って弱い出力を突き返す

エージェントが汎用的な助言しか返してこない場合は、リポジトリに引き戻してください。

• “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.”

浅い要約ではなく、実際に情報量のある出力を引き出すうえで、これが最も実践的なやり方です。

より良い最終プロンプトでbuilding-native-uiの結果を伸ばす

building-native-ui for Frontend Development に対する強い最終プロンプトは、次のような形です。

“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.”

このプロンプトが有効なのは、プロダクト目標、技術的制約、route の規律、UX の期待値、レビュー基準が一か所にまとまっているからです。