Agent skill · software engineering · jeremylongshore
bamboohr-rate-limits
Design bounded BambooHR retry, backpressure, and queue behavior from observed responses without inventing numeric quotas. Use when handling 429 or transient gateway failures, or preventing retry storms. Trigger with "BambooHR rate limit", "BambooHR 429", "BambooHR retry", or "BambooHR backoff".
Why this skill is useful
Adds specific implementation patterns for handling BambooHR API rate limits and optimizing request throughput that the AI wouldn't reliably generate on its own.
What it needs
Requires p-queue installed locally. Requires bamboohr account access. About 2k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
BambooHR Rate and Retry Control Overview Protect the tenant, worker pool, and downstream systems with a finite retry budget. BambooHR does not publish one universal numeric quota in the reviewed official sources, so do not turn an observed limit into a product guarantee. Prerequisites The target repository or integration path and the requested operator outcome. The tenant, identity, and data scope only when approved live work is in scope. The current evidence register plus customer-specific permissions and agreements. Current Contract The official Python SDK retries HTTP 408, 429, 504, and 598 with exponential delays beginning at 100 ms. Retry count is configurable from zero through five and defaults to one. It exposes RateLimitExceededException and request IDs. 503 is represented as service unavailable but is not in that documented automatic-retry set. Authentication Retries must reuse the same tenant-bound identity without logging or rebuilding its token. If an OAuth token expires, permit one refresh workflow; do not count repeated authentication failures as rate-limit retries. Instructions 1. Inventory every caller, concurrency source, scheduled sync, webhook replay, and manual job that shares the tenant identity. 2. Classify operations as read-only, idempotent with a key, conditionally safe, or unsafe to retry. Default mutations to no automatic retry. 3. On 429, parse and honor a valid Retry-After value when present; otherwise use capped exponential backoff with jitter. Bound total attempts and elapsed time. 4. For 408, 504, or 598, apply the same budget only to retry-safe work. Treat other failures according to explicit application policy, not by widening the SDK's documented set accidentally. 5. Centralize per-tenant concurrency and queue limits. Add a circuit breaker for sustained failures and spread scheduled full syncs. 6. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/bamboohr-rate-limits