webnn — скилл для Claude Code: WebNN в браузерных приложениях

---
name: webnn
description: Implements and debugs browser Web Neural Network API integrations in JavaScript or TypeScript web apps. Use when adding navigator.ml checks, MLContext creation, MLGraphBuilder flows, device selection, tensor dispatch and readback, or explicit fallback paths to ONNX Runtime Web or other local runtimes. Don't use for model training, server-side ML inference, or cloud AI APIs.
license: MIT
metadata:
  author: webmaxru
  version: "1.4"
---

# WebNN

## Procedures

**Step 1: Identify the browser integration surface**
1. Inspect the workspace for browser entry points, UI handlers, worker entry files, and any existing model-loading or inference abstraction layer.
2. Execute `node scripts/find-webnn-targets.mjs .` to inventory likely frontend files and existing WebNN markers when a Node runtime is available.
3. If a Node runtime is unavailable, inspect the nearest `package.json`, HTML entry point, framework bootstrap files, and worker entry files manually to identify the browser app boundary.
4. If the workspace contains multiple frontend apps, prefer the app that contains the active route, component, or user-requested feature surface.
5. If the inventory still leaves multiple plausible frontend targets, stop and ask which app should receive the WebNN integration.
6. If the project is not a browser web app, stop and explain that this skill does not apply.

**Step 2: Confirm WebNN viability and choose the runtime shape**
1. Read `references/webnn-reference.md` before writing code.
2. Read `references/examples.md` when choosing between a direct WebNN graph flow and an adapter around an existing browser ML runtime.
3. Read `references/compatibility.md` when native support, preview flags, device behavior, or backend differences matter.
4. Read `references/troubleshooting.md` when context creation, graph build, tensor readback, or device selection fails.
5. Verify that the feature runs in a secure context and in a `Window` or `Worker` context (`DedicatedWorker`, `SharedWorker`, or `ServiceWorker`).
6. If the feature must run on the server, train models, or depend on cloud inference, stop and explain the platform mismatch.
7. Choose device intent deliberately: use `powerPreference: "high-performance"` for throughput, `powerPreference: "low-power"` for power-efficient acceleration, or `accelerated: false` to prefer CPU inference for maximum reach.
8. Treat `accelerated` and `powerPreference` as preferences, not guarantees. Browser backends can still partition graphs or fall back per operator.
9. Choose a direct `MLGraphBuilder` flow when the application owns graph construction or can keep a small deterministic graph path.
10. Choose an adapter around an existing local runtime only when the application already loads models through that runtime and the task is to prefer WebNN acceleration without rewriting the full inference stack.
11. If the project uses TypeScript, add or preserve typings for the WebNN surface used by the project.

**Step 3: Implement a guarded runtime adapter**
1. Read `assets/webnn-runtime.template.ts` and adapt it to the framework, state model, and file layout in the workspace.
2. Centralize support detection around `window.isSecureContext`, `navigator.ml`, and the requested execution context instead of scattering checks through UI components.
3. Create an `MLContext` only at the boundary where the app is ready to initialize local inference.
4. Pass explicit `accelerated` and `powerPreference` values when the product has a real preference, and omit tuning that the product cannot justify.
5. Build the graph through `MLGraphBuilder` when the feature uses direct WebNN operations, or route existing model execution through the app's existing local runtime adapter when that runtime is already responsible for model loading and pre/post-processing.
6. Reuse the compiled graph and reusable tensors when input and output shapes stay stable across requests.
7. Use `context.writeTensor()`, `context.dispatch()`, and `await context.readTensor()` in that order for direct graph execution.
8. Observe `context.lost` and rebuild the context, graph, and tensors if the browser invalidates the execution state.
9. Destroy tensors, graphs, and contexts when the feature is disposed or the route no longer needs them.

**Step 4: Wire UX and fallback behavior**
1. Surface distinct states for unsupported browsers, secure-context failures, runtime preparation, ready native execution, and explicit fallback execution.
2. Keep a non-WebNN path for unsupported browsers or unsupported devices when the feature must remain available.
3. Keep the fallback explicit and product-approved. Do not silently swap in a remote model provider when the feature is supposed to stay local.
4. Present device choice as an intent, not a promise that every operator will execute on that device.
5. Move long-running model preparation or repeated inference off the main thread when the application already uses a worker-friendly architecture.
6. Keep all user data handling consistent with the product's local-processing promises and privacy requirements.

**Step 5: Validate behavior**
1. Execute `node scripts/find-webnn-targets.mjs .` to confirm that the intended app boundary and WebNN markers still resolve to the edited integration surface.
2. Verify secure-context and `navigator.ml` detection before debugging deeper runtime issues.
3. For direct WebNN paths, run a smoke test that creates a context, builds a trivial graph, writes inputs, dispatches, and reads outputs.
4. Test the intended `accelerated` and `powerPreference` settings and confirm that fallback behavior remains usable when an accelerated context cannot be created.
5. Use `context.opSupportLimits()` when operator coverage or tensor data type support influences graph design.
6. Confirm the app does not reuse destroyed tensors, graphs, or contexts.
7. If the target environment depends on preview Chromium flags or milestone-specific behavior, confirm the required browser state from `references/compatibility.md` before treating runtime failures as application bugs.
8. Run the workspace build, typecheck, or tests after editing.

## Error Handling
* If `navigator.ml` is missing, confirm secure-context requirements and browser support from `references/compatibility.md` before changing application code.
* If `createContext()` fails for an accelerated or high-performance request, retry only through the product's approved fallback plan and surface the failure reason.
* If `build()` or `dispatch()` fails, check `references/examples.md` and `references/troubleshooting.md` for operator, shape, and device mismatches before rewriting the feature.
* If `context.lost` resolves, treat the current context, graph, and tensors as invalid and recreate them before the next inference attempt.
* If the product only has a remote inference contract, stop and explain that this skill does not directly apply.