diff --git a/vega-multi-tv-migration/LICENSE b/LICENSE
similarity index 97%
rename from vega-multi-tv-migration/LICENSE
rename to LICENSE
index ed3afcb..e957867 100644
--- a/vega-multi-tv-migration/LICENSE
+++ b/LICENSE
@@ -1,6 +1,6 @@
MIT License
-Copyright (c) 2025 Vega Skills
+Copyright (c) 2025 Amazon
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
diff --git a/README.md b/README.md
index 499af7e..1703969 100644
--- a/README.md
+++ b/README.md
@@ -7,6 +7,7 @@ A collection of **Agent Skills** — structured knowledge packages that give AI
| Skill | Description |
|-------|-------------|
| [vega-multi-tv-migration](vega-multi-tv-migration/SKILL.md) | Migrate Vega OS (Fire TV) apps to multi-platform React Native monorepo supporting Android TV, Apple TV, and more |
+| [rn-tv-ui-best-practices](rn-tv-ui-best-practices/SKILL.md) | React Native TV UI best practices for tvOS, Android TV, Fire TV, and Vega OS — focus management, layouts, typography, and remote/D-pad navigation |
## Installation
@@ -24,6 +25,7 @@ Install a specific skill:
```bash
npx skills add AmazonAppDev/devices-agent-skills --skill vega-multi-tv-migration
+npx skills add AmazonAppDev/devices-agent-skills --skill rn-tv-ui-best-practices
```
For more options, see the [skills CLI documentation](https://skills.sh/docs/cli).
diff --git a/rn-tv-ui-best-practices/README.md b/rn-tv-ui-best-practices/README.md
new file mode 100644
index 0000000..1bd9459
--- /dev/null
+++ b/rn-tv-ui-best-practices/README.md
@@ -0,0 +1,16 @@
+# rn-tv-ui-best-practices
+
+An agent skill for building React Native TV applications with best-practice UI patterns covering focus management, navigation, layout, typography, color, and keyboard handling.
+
+## Attribution
+
+Based on "The Ultimate Guide to React Native TV Development" (2025), co-authored by Amazon and Callstack.
+
+Book: https://reactnativetv.com
+
+## Authors
+
+- Giovanni Laquidara — [@giolaq](https://github.com/giolaq)
+- Karol Latusek — [@Zahoq](https://github.com/Zahoq)
+- Anisha Malde — [@anishamalde](https://github.com/anishamalde)
+- Michal Pierzchala — [@thymikee](https://github.com/thymikee)
diff --git a/rn-tv-ui-best-practices/SKILL.md b/rn-tv-ui-best-practices/SKILL.md
new file mode 100644
index 0000000..98cebde
--- /dev/null
+++ b/rn-tv-ui-best-practices/SKILL.md
@@ -0,0 +1,77 @@
+---
+name: rn-tv-ui-best-practices
+description: React Native TV UI best practices for tvOS, Android TV, Fire TV, and Vega OS (including react-native-tvos). Use whenever building, reviewing, or debugging a TV / set-top box / streaming (OTT) app. Covers focus management (TVFocusGuideView, hasTVPreferredFocus, trapFocus, requestTVFocus, useTVEventHandler, focus loss/jumping); D-pad / RCU / spatial navigation; swimlanes, hero banners, drawers, tabs, modals, overscan/safe zones; TV typography, contrast, HDR; remote-driven text or voice input.
+---
+
+# React Native TV UI Best Practices
+
+Build polished React Native TV apps across tvOS, Android TV, Fire TV, Vega OS.
+
+## When to Apply
+
+Use when user is:
+- Building or reviewing TV UI components
+- Debugging focus/navigation issues
+- Designing layouts for TV (10-foot experience)
+- Choosing typography or color for TV displays
+- Implementing keyboard/text input on TV
+
+## When NOT to Apply
+
+- Mobile-only React Native apps (no TV target)
+- Web apps not targeting TV platforms
+- General React Native performance issues unrelated to TV UX
+
+## Quick Decision Tree
+
+```
+Starting a new TV app or doing a broad design review?
+└─ Read in order: references/ten-foot-experience.md → references/layout-patterns.md → references/typography-and-color.md
+
+Focus / navigation issue?
+├─ Not sure which approach to use → references/navigation-and-focus.md (Focus Management Hierarchy)
+├─ Focus doesn't start where expected → references/navigation-and-focus.md (hasTVPreferredFocus)
+├─ Focus jumps unexpectedly → references/navigation-and-focus.md (Debugging Focus Issues + Common Focus Problems)
+├─ Focus disappears (loader/empty/error state) → references/navigation-and-focus.md (Gotchas)
+├─ Need modal/overlay focus trap → references/navigation-and-focus.md (Focus Traps)
+├─ Back button not restoring focus → references/navigation-and-focus.md (Back Navigation and Focus Restoration)
+├─ Need to move focus programmatically → references/navigation-and-focus.md (Imperative Focus)
+└─ Cross-platform differences (tvOS vs Android TV vs Vega) → references/navigation-and-focus.md (Platform Focus Engines)
+
+Building screens/components?
+├─ Drawer / tabs / modals → references/layout-patterns.md (Navigation Patterns)
+├─ Cards / rows / swimlanes / hero banners → references/layout-patterns.md (Common Components)
+├─ Buttons / overlays / details panels → references/layout-patterns.md (Common Components)
+└─ Safe zones / overscan / multi-aspect-ratio → references/layout-patterns.md (Layout and Safe Zones)
+
+Visual design?
+├─ Font sizes / line height / letter spacing → references/typography-and-color.md (Typography)
+├─ Color / contrast / accessibility → references/typography-and-color.md (Color and Contrast)
+├─ HDR / bright vs dim vs dark room → references/typography-and-color.md (HDR Considerations + Ambient Light Adaptation)
+├─ Text over images or video → references/typography-and-color.md (Text Over Images)
+└─ Animation / motion / feedback timing → references/ten-foot-experience.md (Feedback, Motion, and Rhythm)
+
+Text input / search / auth?
+├─ Reduce typing burden → references/keyboard-handling.md (Input Minimization)
+├─ System keyboard + RCU events → references/keyboard-handling.md (Built-In System Keyboard)
+├─ Custom keyboard UI → references/keyboard-handling.md (Custom Keyboard)
+├─ Voice input → references/keyboard-handling.md (Voice Input)
+└─ Phone-as-input / QR auth → references/keyboard-handling.md (Mobile Companion Apps)
+
+Pre-ship review / sanity check?
+├─ Focus traps & back navigation → references/navigation-and-focus.md (Verify before ship)
+├─ Safe zones & aspect ratios → references/layout-patterns.md (Verify before ship)
+├─ Typography sizes & contrast → references/typography-and-color.md (Verify before ship)
+├─ Animation timing & input latency → references/ten-foot-experience.md (Verify before ship)
+└─ Couch test (real device, real distance, real remote) → references/ten-foot-experience.md (Couch Sanity Checks)
+```
+
+## References
+
+| File | When to Load |
+|------|--------------|
+| [ten-foot-experience.md](references/ten-foot-experience.md) | UX design decisions, remote interaction patterns, animation/motion |
+| [layout-patterns.md](references/layout-patterns.md) | Building screens, navigation structure, component patterns, safe zones |
+| [typography-and-color.md](references/typography-and-color.md) | Setting font sizes, choosing colors, ensuring readability at distance |
+| [navigation-and-focus.md](references/navigation-and-focus.md) | Focus bugs, TVFocusGuideView, focus traps, back navigation, platform differences |
+| [keyboard-handling.md](references/keyboard-handling.md) | Search screens, login forms, any text input UI |
diff --git a/rn-tv-ui-best-practices/references/keyboard-handling.md b/rn-tv-ui-best-practices/references/keyboard-handling.md
new file mode 100644
index 0000000..b6ffaa6
--- /dev/null
+++ b/rn-tv-ui-best-practices/references/keyboard-handling.md
@@ -0,0 +1,130 @@
+# Keyboard Handling
+
+Input patterns for React Native TV apps. D-pad typing is the slowest interaction on TV — minimize it first, then optimize what remains.
+
+## Input Minimization (Priority #1)
+
+Before building keyboard UI, reduce the need for typing:
+
+- Pre-filled options and smart defaults (past searches, popular searches).
+- Voice input via system dictation or `react-native-voice`.
+- Real-time validation to minimize corrections.
+- Maintain input history so users don't retype.
+- QR code authentication (TV shows QR, phone scans to authenticate).
+- Mobile companion apps for complex input (auth, casting, search).
+
+## Built-In System Keyboard
+
+Trigger by rendering a standard `TextInput`. Keyboard appears automatically on focus.
+
+### Platform Differences
+
+- **Android TV (Gboard)**: Grid-based, arrow-navigated. Pops up center/bottom, covers UI beneath.
+- **Apple tvOS**: Row-based, Siri Remote swipe-friendly. Also supports iOS Remote app and dictation.
+
+### Keyboard Types
+
+Use the appropriate type to minimize friction:
+
+- `default`: Full autocomplete & autocorrect
+- `email-address`: @, ., .com shortcuts; autocorrect off
+- `numeric`: Numbers only
+- `number-pad`: Digits only (PINs, codes)
+- `decimal-pad`: Numeric with decimal point
+- `phone-pad`: Digits + #, +
+- `url`: Includes /, ., .com shortcuts
+- Password: Use `secureTextEntry` prop (not a keyboardType)
+
+**iOS-only types:** `ascii-capable`, `ascii-capable-number-pad`, `name-phone-pad`, `numbers-and-punctuation`, `twitter`, `web-search`
+
+**Android-only:** `visible-password`
+
+### Enhancing with RCU Events
+
+Map remote buttons to keyboard actions using `useTVEventHandler`:
+
+```jsx
+import { useTVEventHandler } from 'react-native';
+
+const SearchScreen = () => {
+ const inputRef = useRef(null);
+ const inputValueRef = useRef('');
+
+ const handleSearch = () => {
+ // Call search API with inputValueRef.current
+ };
+
+ useTVEventHandler((evt) => {
+ if (evt.eventType === 'play') {
+ handleSearch(); // "play" button = submit search
+ }
+ });
+
+ return (
+
+ { inputValueRef.current = text; }}
+ onSubmitEditing={handleSearch}
+ />
+
+ );
+};
+```
+
+`onSubmitEditing` fires when the text input's submit button is pressed, which is the most common trigger. Depending on your UI, you may also want `onBlur` (submit when focus leaves the field) or to listen for events from surrounding `Pressable` / `Touchable` components (e.g., a dedicated "Search" button next to the input). Pick whichever matches how users actually complete the action in your flow.
+
+## Custom Keyboard
+
+When the system keyboard covers important UI or you need more control:
+
+### Implementation Pattern
+
+```jsx
+const [showKeyboard, setShowKeyboard] = useState(false);
+
+return (
+
+
+ setShowKeyboard(true)}
+ showSoftInputOnFocus={false} // Suppress default keyboard
+ />
+
+ {showKeyboard && }
+
+);
+```
+
+### Custom Keyboard Considerations
+
+- Set `showSoftInputOnFocus={false}` to suppress the default keyboard.
+- Each key button needs two states: **focused** and **selected** (user skips over buttons to reach target letter).
+- Wire each button's output to the TextInput value.
+- Focus management within the keyboard grid follows standard TV navigation rules.
+
+### Tradeoff
+
+Custom keyboards give full UI control but users must learn your specific layout. The system keyboard is familiar even if less pretty. Only build custom when the system keyboard genuinely blocks critical UI (like YouTube's search with results visible below).
+
+## Voice Input
+
+- **With system keyboard**: Already handles dictation. Just wait for system to fill the TextInput.
+- **With custom keyboard**: Need native code. Use `react-native-voice` library.
+- Remember: adding voice requires microphone + speech recognition permissions.
+
+## Mobile Companion Apps
+
+Companion apps (YouTube, Netflix, Spotify pattern) offload input to the phone:
+- Authentication via QR code (TV shows code, phone scans, backend binds devices via shared token).
+- Search input typed on phone keyboard, sent to TV over local network.
+- Media casting from phone to TV (no TV-side login needed).
+
+## Key Rules
+
+1. Prioritize input minimization — every keystroke saved is UX gained.
+2. Use appropriate keyboard types (don't show full keyboard for a PIN).
+3. Maintain input history.
+4. Enable voice input where possible.
+5. Consider companion app flows for complex authentication.
diff --git a/rn-tv-ui-best-practices/references/layout-patterns.md b/rn-tv-ui-best-practices/references/layout-patterns.md
new file mode 100644
index 0000000..843b8fb
--- /dev/null
+++ b/rn-tv-ui-best-practices/references/layout-patterns.md
@@ -0,0 +1,203 @@
+# Layout Patterns and Common Components
+
+Structural patterns for TV interfaces: navigation, components, safe zones, and spacing.
+
+## Why Structure Matters
+
+Layout patterns reduce cognitive effort. Users focus on content rather than figuring out navigation. Every button press on a remote takes deliberate time, so predictability is a valuable feature.
+
+A well-designed layout provides three things:
+1. **Orientation**: Where am I?
+2. **Context**: What can I do here?
+3. **Momentum**: Where can I go next?
+
+These patterns also create shared vocabulary for teams — designers, developers, and testers can communicate using the same terms (hero, swimlane, drawer, focus trap), turning complex interfaces into manageable, reusable systems.
+
+## Gotchas
+
+- Many TVs still apply **overscan** (5-10% cropped from edges). Keep all interactive elements inside a 5-10% safe zone margin. Only backgrounds/hero images extend to edge.
+- Drawer open/close transitions must complete in **under 200ms**. Modal transitions ~150ms. Longer = sluggish.
+
+## Critical Values (Guidelines)
+
+Recommended starting points — adapt to your app's specific needs and user testing.
+
+```
+Safe Zone: 5-10% margin on all sides
+Card Focus Scale: 3-5% larger
+Row Vertical Padding: 1.5x card height
+Drawer Items: 5-7 maximum
+Tabs: 3-5 maximum
+Animation Timing: Drawer < 200ms | Modal ~150ms
+```
+
+## Navigation Patterns
+
+### Drawer Navigation (Global)
+
+Left-edge menu for main sections. Acts as the app's structural backbone.
+
+**Behavior:**
+- Opens when user presses left from leftmost focusable area (or menu/back shortcut).
+- Dims the rest of the screen slightly to signal context shift.
+- Focus trapped inside until user exits or selects.
+- On close, restore focus to previously active element.
+
+**Rules:**
+- 5-7 items maximum.
+- Clear labels (icons + text for clarity).
+- Open/close transition: under 200ms.
+
+```jsx
+
+
+```
+
+### Tab Navigation (Local)
+
+Organizes content within a single section (not between sections). Place beneath hero banner or above first content row.
+
+**Rules:**
+- 3-5 tabs maximum.
+- Current tab visually obvious (bold, underline, highlight).
+- Left/right to switch tabs, down to enter content rows below.
+- Tabs as primary navigation only works for apps with limited sections. Complex apps need a drawer.
+
+```jsx
+
+ setCategory('popular')} />
+ setCategory('new')} />
+ setCategory('favorites')} />
+
+```
+
+### Modal Navigation
+
+Temporary focused interruptions (confirmations, playback controls, detail views).
+
+**Rules:**
+- Trap focus inside. Dim/blur background.
+- Restore focus to triggering element on close.
+- Transitions ~150ms. Never stack multiple modals.
+- Consistent placement: fade or scale from center.
+
+```jsx
+
+ Are you sure you want to remove this item?
+
+```
+
+### Navigation Predictability
+
+- Consistent directional logic across all screens.
+- Always provide a visible focus state.
+- Never move focus off-screen without scrolling the new element into view.
+- Keep focusable element count reasonable — don't force excessive button presses.
+
+## Common Components
+
+### Cards and Content Tiles
+
+Each card = one piece of content. Entry points, not summaries.
+
+- Focus feedback: subtle scaling (3-5%), glow or drop shadow for depth.
+- Include: title, thumbnail, one secondary detail (runtime or badge).
+- Adequate spacing so focus indicators don't overlap adjacent cards.
+- Don't cram too much info — show detail on focus or in a dedicated view.
+
+```jsx
+ setHighlight(id)}
+ onPress={() => openDetails(id)}
+/>
+```
+
+### Rows / Carousels / Swimlanes
+
+Horizontal rows of cards — the signature streaming app pattern.
+
+- Render only visible items (FlatList or VirtualizedList).
+- Left/right within a row, up/down between rows.
+- Auto-scroll when focus reaches row edge.
+- Label each row with headers ("Recommended", "New Releases") visible even when card has focus.
+- Resist overfilling — fewer distinct categories > overwhelming options.
+
+```jsx
+
+ {data.map((item) => )}
+
+```
+
+### Hero Headers
+
+Large visual at top of screen. Anchors attention, provides a starting point for focus.
+
+- Feature a single piece of content (show, event, collection).
+- Strong composition — fills space naturally, not cropped.
+- Text readable against backgrounds (use gradients or blurs).
+- Single primary action: "Play", "Resume", or "More Info".
+- Smooth transition to first content row (subtle fades or parallax).
+
+### Buttons and Overlays
+
+- Focused buttons: contrast, outlines, or subtle scaling.
+- Group related actions ("Play" + "More Info") with consistent spacing.
+- Labels: short verbs ("Play", "Retry", "Cancel").
+- Overlays fade in quickly, fade out after inactivity period.
+- Predictable focus order within overlays (left to right).
+- Dim content beneath overlays but don't hide completely.
+
+### Details and Info Panels
+
+- Slide in or overlay smoothly — maintain continuity, don't replace entire screen.
+- Back button always returns to where user started (not a default state).
+
+## Layout and Safe Zones
+
+### Overscan
+
+Many TVs still crop the outer 5-10% of the layout.
+
+- **Essential elements** (text, logos, buttons, nav): inside 5-10% safe zone margin on all sides.
+- **Backgrounds and hero images**: can extend to screen edge.
+- Use gridlines or invisible bounding boxes during development to visualize safe boundaries.
+
+**Verify before ship:** every interactive or text element sits inside the 5-10% safe zone on all four edges. Easiest check is to overlay a debug rectangle at 5% inset and confirm nothing critical pokes outside it.
+
+### Multiple Screen Sizes
+
+TVs range from 32" to 85"+. Never rely on fixed pixel values.
+
+- Use relative units (percentages, viewport-relative) for spacing and positioning.
+- Anchor interface regions to screen edges (top, left, right), not absolute coordinates.
+- Keep critical content centered — peripheral areas are less reliable.
+- Test on multiple display modes (Standard, Cinema, Game, HDR).
+
+### Aspect Ratios
+
+- Design around 16:9 base grid, adaptable to 21:9 without breaking.
+- Don't position titles or CTAs close to corners.
+- For backgrounds, choose compositions that stay balanced when cropped.
+
+**Verify before ship:** render the screen at both 16:9 and 21:9 and confirm nothing clips, reflows awkwardly, or pushes a CTA off-screen. Ultrawide displays are a small share of the install base but they expose layout assumptions that look fine at 16:9.
+
+### Spacing
+
+- Align to a grid system (12-column or 8-column).
+- Vertical rhythm between rows: 1.5x card height for padding.
+- Invisible baselines for text/components keep focus transitions smooth.
+- Don't overfill the screen. TV interfaces work best when calm, not dense.
+
+## Layout-Specific Checks
+
+A few layout-specific things that only matter once the structural patterns above are in place:
+
+- Overlays scale correctly on both HD and 4K (test at native and upscaled output).
+- Test in real living room conditions: lights on/off, varying distances. TV environments differ enough from a desk monitor that surprises only surface there.
diff --git a/rn-tv-ui-best-practices/references/navigation-and-focus.md b/rn-tv-ui-best-practices/references/navigation-and-focus.md
new file mode 100644
index 0000000..e719c44
--- /dev/null
+++ b/rn-tv-ui-best-practices/references/navigation-and-focus.md
@@ -0,0 +1,236 @@
+# Navigation and Focus
+
+Focus management for React Native TV apps. The most common source of TV UX bugs.
+
+## The Focus Tree Mental Model
+
+Each platform builds a **focus tree**: an internal map of all focusable elements. Every `Pressable`, `Touchable`, or `TextInput` becomes a node, connected to its neighbors by directional relationships. When a key event comes in, the focus engine consults this tree to determine which node to highlight next.
+
+React Native TV mirrors this concept with a unified set of focus APIs so you can build predictable flows without diving into native code. Understanding this tree structure helps debug — if focus jumps unexpectedly, the tree's structure (element positions, visibility, mount status) is what's broken.
+
+## Platform Focus Engines
+
+Each platform handles focus differently. Understand these differences before writing focus code.
+
+### tvOS (Inferred Focus Engine)
+
+Apple's engine is spatial and physics-based:
+- Searches for focusable views in the pressed direction based on spatial proximity.
+- Treats clusters of related items as "focus islands."
+- Expects clean grid/alignment — misaligned or overlapping elements cause unexpected jumps.
+- Supports diagonal movement and inertia-based swipes from Siri Remote.
+
+### Android TV (Explicit Directional Model)
+
+More flexible, more manual:
+- Focus moves to nearest visible item along pressed direction (Cartesian).
+- Override with `nextFocusUp`, `nextFocusDown`, `nextFocusLeft`, `nextFocusRight`.
+- Tolerates less regular layouts, but focus can disappear entirely if no valid target exists.
+
+**Note:** `nextFocus*` props are Android-only, ignored on tvOS. Don't use in cross-platform codebases.
+
+### Vega OS
+
+Cartesian focus management like Android TV.
+
+## Focus Management Hierarchy
+
+Apply in this order. Each level is a fallback when the previous doesn't work:
+
+### 1. Inferred Behavior (Default — Always Try First)
+
+Design your UI so the focus engine handles everything automatically:
+
+- Align and space elements logically so directional presses resolve to intended neighbor.
+- Avoid dead zones (gaps in focusable elements cause unpredictable jumps).
+- Group related UI into containers ("focus islands").
+- On tvOS: account for diagonal/inertia. On Android TV: strict up/down/left/right.
+
+```jsx
+
+ {items.map((item) => (
+ select(item)}
+ onFocus={() => setFocusedItem(item.id)}
+ >
+
+
+ ))}
+
+```
+
+**If focus behaves strangely, adjust the layout first — don't add more code.**
+
+### 2. TVFocusGuideView (Complex Layouts)
+
+Bridges areas that don't naturally connect. Groups focusable elements so the system remembers last focused child and redirects focus intelligently.
+
+```jsx
+
+
+
+
+
+
+```
+
+- If you need many guides, your layout probably needs simplifying.
+- Keep destination refs up to date — stale refs cause focus loss.
+
+### 3. hasTVPreferredFocus (Initial Focus)
+
+Tells the engine "start here" when a screen first loads.
+
+```jsx
+
+ Start Watching
+
+```
+
+- Never set on multiple elements in the same view (unpredictable results).
+- Delay focus until data-dependent UI has rendered.
+
+### 4. Focus Traps (Modals/Overlays)
+
+Use `trapFocus*` props on `TVFocusGuideView` to contain focus inside temporary surfaces:
+
+```jsx
+
+
+
+ Confirm
+
+
+
+```
+
+**Platform note:** `trapFocus*` is built into the framework on `react-native-tvos` (tvOS and Android TV). Other platforms — notably web-based TVs like Tizen and webOS — don't expose this natively. On those, use a spatial navigation library (e.g., `@noriginmedia/norigin-spatial-navigation`) with equivalent concepts like `isFocusBoundary` and `saveLastFocusedChild`. Consider wrapping both in a shared `FocusBoundary` abstraction so the same patterns hold across your codebase.
+
+**Verify before ship:** every modal and overlay traps focus inside itself. Open each one, mash the D-pad in all four directions, and confirm focus never escapes to elements behind the dim layer.
+
+### 5. Imperative Focus (Last Resort Only)
+
+Use `requestTVFocus()` (preferred on react-native-tvos) or `.focus()`:
+
+```js
+useEffect(() => {
+ if (lastFocusedRef.current?.requestTVFocus) {
+ lastFocusedRef.current.requestTVFocus();
+ } else if (lastFocusedRef.current?.focus) {
+ lastFocusedRef.current.focus();
+ }
+}, [isActiveScreen]);
+```
+
+**Risks:**
+- If referenced element is unmounted or ref is stale, focus call fails silently.
+- Overuse signals your layout/navigation is too brittle.
+- Prefer focusing a stable container (TVFocusGuideView wrapping a section) over a granular element.
+
+**If you must use imperative focus, target a stable container.** Focusing a `TVFocusGuideView` wrapping a section is safer than focusing a granular element — the guide acts as a predictable anchor and survives child re-renders or unmounts that would otherwise leave a direct ref stale.
+
+## Back Navigation and Focus Restoration
+
+### Focus Restoration
+
+- `TVFocusGuideView` manages last-focused element internally per scope.
+- When user returns to a section, the same element is automatically refocused.
+- For complex layouts, nest multiple guides — each remembers focus for its region.
+- Use `hasTVPreferredFocus` once within a guide for first-time default focus; the guide handles subsequent restores.
+
+### Overlays/Modals
+
+When an overlay closes, focus must return to the element that opened it:
+
+```jsx
+function ConfirmModal({ visible, onClose, returnRef }) {
+ return visible ? (
+
+
+ Confirm
+
+ { onClose(); returnRef?.current?.focus(); }}>
+ Cancel
+
+
+ ) : null;
+}
+```
+
+### Back Button Consistency
+
+Each back press should move back one layer and restore previous focus state. Same behavior everywhere — modals, drawers, screens.
+
+**Verify before ship:** for every navigation transition, press back and confirm focus lands on the element that triggered the forward step — not a default tile, not nowhere. This is the bug users notice fastest because it forces them to re-find their place with the D-pad.
+
+## Debugging Focus Issues
+
+### Visualize Focus
+
+- **tvOS**: Simulator → Debug > Toggle Focus Rectangle.
+- **Android TV**: `adb logcat` and filter for focus changes.
+- **Instrument directly**: Add visible borders on focus for debugging.
+
+```jsx
+ ({
+ borderWidth: focused ? 2 : 0,
+ borderColor: focused ? 'red' : 'transparent',
+ })}
+>
+ Play
+
+```
+
+### Add Logs
+
+```jsx
+ console.log('Focused: playButton')}
+ onBlur={() => console.log('Blurred: playButton')}
+>
+ Play
+
+```
+
+Log `testID` or `accessibilityLabel` for each component to pinpoint where focus actually landed.
+
+### React DevTools
+
+- Inspect which components are actually focusable.
+- Identify invisible/off-screen elements still receiving focus.
+- Profile re-renders after D-pad key press to catch timing issues (component mounting/unmounting during focus transition).
+
+## Gotchas
+
+- The **focus management hierarchy** is: (1) clean layouts with inferred behavior, (2) TVFocusGuideView, (3) hasTVPreferredFocus, (4) trapFocus props, (5) requestTVFocus() as last resort. If you're reaching for imperative focus, your layout probably needs fixing.
+- `nextFocusUp`/`nextFocusDown`/etc. are **Android-only** and ignored on tvOS. Don't use them in cross-platform codebases.
+- Hidden views can still **receive focus** if they remain in the tree. When hiding elements, unmount them entirely or disable focus explicitly.
+- Always have **at least one focusable element** on screen — including loaders, empty states, and error states. Without one, focus jumps to arbitrary locations or vanishes entirely. Verify by walking every screen state (loading, empty, error, populated) and confirming focus has somewhere to land.
+- On tvOS, **misaligned or overlapping elements** cause unexpected focus jumps. The focus engine expects clean grid alignment.
+- `hasTVPreferredFocus` on **multiple elements** in the same view produces unpredictable results. Use it once per screen.
+
+## Common Focus Problems
+
+| Problem | Cause | Fix |
+|---------|-------|-----|
+| Focus jumps to random element | No focusable element on current screen (loader/empty state) | Always render a focusable placeholder |
+| Focus lost after re-render | Component key changed or unmounted | Keep keys stable; restore focus post-render |
+| Focus lands on hidden content | Hidden view still in tree | Unmount hidden elements or disable focus |
+| Focus won't cross a gap | Two areas too far apart for engine | Use TVFocusGuideView to bridge |
+| Wrong element focused on load | Multiple `hasTVPreferredFocus` | Use only one; wait for UI to render |
+| Focus feels laggy | Too many focusable elements | Reduce count; virtualize lists |
+
+## Building Predictable Navigation
+
+- **Keep movement consistent**: If "right" moves to next card on one screen, same everywhere.
+- **Let the layout lead**: Clear alignment helps the engine make right decisions.
+- **Plan focus transitions**: Define where focus starts, how "back" behaves, what regains focus on return.
+- **Simplify the hierarchy**: Shallow navigation works best. Too many layers = lost users.
+
+**Verify before ship:**
+
+- Every interactive element shows a visible focus state using multi-cue (color + border/outline + mild scale) — color alone fails on washed-out displays and for color-deficient users.
+- No dead ends: from any focused element, the user can always navigate back. Walk every screen and confirm "back" produces a sensible destination, not a stuck state.
diff --git a/rn-tv-ui-best-practices/references/ten-foot-experience.md b/rn-tv-ui-best-practices/references/ten-foot-experience.md
new file mode 100644
index 0000000..f5ceeae
--- /dev/null
+++ b/rn-tv-ui-best-practices/references/ten-foot-experience.md
@@ -0,0 +1,55 @@
+# The 10-Foot Experience
+
+Design principles for TV interfaces viewed from across the room with a remote control.
+
+## Designing for Distance
+
+- Bold shapes and simple icons only — fine detail disappears at 10 feet.
+- Generous spacing so every element stands out. Dense layouts fail on TV.
+- Strong contrast and visual hierarchy over decorative elements.
+- Interface must be readable at a glance; important info immediately obvious.
+
+## Remote Interaction Model
+
+Most remotes provide: directional arrows, select, back, play/pause. Design for these constraints:
+
+- **Select** = confirm/activate. **Back** = return to previous screen.
+- Every button press produces an immediate visual response (highlight, scale change, or pulse).
+- Map actions to predictable buttons consistently across all screens.
+- If pressing left opens the drawer from one screen, it must do the same from all screens.
+
+## Directional Navigation Principles
+
+- Left/right for movement **within** rows. Up/down for movement **between** sections.
+- Focus should flow predictably — no dead ends, no surprising jumps.
+- From home screen to first "Play" action: always a clear, logical path.
+- When overlays/modals appear, trap focus inside until dismissed.
+
+## Shared Screen Considerations
+
+TVs are shared among family/roommates. This changes UI decisions:
+
+- Avoid displaying sensitive/personal info unless necessary.
+- Make profile/account switching clearly accessible.
+- Confirm voice input text before submitting (everyone in the room can see it).
+- Overlays/menus: visible long enough to serve purpose, then dismiss. Don't compete with content.
+
+## Feedback, Motion, and Rhythm
+
+TVs have inherent input delay. Immediate visual acknowledgment is critical.
+
+- Every button press acknowledged instantly through a visual cue.
+- Animation serves direction or focus changes — never pure decoration.
+- If an animation delays interaction or feels sluggish, it's too long.
+- Smooth execution matters more than elaborate effects.
+
+**Verify before ship:** animations stay under 200ms (drawers, modals, focus transitions) and there's no perceptible input delay between a remote press and a visible response. If you can press a button and count "one" before anything happens, it's already too slow — TV input pipelines add their own latency on top of whatever you measure on a dev machine.
+
+## Couch Sanity Checks
+
+The mechanical checks (typography sizes, contrast, safe zones, focus behavior, animation timing) are covered in their respective reference files as `**Verify before ship:**` notes. But mechanical pass alone isn't enough — TV apps surface issues only when used the way real users use them.
+
+**Verify before ship: do a real couch test.** Sit at actual viewing distance (8-10 feet), use the actual remote control for the platform, and run through the primary flows. Don't substitute a desk monitor with a keyboard — input cadence, text legibility, and focus visibility all behave differently with a remote in hand and the screen across the room. Two qualitative questions only this test can answer:
+
+- Can you find and play content easily? (Discovery test — does the layout guide you toward the goal?)
+- Is anything awkward? Simplify until navigation feels invisible.
diff --git a/rn-tv-ui-best-practices/references/typography-and-color.md b/rn-tv-ui-best-practices/references/typography-and-color.md
new file mode 100644
index 0000000..e4a205b
--- /dev/null
+++ b/rn-tv-ui-best-practices/references/typography-and-color.md
@@ -0,0 +1,132 @@
+# Typography and Color for TV Displays
+
+TV-specific typography and color guidelines. What works on phones fails on TV due to distance, panel tech, ambient light, and OS rendering.
+
+## Gotchas
+
+- TV text must be **50-80% larger** than mobile equivalents. A 16px body on mobile = 24px on TV. Anything smaller is unreadable from the couch.
+- Avoid pure `#FFFFFF` on pure `#000000` for entire screens — causes eye fatigue and HDR glow. Use near-white (#E5E5E7) and near-black (#1a1a1a).
+- Focus contrast must use **multi-cue**: color + border/outline + mild scale. Color alone fails for color-deficient users and washed-out displays.
+
+## Typography
+
+### Critical Values (Guidelines)
+
+These are recommended starting points based on visual acuity research for living room environments. Adapt to your app's brand and user testing results.
+
+```
+Typography (minimum TV sizes):
+ Body: 24px | Caption: 20px | Button: 22px
+ Heading: 32px | Title: 48px | Display: 64px
+
+Contrast:
+ Normal text: >= 4.5:1
+ Core UI (menus, buttons, captions): >= 7:1
+ Focus border: #00D4FF (11.3:1 vs black)
+```
+
+### Recommended Font Sizes
+
+TV text should be 50-80% larger than mobile equivalents. These are guidelines based on visual acuity research for living room environments — use as starting points and adjust based on your app's design and user testing:
+
+| Text Style | Mobile | TV | Use Case |
+|---|---|---|---|
+| Body | 16px | 24px | Descriptions, paragraphs |
+| Caption | 12px | 20px | Metadata, labels, tags |
+| Button | 14px | 22px | Interactive elements, CTAs |
+| Heading | 20px | 32px | Section titles, category names |
+| Title | 28px | 48px | Page titles, hero text |
+| Display | 36px | 64px | Large promotional text |
+
+```js
+const tvTypography = StyleSheet.create({
+ body: { fontSize: 24, lineHeight: 32, fontWeight: '400' },
+ button: { fontSize: 22, lineHeight: 28, fontWeight: '600' },
+ caption: { fontSize: 20, lineHeight: 26, fontWeight: '400' },
+ heading: { fontSize: 32, lineHeight: 40, fontWeight: '600' },
+ title: { fontSize: 48, lineHeight: 56, fontWeight: '700' },
+});
+```
+
+**Verify before ship:** every text style on screen lands at >= 20px (captions) and >= 24px (body). Anything smaller is a regression — a single 16px label slipping through is the kind of thing only catches at couch distance, so audit explicitly rather than relying on a quick scan.
+
+### Platform Typefaces
+
+Use the platform's optimized system font:
+- **tvOS**: San Francisco (SF Pro Display / SF Pro Text)
+- **Android TV / Fire TV**: Roboto
+- **Fallbacks / multi-script**: Inter, Noto Sans
+
+### Line and Character Spacing
+
+Line height values are **multipliers** of font size (e.g., 1.4x means line-height = 1.4 × fontSize).
+
+| Context | Line Height | Letter Spacing | Use |
+|---|---|---|---|
+| Content (paragraphs) | 1.4x | +0.4px | Long-form reading |
+| Navigation (menus) | 1.2x | +0.5px | Menu items, scanning |
+| Display (large text) | 1.15x | -0.4px to -0.8px | Hero text, titles |
+
+Negative tracking for large titles: huge sizes amplify default spacing, so tighten slightly to avoid airy gaps.
+
+### Text Rendering Rules
+
+- Sentence case over ALL CAPS for body/captions (caps reduce word shape recognition).
+- Tile titles: max 2 lines + `ellipsizeMode="tail"`.
+- Avoid ultra-light/ultra-thin weights — shimmer on LCDs, bloom on OLEDs.
+- For long localized titles: gentle marquee on focus only, never by default.
+
+### Text Over Images
+
+Text can vanish against complex backgrounds. Use:
+
+```js
+const readableOnImage = {
+ color: '#FFF',
+ textShadowColor: 'rgba(0,0,0,0.35)',
+ textShadowOffset: { width: 0, height: 1 },
+ textShadowRadius: 2,
+};
+```
+
+For subtitles/over-video UI: combine shadow + thin stroke outline at low opacity. Don't crank shadow blur.
+
+## Color and Contrast
+
+### Contrast Ratios
+
+- Normal text: >= 4.5:1
+- Core UI (menus, buttons, captions over images): >= 7:1
+- Avoid pure #FFFFFF on #000000 for entire screens (eye fatigue, HDR glow).
+- Use near-white and near-black for base UI; reserve extremes for short-lived highlights.
+- Focus indicators must use **multi-cue**: color + border/outline + mild scale.
+
+**Verify before ship:** spot-check every text-on-background pair against these ratios (4.5:1 normal, 7:1 core UI). Don't trust the design comp — TV gamma and ambient glare push borderline pairs below threshold once the app actually renders on hardware.
+
+### HDR Considerations
+
+- Keep UI whites around 80-90% luminance; avoid hard #FFFFFF for persistent text.
+- Cap highlight intensity (focus glow, selection chips) to prevent blooming against HDR content.
+- Test both SDR and HDR modes; ship a palette that doesn't collapse in either.
+
+### Ambient Light Adaptation
+
+| Environment | Background | Primary Text | Secondary Text | Accent | Min Contrast |
+|---|---|---|---|---|---|
+| Bright room | #000000 | #FFFFFF | #E5E5E7 | #007AFF | 7:1 |
+| Dim room | #1a1a1a | #E5E5E7 | #B3B3B3 | #5AC8FA | 4.5:1 |
+| Dark room | #2a2a2a | #D1D1D6 | #8E8E93 | #64D2FF | 3:1 |
+
+### Color Palette with Contrast Ratios
+
+| Purpose | Value | vs Black | vs #1a1a1a | Use Case |
+|---|---|---|---|---|
+| Primary text | #FFFFFF | 21:1 | 17.8:1 | Body, headings, critical info |
+| Secondary text | #E5E5E7 | 18.5:1 | 15.7:1 | Labels, metadata |
+| Tertiary text | #A1A1AA | 8.6:1 | 7.3:1 | Timestamps, auxiliary |
+| Disabled text | #6B7280 | 4.2:1 | 3.6:1 | Inactive (use sparingly) |
+| Primary accent | #007AFF | 8.2:1 | 7.0:1 | Links, CTAs, selected states |
+| Focus border | #00D4FF | 11.3:1 | 9.6:1 | Focus indicators |
+| Success | #34C759 | 9.8:1 | 8.3:1 | Confirmations |
+| Warning | #FF9500 | 7.1:1 | 6.0:1 | Warnings |
+| Danger | #FF3B30 | 5.9:1 | 5.0:1 | Errors, destructive actions |