fleet-ack

Track fleet message delivery with ACK-based retries and failure alerts.

2|Updated Apr 5, 2026
One-click install
npx skills add https://github.com/supportersimulator/multi-fleet --skill fleet-ack
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fleet-ack
Source: https://github.com/supportersimulator/multi-fleet/tree/main/skills/fleet-ack
Command: npx skills add https://github.com/supportersimulator/multi-fleet --skill fleet-ack

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Fleet messages are not reliably delivered without acknowledgments; this protocol provides an ACK-driven delivery mechanism that tracks, retries on timeout, and raises alerts on failure.

Core Features & Use Cases

  • ACK tracking for every message to confirm delivery.
  • Retry on timeout with configurable timeouts and max retries.
  • Failure alerting to surface unreached messages within sessions.
  • Persistent retry state using SQLite to survive restarts and outages. Use case: Ensuring critical fleet commands reach all nodes in unreliable networks.

Quick Start

Configure your fleet to enable ACK-based delivery and deploy a node to start sending messages with automatic retries.

Frequently Asked Questions about fleet-ack

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

FAQPage Schema
How do I ensure reliable fleet message delivery across unreliable networks?

Fleet message delivery is tracked using ACKs for every message, automatically retrying on timeout. It maintains a persistent retry loop across channels that survives restarts and emits failure alerts after max retries are exceeded.

Why do I need ACK-based retries for my NATS fleet commands?

ACK-based retries are needed because fleet messages are not reliably delivered without acknowledgments. This mechanism tracks delivery, retries on timeout, and raises alerts on failure to ensure critical commands reach all nodes.

How do I configure automatic retry timeouts for fleet alerts?

Automatic retry timeouts are configured using environment controls for ack_timeout and max_retries. These settings define the wait period and retry threshold before the system emits failure alerts for unreached fleet messages.

Does the fleet ACK retry state survive system restarts?

Yes, the fleet ACK retry state survives restarts by using SQLite for persistent storage. This persistent retry loop retains pending message acknowledgments and retry counts across outages and application restarts.

What happens when fleet messages exceed the maximum retry limit?

When fleet messages exceed the maximum retry limit, the system emits failure alerts to surface unreached messages within sessions. This surfaces persistent delivery failures for manual intervention.

Do I need a SQLite database to track fleet ACKs?

Yes, a SQLite database is required because the system uses FleetNerveStore for persistent ACK tracking. SQLite stores delivery state and retry counters, enabling the retry loop to survive restarts and outages.