Improve agentic coding setup

.agents/skills/agent-verification/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: agent-verification
+description: Select and run concise deterministic DodoStream verification checks. Use for implementation validation, CI-equivalent checks, static quality checks, or rerunning one failing verification phase.
+---
+
+# Agent verification
+
+Use this skill to select the narrowest deterministic check that observes the changed contract. It complements `slice-development`; it does not replace focused tests or authorized native evidence.
+
+## Commands
+
+```bash
+# List stable phase keys.
+pnpm --silent verify:agent --list
+
+# Run one or more named phases with concise output.
+pnpm --silent verify:agent --only typecheck,lint
+
+# Emit newline-delimited JSON for an automated caller.
+pnpm --silent verify:agent --only format,typecheck --json
+
+# Stream a child command while diagnosing it.
+pnpm --silent verify:agent --only android-prebuild --verbose
+
+# Run the complete deterministic gate after the last slice.
+pnpm --silent verify:agent
+# `pnpm verify:ci` is the CI alias.
+```
+
+`verify:agent` preserves a failing command's output and exit status. It suppresses successful child output so an agent retains the phase result, elapsed time, and failure evidence instead of routine logs.
+
+## Phase selection
+
+| Changed area                                    | First check                                            |
+| ----------------------------------------------- | ------------------------------------------------------ |
+| TypeScript code or imports                      | `typecheck`                                            |
+| Formatting-only or config/documentation changes | `format`                                               |
+| JavaScript/TypeScript lint rules                | `lint`                                                 |
+| Expo dependency versions                        | `expo-deps`, then `expo-doctor`                        |
+| Native config or config plugins                 | `android-prebuild`                                     |
+| Root Jest contract                              | a focused `pnpm --silent test:agent <path-or-pattern>` |
+| Android E2E runner scripts                      | `e2e-tools`                                            |
+| Deterministic fixture add-on                    | `e2e-addon-types,e2e-addon`                            |
+
+Run the complete gate only after the changed slice's focused check passes. Do not substitute it for a focused RED/GREEN test.
+
+## Native and diagnostic boundaries
+
+- `verify:agent` never builds an APK, starts Metro, acquires a device, or proves UI/focus/player behavior.
+- For rendered Android/TV behavior, use `android-interactive-verification` after this gate; the device proof is separate.
+- Use direct `pnpm lint` when the current warning text matters. The gate intentionally reports a successful lint phase concisely.
+- The Jest phase does not force-exit or otherwise conceal open handles. Investigate a handle warning as its own defect; do not weaken the gate to hide it.
+
+## Exit criteria
+
+Report the exact phase keys and observed result. A complete UI or native-feature claim also needs the focused test and, when applicable, the authorized device evidence named by `slice-development`.

.agents/skills/android-interactive-verification/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: android-interactive-verification
+description: Session-scoped Android and Android TV fixture, APK, interaction, evidence, and Maestro procedure through the agent-device MCP server.
+---
+
+# Android interactive verification
+
+Use this skill only when the slice's expectation crosses a native Android/Android TV boundary: focus routing, D-pad semantics, native players, lifecycle or system UI, real list recycling, Android-only behavior, rendered geometry, or a stable Maestro regression. Pure parsing, state, hook, transformation, and mockable API work stays on the lower verification ladder.
+
+## Permission and ownership gate
+
+Before acquiring or driving a device, confirm that the task explicitly requires device evidence or that the user authorized it. Stop before device acquisition when neither is true. If no agent-device session is active or the selected target is occupied by another agent, ask the user what to do before acquiring, booting, or reusing a target. Never start Metro, use Expo web, call the `agent-device` CLI directly, or use raw `adb`.
+
+All device interaction goes through the repository's `agent-device` MCP server (`.omp/mcp.json`): keep exactly one MCP session per worktree and bind every operation to it. Keep the session for nearby repairs; release it with `close` after the last related L4/L5 slice, including failure paths.
+
+## Required inputs
+
+Record these before starting:
+
+- The slice's exact expectation and RED interaction, including the expected initial and final state.
+- `phone`, `tablet`, or `tv` profile; dev app id `app.dodora.dodostream.dev`; and the required orientation.
+- The release APK path recorded by `pnpm e2e:android:build` in `artifacts/e2e/<profile>/artifact.json`.
+- The seeded fixture manifest URL. The fixture's `GET /manifest.json` must identify `com.dodostream.e2e-fixture` before install or launch; do not invent a second health endpoint.
+- The affected existing Maestro flow, if a stable regression path already exists.
+
+## Session sequence
+
+1. Start the fixture add-on for this worktree (`pnpm e2e:addon`) and probe its `/manifest.json`.
+2. Build the release APK artifact: `pnpm e2e:android:build -- --profile <phone|tablet|tv>`. The build applies `APP_VARIANT=dev`, `EXPO_PUBLIC_E2E=1`, the profile orientation, and `EXPO_TV=1` for TV. Never substitute a Metro bundle.
+3. Through the MCP tools: list or boot the profile-matching device and bind the worktree's MCP session to it.
+4. Through the MCP tools: disable animations, set the profile orientation, install the artifact, and launch `app.dodora.dodostream.dev`. Clear only the app state when the slice needs a clean start, then capture the initial screenshot, hierarchy snapshot, and app logs before interacting.
+5. Execute the recorded sequence through MCP interactions (`tv_remote` for `DPAD_*` and `BACK`, press, type, swipe). Capture the resulting screenshot, hierarchy, and focused-component or app logs at each meaningful state.
+6. On failure, return to the same slice's DEBUG loop: repeat the exact sequence, state one causal hypothesis, change one causal area, and retest on the same session.
+7. Release the MCP session with `close` when no nearby slice needs it, and stop the fixture add-on process.
+
+Captures belong beneath the current worktree's ignored `artifacts/` directory. A local emulator reaches the fixture through `http://10.0.2.2:<port>/manifest.json`; record the exact URL the session used. Never assume a host address works from a physical device.
+
+## Evidence and Maestro promotion
+
+The final slice record must state `initial state → key/action → observed state` and identify which screenshot, hierarchy, and log artifacts support it. A screenshot alone does not prove focus; name the visual focus indicator plus hierarchy or focused-component evidence. Do not overwrite committed snapshots during exploration.
+
+Promote the sequence to a targeted Maestro flow only when L4 establishes a stable, user-important regression with reliable selectors and reviewed screenshots. Run the flow through the MCP server (`test` with the flow file and session env such as `ADDON_MANIFEST_URL`, `PROFILE`, `E2E_ORIENTATION`); inspect every screenshot and baseline change before staging. Do not use Maestro as the first debugger for an unclear focus graph, a positional workaround, or a one-off exploratory trace.
+
+## Exit criteria
+
+The skill exits only when the slice has concrete interaction evidence, a targeted Maestro result when promotion is warranted, and no live agent-device MCP session or fixture add-on process is left running.

.agents/skills/bug-reproduction/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: bug-reproduction
+description: Reproduce a reported bug on Android/Android TV and capture evidence. Use when a bug report, GitHub issue, or regression must be confirmed before fixing; release-APK route via agent-device, never Metro or Expo web.
+---
+
+# Bug reproduction
+
+## Intake
+
+Extract from the issue: repro steps, affected variant (`app.dodora.dodostream.dev` vs prod), platform (phone portrait / tablet / tv landscape), and expected vs actual behavior.
+
+## Permission gate
+
+Per `AGENTS.md`, only acquire a device through the `agent-device` MCP server, one named session per worktree, and only when the user authorized device use for this task.
+
+## Build route
+
+Default is the release-APK route: `pnpm e2e:android:build -- --profile <phone|tablet|tv>` with the deterministic Stremio fixture (`packages/e2e-addon/`, readiness probe `/manifest.json`). Do not start Metro or use Expo web. If the issue only reproduces in a dev build, ask the user before starting Metro.
+
+## Reproduce loop
+
+Install the APK via agent-device, reset state, drive the exact repro steps with D-pad/tap tools, and capture snapshot/screenshot/logs each attempt. Keep going until the bug reproduces or 3 attempts make no progress — report findings instead of thrashing.
+
+## Regression windows
+
+If the issue is a regression and the breaking window is unclear, never start a `git bisect` loop unprompted — each step costs a full release-APK build. Present the bisect plan (candidate commits, build count, expected duration) and ask the user first; prefer reasoning from the issue's reported version and `git log` over blind bisection.
+
+## Fix handoff
+
+Once reproduced, switch to the `slice-development` skill state loop with the reproduction as the RED expectation; re-verify on device post-fix.
+
+## Close the loop
+
+Prepare the issue comment (repro summary + fix commit) as a dry run for `github-write`, and hand the fix off through `pr-handoff`. Post either only after explicit user approval.

.agents/skills/feature-delivery/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: feature-delivery
+description: Deliver a feature end to end from user-visible goal to PR-ready branch. Use when implementing a new feature: composes slice-development, android-interactive-verification, What's New generation, the verify:ci gate, and pr-handoff.
+---
+
+# Feature delivery
+
+## Compose, don't duplicate
+
+This skill routes; it does not restate content. `slice-development` owns slicing, RED, checkpoints, and the final evidence structure. `android-interactive-verification` owns the device boundary. Link to them by skill name.
+
+## Pipeline
+
+1. Write the goal as user-visible behavior.
+2. Slice with `slice-development`.
+3. Implement with the invariants in `AGENTS.md` (Restyle tokens, i18n strings, `Focusable`, LegendList, React Query).
+4. Prove each slice at the lowest observing ladder level.
+5. Any UI change requires a live `agent-device` check of the real surface — Jest alone never closes a UI slice.
+6. Add a What's New entry if noteworthy per CONTRIBUTING.md's "Noteworthy feature release notes" criteria (`pnpm new-whats-new` + `pnpm generate-whats-new`).
+7. Run the final `pnpm verify:ci`.
+8. Hand off via the `pr-handoff` skill.
+
+## Completion rule
+
+The feature is done only when every slice is checkpointed, the UI is verified on device with recorded evidence, `verify:ci` is green, and the PR (or approved local-commit delivery, if the user pushes themselves) is out for review.

.agents/skills/issue-triage/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: issue-triage
+description: Rank open GitHub issues and propose the next work. Use when prioritizing the backlog, deciding what to implement next, or reviewing new issues; reads via the readonly `github` server, writes only after user approval.
+---
+
+# Issue triage
+
+## Read phase
+
+Use the read-only `github` MCP server. List open issues with their state, labels, and comments. Never use `github-write` in this phase.
+
+## Classify
+
+Classify each issue as bug / feature / chore. Note the affected platform (phone / tablet / tv) from labels or the body. Note repro clarity: are concrete steps present? Is the issue fixture-reproducible?
+
+## Taxonomy proposals
+
+For each issue, prepare a dry-run label payload:
+
+- `type: bug|feature|chore`
+- `platform: phone|tablet|tv`
+- `repro: clear|unclear|fixture`
+- `prio: P1|P2|P3`
+
+Follow the existing repo label style in `.github/ISSUE_TEMPLATE/`. Execute only after explicit user approval via `github-write`. Once the labels exist on enough issues, ranking becomes mechanical label filtering instead of per-issue reasoning.
+
+## Rank
+
+Score each issue: user impact (weight ×3) + frequency signals (+1 per duplicate or mention in comments) + effort estimate (S/M/L; subtract weight for larger effort) + risk. Present a ranked table with per-issue rationale. Map each issue to repo areas via the layout in `AGENTS.md` (`src/components/` domains, `packages/`, `scripts/`).
+
+## Propose
+
+Recommend the next 1–2 items to implement with the reasoning table. For each recommendation, state the skill to use (`bug-reproduction` or `feature-delivery`) and the affected build profiles.
+
+## Write gate
+
+Prepare exact payloads for any proposed write (label to apply, comment text, priority field) as dry runs in the response. Execute only via `github-write` tools after explicit user approval in the same conversation, and only the exact approved payload.

.agents/skills/pr-handoff/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: pr-handoff
+description: Prepare the branch, title, and draft PR body for substantive finished work. Use when a change touching runtime code, tests, build config, or behavior-impacting docs is verified and ready for review; output is a PR-ready block, created only after user approval.
+---
+
+# PR handoff
+
+## Collect
+
+- Branch name suggestion: `fix|feat/<scope>-<slug>`.
+- PR title in Conventional Commit style referencing the owning issue (`fix: #195 ...`).
+- Draft body assembled from the slice evidence structure (Implemented / Checkpoints / Verified / Not run / Remaining concerns), matching `.github/PULL_REQUEST_TEMPLATE.md`.
+
+## Emit
+
+Emit the complete block (branch, title, body) in one fenced markdown chunk so the user can review the exact payload.
+
+## Write gate
+
+Create the branch and PR via `github-write` only after explicit user approval of that exact block in the same conversation. Never push directly, never merge, never approve a PR — review and merge are human phases.