17track package tracking

**Quick judgement** A solid, focused skill for parcel tracking that leverages the 17TRACK API with a local SQLite store. It is well-suited for users who frequently track multiple packages and want the assistant to remember, sync, and summarise their shipment statuses over time. **What it does well** - Maintains a persistent local database of parcels under the workspace, so tracking history survives bot restarts. - Uses the official 17TRACK API v2.2 with support for carrier auto-detection and explicit carrier codes when needed. - Offers both polling (`sync`) and webhook ingestion (webhook server + inbox processing), covering simple and advanced deployment scenarios. - Provides clear operational commands: `init`, `add`, `list`, `sync`, `status`, `stop`, `retrack`, `remove`, `delete-remote`, and `quota`. - Includes explicit agent guidance: prefer polling unless the user wants webhooks; after adding a package, call `status` once to confirm carrier/status; summarise updates with priority on delivered, out-for-delivery, exceptions, customs, and handoffs. **Key risks / limitations** - **External dependency**: Completely dependent on the 17TRACK API (availability, rate limits, and token validity). If the API is down or the quota exhausted, tracking will fail or degrade. - **Configuration overhead**: Requires a valid `TRACK17_TOKEN` environment variable and Python 3. Webhook verification also needs `TRACK17_WEBHOOK_SECRET` if used. Misconfiguration will cause failures that the agent must detect and surface clearly. - **Webhook complexity**: The webhook server mode is more operationally complex (requires binding to a port, reverse proxy/tunnel, optional inbox processing), so it should be reserved for advanced users. - **Local storage assumptions**: Relies on being able to write to the workspace’s `packages/track17/` directory (or overrides). Read-only or unusual filesystem layouts may cause subtle issues. **Safety & security considerations** - Uses environment variables for secrets (`TRACK17_TOKEN`, `TRACK17_WEBHOOK_SECRET`), which is standard but still requires safe handling by the host environment. - The operating guidance explicitly instructs the agent to never echo these secrets, reducing risk of accidental exposure in conversations or logs. - Webhook verification via `TRACK17_WEBHOOK_SECRET` helps mitigate spoofed webhook payloads when correctly configured. - SQLite-based storage is local to the workspace; risk is mainly limited to local data exposure rather than remote data leaks. **Recommended scenarios** - Users who regularly track shipments (e.g., heavy online shoppers, small e-commerce operators) and want the assistant to remember and summarise all parcels across carriers in one place. - Chat-centric workflows where the user asks, “Where are my packages?” and expects a concise, prioritised summary (delivered, out for delivery, exceptions, customs holds, handoffs) without digging into raw tracking data. - Environments where running Python 3 and setting environment variables is acceptable, and where a lightweight local SQLite database is suitable. **Less suitable scenarios** - Strictly offline or highly restricted environments that cannot reach the 17TRACK API, or where installing Python/running background scripts is not allowed. - Users who cannot or will not manage a 17TRACK API token or webhook infrastructure (for near–real-time updates). For these, stick to basic polling or a simpler tracking approach. Overall, this is a capable, relatively mature tracking skill (as suggested by its download count) that fits well into an assistant’s toolbox for ongoing parcel tracking, provided the environment can supply a valid 17TRACK token and basic Python runtime support.