Agent skill · software engineering · jeremylongshore
lucidchart-rate-limits
Design endpoint-specific Lucid request pacing, 429 handling, backpressure, and safe retry behavior. Use when hardening REST or connector traffic. Trigger with "handle Lucid rate limits".
Why this skill is useful
Includes an executable rate limiter class and retry strategy for managing Lucidchart API rate limits that aren't in public documentation.
What it needs
Requires lucidchart account access. About 2k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Lucid Rate-Limit and Backpressure Design Overview Ground request control in the exact Lucid endpoint contract and observed responses. There is no justified pack-wide fixed requests-per-minute value. Prerequisites Inventory of operations, mutation semantics, concurrency, callers, and service objectives Current endpoint documentation and sanitized response headers/bodies Stable idempotency or reconciliation strategy for mutations Tool Discipline Use Read, Glob, and Grep to inspect clients and tests, WebFetch for current endpoint/limit documentation, and Write or Edit only for local policy, code, tests, and receipts. Current Contract Treat limits as endpoint/API-specific and time-sensitive. A legacy or Data API limit must not be generalized to document, export, import, Extension API, or connector operations. Server responses and current endpoint pages control. Authentication Rate limiting does not justify credential pooling or scope expansion. Partition traffic by approved principal and tenant while keeping tokens out of metrics and logs. Instructions 1. Enumerate each operation's method, read/write effect, caller, principal, concurrency, and retry safety. 2. Re-fetch the exact operation and rate-limit documentation; record only explicitly documented values. 3. Instrument requests, success/error counts, latency, queue age, and safe server rate-limit/retry metadata. 4. Use bounded queues, per-operation concurrency, jitter, and backpressure before retries. 5. Retry only documented transient failures. For writes, require idempotency support or reconciliation before replay. 6. Honor documented Retry-After or equivalent server guidance when present; otherwise use conservative capped backoff based on observed behavior. 7. Test synthetic 429, timeout-before-response, partial batch, queue saturation, cancellation, and recovery. 8. Present any production concurrency or replay-policy change for approval and deploy as a monitored canary. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/lucidchart-rate-limits