Skip to main content
OfficialSwiftObjective-C

Implement AIBuds Factory Reset

Add a guarded factory-reset workflow to an iOS app using the public DeviceCommonAPI.

Install this Skill

Download the complete reviewed package. Raw Markdown alone does not include its supporting references.

Download reviewed ZIP
1. Download

Save the ZIP without changing its contents.

2. Extract

Extract the Skill folder into one of these locations:

~/.codex/skills/implement-aibuds-factory-reset%USERPROFILE%\.codex\skills\implement-aibuds-factory-reset
3. Invoke

Use the invocation in your next Codex turn.

$implement-aibuds-factory-reset

The Skill becomes available on the next turn after installation.

Verified packageSHA-256ff3a1c2f7a4c36b1f31c75621cafc7ea8b2a4628d2db03700ed683209a22d299
SKILL.md

Implement AIBuds Factory Reset

Add factory reset to the consumer application's existing device experience without replacing its connection architecture or UI framework.

Workflow

  1. Read references/implementation.md completely.
  2. Inspect how the application stores the connected DeviceConvertible, presents destructive confirmations, reports errors, and observes connection changes.
  3. Confirm that the target already has a connected-device flow. If it does not, explain that prerequisite instead of inventing a second device manager.
  4. Add an explicit destructive-action confirmation using the application's existing UI conventions.
  5. Check DeviceCommonAPI conformance before enabling or executing the action.
  6. Call factoryReset(_:) only after confirmation. Handle both success and nullable error, and return to the main queue before changing UI.
  7. Keep observing the application's existing SDK connection/state callbacks. Do not use a fixed delay or promise identical reset, restart, erasure, or re-pair behavior across devices.
  8. Add focused verification for unsupported devices, cancellation, success, failure with an error, and failure with a nil error.

Constraints

  • Use only public AIBuds SDK API.
  • Preserve unrelated application code and architecture.
  • Prevent duplicate submissions while the request is in flight.
  • Do not force-cast protocol support.
  • Do not expose raw implementation or transport concepts to application code.
  • Do not claim device-specific side effects unless the product specification supplied by the developer guarantees them.

Completion criteria

  • Unsupported devices cannot execute the operation.
  • The user must explicitly confirm the destructive action.
  • Success and failure both produce stable UI feedback on the main queue.
  • A nil error cannot crash or produce an empty failure message.
  • Follow-up state comes from SDK callbacks rather than timing assumptions.