OTA Deployment Guardian
Use this skill when a device is updated remotely and losing the update path
would be expensive.
Resources
references/ota-safe-sketch.md - minimum sketch-side OTA contract and guardrailsreferences/discovery-and-network-ports.md - IDE, mDNS, IP reachability, and disappearing network port triagereferences/recovery-and-rollback.md - rollout safety, rollback, and last-resort recovery planning../../docs/board-support/uno-r4-family.md - Uno R4 Minima and Uno R4 WiFi board-family caveats
When to Use
Use this skill when the request involves:
- OTA uploads for ESP32, Nano ESP32, or Uno R4 WiFi
- network port appears briefly or disappears
- IDE can ping the device but cannot upload
- keeping a remote weather station or deployed board updateable
- avoiding self-bricking after an OTA deployment
Do not use this skill for ordinary bench USB uploads unless the user is clearly
preparing for later OTA deployment.
Workflow
- Confirm the board family:
- ESP32 or Nano ESP32 -> open
references/ota-safe-sketch.md
- Uno R4 WiFi -> also open
../../docs/board-support/uno-r4-family.md
- Separate discovery failures from sketch failures:
- ping works but network port disappears -> open
references/discovery-and-network-ports.md
- OTA works once, then disappears after the new sketch runs -> verify the new
sketch still implements the OTA path in
ota-safe-sketch.md
- Before suggesting a rollout, check
references/recovery-and-rollback.md for
recovery path, rollback strategy, and what must stay available over USB.
- Treat core-version changes as a possible variable when OTA previously worked
and later became unreliable.
Security And Maintenance Boundary
Use the router's connected-device security reference for secrets, signed images,
dependency versions, staged rollout, rollback, vulnerability response, and
decommissioning. This skill's board-specific OTA procedures do not prove that
the device has secure boot, authenticated updates, or a recoverable field
deployment; verify those controls on the exact target.
Core Rules
- Never assume OTA remains available after a new sketch unless the sketch keeps
the OTA path alive.
- Distinguish reachability from OTA discovery. Ping success does not prove the
IDE can discover or upload.
- Keep at least one recovery path in reserve for high-cost remote devices.
- For Uno R4 WiFi, keep board-family caveats explicit. Its WiFi side is not the
same operational model as a plain ESP32 board.
Verification
- Confirm the sketch still connects to the intended network and services the OTA
path after boot.
- Confirm whether the failure is discovery-only, upload-only, or full device
reachability loss.
- For remote deployments, confirm the rollback or physical recovery plan before
recommending an update.
- If board or core versions changed recently, capture the exact versions before
concluding the failure is in user code.
Integration
- Pair with
arduino-cli-skill when the user needs command-line upload or port
inspection.
- Pair with
field-power-and-connectivity-triager when the OTA path fails only
off USB or in field power conditions.
- Pair with
error-message-explainer when the OTA sketch itself does not build.
Shared Output Contract
Use the shared Arduino skill contract:
state assumptions, required tools and versions, implementation steps,
tests/evidence by proof stage, known limitations, and recovery/security notes.
1---
2name: ota-deployment-guardian
3description: Use when users need safe over-the-air update workflows for ESP32-class boards or Arduino Uno R4 WiFi, including OTA sketch requirements, network port discovery failures, remote recovery planning, and rollout safety checks.
4metadata: {triggers: "OTA, over-the-air update, rollback, remote recovery, deployment"}
5---
6
7# OTA Deployment Guardian
8
9Use this skill when a device is updated remotely and losing the update path
10would be expensive.
11
12## Resources
13
14- `references/ota-safe-sketch.md` - minimum sketch-side OTA contract and guardrails
15- `references/discovery-and-network-ports.md` - IDE, mDNS, IP reachability, and disappearing network port triage
16- `references/recovery-and-rollback.md` - rollout safety, rollback, and last-resort recovery planning
17- `../../docs/board-support/uno-r4-family.md` - Uno R4 Minima and Uno R4 WiFi board-family caveats
18
19## When to Use
20
21Use this skill when the request involves:
22
23- OTA uploads for ESP32, Nano ESP32, or Uno R4 WiFi
24- network port appears briefly or disappears
25- IDE can ping the device but cannot upload
26- keeping a remote weather station or deployed board updateable
27- avoiding self-bricking after an OTA deployment
28
29Do not use this skill for ordinary bench USB uploads unless the user is clearly
30preparing for later OTA deployment.
31
32## Workflow
33
341. Confirm the board family:
35 - ESP32 or Nano ESP32 -> open `references/ota-safe-sketch.md`
36 - Uno R4 WiFi -> also open `../../docs/board-support/uno-r4-family.md`
372. Separate discovery failures from sketch failures:
38 - ping works but network port disappears -> open
39 `references/discovery-and-network-ports.md`
40 - OTA works once, then disappears after the new sketch runs -> verify the new
41 sketch still implements the OTA path in `ota-safe-sketch.md`
423. Before suggesting a rollout, check `references/recovery-and-rollback.md` for
43 recovery path, rollback strategy, and what must stay available over USB.
444. Treat core-version changes as a possible variable when OTA previously worked
45 and later became unreliable.
46
47## Security And Maintenance Boundary
48
49Use the router's connected-device security reference for secrets, signed images,
50dependency versions, staged rollout, rollback, vulnerability response, and
51decommissioning. This skill's board-specific OTA procedures do not prove that
52the device has secure boot, authenticated updates, or a recoverable field
53deployment; verify those controls on the exact target.
54
55## Core Rules
56
57- Never assume OTA remains available after a new sketch unless the sketch keeps
58 the OTA path alive.
59- Distinguish reachability from OTA discovery. Ping success does not prove the
60 IDE can discover or upload.
61- Keep at least one recovery path in reserve for high-cost remote devices.
62- For Uno R4 WiFi, keep board-family caveats explicit. Its WiFi side is not the
63 same operational model as a plain ESP32 board.
64
65## Verification
66
67- Confirm the sketch still connects to the intended network and services the OTA
68 path after boot.
69- Confirm whether the failure is discovery-only, upload-only, or full device
70 reachability loss.
71- For remote deployments, confirm the rollback or physical recovery plan before
72 recommending an update.
73- If board or core versions changed recently, capture the exact versions before
74 concluding the failure is in user code.
75
76## Integration
77
78- Pair with `arduino-cli-skill` when the user needs command-line upload or port
79 inspection.
80- Pair with `field-power-and-connectivity-triager` when the OTA path fails only
81 off USB or in field power conditions.
82- Pair with `error-message-explainer` when the OTA sketch itself does not build.
83
84## Shared Output Contract
85
86Use [the shared Arduino skill contract](../../docs/arduino-skill-contract.md):
87state assumptions, required tools and versions, implementation steps,
88tests/evidence by proof stage, known limitations, and recovery/security notes.
wedsamuel1230