ota-update-integration

Name: ota-update-integration
Author: easyzoom

22stars2forks

How to install ota-update-integration?

easyzoom/aix-skills/ota-update-integration

$npx -y skills add easyzoom/aix-skills --skill ota-update-integration

Installs into the current project.

Summary

Use when designing, integrating, testing, or debugging OTA firmware update flows, package formats, transport, rollback, versioning, or power-fail safety on embedded devices

Files · 1

View on GitHub

SKILL.md

1	# OTA Update Integration
2
3	## Overview
4
5	Use this skill to build OTA updates as a full pipeline: package creation, transport, staging, validation, activation, rollback, and observability. OTA is only reliable when every reset point is defined.
6
7	## When To Use
8
9	Use this skill when:
10
11	- The user wants firmware updates over HTTP, MQTT, BLE, LoRa, cellular, USB, SD card, or a custom protocol.
12	- The issue involves partial downloads, checksum failures, signature validation, resume, rollback, version checks, or update state machines.
13	- The target uses MCUboot, a vendor bootloader, A/B partitions, recovery mode, or external flash staging.
14
15	Do not use this skill for bootloader internals. Use `mcuboot-integration` when the image activation or swap logic itself is failing. For generic bootloader jump/handoff debugging, use `bootloader-debug`.
16
17	## First Questions
18
19	Ask for:
20
21	- Target device, RTOS/Linux stack, bootloader, flash layout, and update storage.
22	- Transport, package format, manifest fields, compression, encryption, and signing policy.
23	- Version policy, compatibility rules, rollback/factory reset behavior, and update trigger.
24	- Power-fail expectations and whether updates must resume after reset.
25	- Logs from download, validation, activation, and first boot.
26
27	## Integration Checklist
28
29	1. Define the update contract.
30	The manifest should include target identity, version, size, hash, signature, compatibility, and install mode.
31
32	1. Separate download from activation.
33	Store the image safely, verify it, then mark it pending only after all bytes and metadata are valid.
34
35	1. Make reset points explicit.
36	Document what happens during download, after validation, after activation, and during first boot.
37
38	1. Verify authenticity and integrity.
39	Use hash checks for corruption and signatures for trust. Do not treat transport TLS as a replacement for image signing.
40
41	1. Prove rollback.
42	The device must recover from bad images, failed self-tests, power loss, and interrupted transfers.
43
44	1. Add operational visibility.
45	Log update ID, version, byte count, validation result, boot decision, and final status.
46
47	## Common Failures
48
49	- Package metadata does not bind the image to the intended hardware or firmware family.
50	- Download success is treated as install success.
51	- The update state is stored in RAM or a non-atomic flash record.
52	- Power loss corrupts the staging slot or leaves ambiguous flags.
53	- Delta update logic has no full-image recovery path.
54	- TLS is enabled but image signatures and rollback policy are missing.
55
56	## Verification
57
58	Before claiming OTA works:
59
60	- State transport, package fields, bootloader policy, and flash layout.
61	- Confirm successful update and version transition.
62	- Confirm bad signature/hash rejection.
63	- Confirm power loss handling at download, validation, activation, and first boot.
64	- Confirm rollback or recovery path.
65
66	## Example
67
68	User:
69
70	```text
71	设备 OTA 偶尔升级后变砖。
72	```
73
74	Agent:
75
76	1. Maps each persistent OTA state and reset point.
77	1. Reproduces power loss during download, mark-pending, swap, and first boot.
78	1. Fixes atomic state storage or rollback policy before optimizing transfer speed.

People who liked this also viewed

6 picks

Type

ota-update-integration

22stars2forks

View on GitHub

How to install ota-update-integration?

easyzoom/aix-skills/ota-update-integration

$npx -y skills add easyzoom/aix-skills --skill ota-update-integration

Installs into the current project.

Summary

Use when designing, integrating, testing, or debugging OTA firmware update flows, package formats, transport, rollback, versioning, or power-fail safety on embedded devices

Files · 1

View on GitHub

SKILL.md

1	# OTA Update Integration
2
3	## Overview
4
5	Use this skill to build OTA updates as a full pipeline: package creation, transport, staging, validation, activation, rollback, and observability. OTA is only reliable when every reset point is defined.
6
7	## When To Use
8
9	Use this skill when:
10
11	- The user wants firmware updates over HTTP, MQTT, BLE, LoRa, cellular, USB, SD card, or a custom protocol.
12	- The issue involves partial downloads, checksum failures, signature validation, resume, rollback, version checks, or update state machines.
13	- The target uses MCUboot, a vendor bootloader, A/B partitions, recovery mode, or external flash staging.
14
15	Do not use this skill for bootloader internals. Use `mcuboot-integration` when the image activation or swap logic itself is failing. For generic bootloader jump/handoff debugging, use `bootloader-debug`.
16
17	## First Questions
18
19	Ask for:
20
21	- Target device, RTOS/Linux stack, bootloader, flash layout, and update storage.
22	- Transport, package format, manifest fields, compression, encryption, and signing policy.
23	- Version policy, compatibility rules, rollback/factory reset behavior, and update trigger.
24	- Power-fail expectations and whether updates must resume after reset.
25	- Logs from download, validation, activation, and first boot.
26
27	## Integration Checklist
28
29	1. Define the update contract.
30	The manifest should include target identity, version, size, hash, signature, compatibility, and install mode.
31
32	1. Separate download from activation.
33	Store the image safely, verify it, then mark it pending only after all bytes and metadata are valid.
34
35	1. Make reset points explicit.
36	Document what happens during download, after validation, after activation, and during first boot.
37
38	1. Verify authenticity and integrity.
39	Use hash checks for corruption and signatures for trust. Do not treat transport TLS as a replacement for image signing.
40
41	1. Prove rollback.
42	The device must recover from bad images, failed self-tests, power loss, and interrupted transfers.
43
44	1. Add operational visibility.
45	Log update ID, version, byte count, validation result, boot decision, and final status.
46
47	## Common Failures
48
49	- Package metadata does not bind the image to the intended hardware or firmware family.
50	- Download success is treated as install success.
51	- The update state is stored in RAM or a non-atomic flash record.
52	- Power loss corrupts the staging slot or leaves ambiguous flags.
53	- Delta update logic has no full-image recovery path.
54	- TLS is enabled but image signatures and rollback policy are missing.
55
56	## Verification
57
58	Before claiming OTA works:
59
60	- State transport, package fields, bootloader policy, and flash layout.
61	- Confirm successful update and version transition.
62	- Confirm bad signature/hash rejection.
63	- Confirm power loss handling at download, validation, activation, and first boot.
64	- Confirm rollback or recovery path.
65
66	## Example
67
68	User:
69
70	```text
71	设备 OTA 偶尔升级后变砖。
72	```
73
74	Agent:
75
76	1. Maps each persistent OTA state and reset point.
77	1. Reproduces power loss during download, mark-pending, swap, and first boot.
78	1. Fixes atomic state storage or rollback policy before optimizing transfer speed.

People who liked this also viewed

6 picks

Type