lucidchart-rate-limits

v2026.09.24

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".

GitHub
安装命令
npx skhub add jeremylongshore/lucidchart-rate-limits
Markdown
SKILL.md

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.

Approval Boundaries

Do not increase production load, pool credentials, bypass queues, or replay ambiguous mutations without approval and reconciliation.

Output

Return operation matrix, documented/unknown limits, observed response evidence, queue/retry policy, tests, approval, canary result, and remaining risks.

Error Handling

ConditionResponse
Limit is undocumentedMark unknown and design adaptive backpressure; do not invent a number.
Mutation timed out ambiguouslyReconcile before retrying.
Sustained 429s continueStop adding load, drain safely, and escalate with redacted evidence.

Example

operation=document-create; published-limit=unknown; concurrency=2; 429-test=pass; ambiguous-write=reconcile

Resources

Next Steps

Review observed traffic after the canary and tune only against verified endpoint evidence.

发现
标签

此技能尚未发布标签。

版本
最新版本元数据

版本

v2026.09.24

发布时间

Sep 24, 2026

分类

未分类

许可证

MIT

源路径

skills/.curated/lucidchart-rate-limits

默认分支

main

最新提交

e5a6c3b

Tree SHA

c2dc8e8