meta-wearables-operational-readiness

Diagnose and recover Meta Wearables DAT integration failures across firmware, companion, and release channels.

Updated Sep 6, 2026
One-click install
npx skills add https://github.com/shotcowboystyle/meta-wearables-ops-plugin --skill meta-wearables-operational-readiness-shotcowboystyle
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: meta-wearables-operational-readiness
Source: https://github.com/shotcowboystyle/meta-wearables-ops-plugin/tree/main/.agent/skills/meta-wearables-operational-readiness
Command: npx skills add https://github.com/shotcowboystyle/meta-wearables-ops-plugin --skill meta-wearables-operational-readiness-shotcowboystyle

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Meta Wearables integrations fail for many reasons—registration blocks, firmware mismatches, Meta AI companion issues, transport drops, or release-channel misconfiguration—and it is hard to tell which layer is at fault. This Skill provides a structured diagnostic and recovery workflow that freezes the full version tuple, classifies the failure, applies bounded recovery, and produces an auditable readiness packet. ## Core Features & Use Cases - Tuple-based preflight: Records platform, DAT artifact, Meta AI version, firmware, on-glasses DAT app, account, and channel with source/observed/access-gated labels before diagnosing. - Typed failure recovery: Classifies failures into configuration, account/channel, companion, firmware, transport, permission, lifecycle, thermal, and SDK categories, then applies the least invasive documented recovery. - Release readiness audit: Separates Developer Mode results from signed release-channel evidence so a clean debug run is never mistaken for production readiness. - Use Case: Your DAT Android app registers in Developer Mode but fails on a signed release build. Use this Skill to trace provisioning, identify the channel/tester misconfiguration, and produce a redacted evidence packet with a clear ready/blocked verdict. ## Quick Start Diagnose why my Meta Wearables DAT iOS app cannot start a session with my glasses and produce an operational readiness packet.

Frequently Asked Questions about meta-wearables-operational-readiness

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix Meta Wearables DAT registration failures?

Registration failures are classified by mode first: Developer Mode can enable local registration without proving release-channel authorization. Verify the project, application ID, signature, tester invitation, and channel state before assuming a device defect, then re-run registration with a new run ID.

Why does my Meta glasses session fail to start?

Session failures are traced through a preflight tuple covering SDK artifact, phone OS, Meta AI companion version, firmware, on-glasses DAT app state, permissions, and transport. The first failing state is captured in an ordered event trace so the exact layer—companion, firmware, link, or permission—is identified.

Does Developer Mode success mean my DAT app is release ready?

No. Developer Mode only proves the local registration and debug path; it cannot establish release authorization, app attestation, signed distribution, or store approval. Release readiness requires re-testing with the signed artifact, release channel, tester account, and physical device pair.

What should I do when Meta glasses report a firmware update required error?

Use the documented firmware update route, wait for the post-update state to be reported, and re-pair only if instructed. Record the firmware version again afterward and never claim the update succeeded unless the original operation completes on the target.

Can I auto-retry after a thermal or battery error on Meta glasses?

No. Thermal emergency, battery critical, peak-power shutdown, doff, and unknown protocol errors require stopping the workload, preserving the event trace, and applying a deliberate recovery. Automatic retries through these states are explicitly prohibited.