apollo-rate-limits
Implement Apollo.io rate limiting and backoff. Use when handling rate limits, implementing retry logic, or optimizing API request throughput. Trigger with phrases like "apollo rate limit", "apollo 429", "apollo throttling", "apollo backoff", "apollo request limits".
68
83%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a well-structured skill description with strong trigger terms and clear 'what/when' guidance. Its main weakness is that the capability description could be more specific about the concrete actions performed (e.g., exponential backoff implementation, 429 response handling, request queuing). Overall it would serve well for skill selection in a large skill library.
Suggestions
Add more specific concrete actions like 'implement exponential backoff strategies', 'handle HTTP 429 responses', 'configure request queuing and throttling' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Apollo.io rate limiting) and some actions (rate limiting, backoff, retry logic, optimizing throughput), but doesn't list multiple concrete specific actions like 'implement exponential backoff', 'handle 429 responses', 'queue requests', etc. | 2 / 3 |
Completeness | Clearly answers both 'what' (implement Apollo.io rate limiting and backoff) and 'when' (handling rate limits, implementing retry logic, optimizing API request throughput) with explicit trigger phrases. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms including 'apollo rate limit', 'apollo 429', 'apollo throttling', 'apollo backoff', 'apollo request limits' — these are terms users would naturally use when encountering this problem. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — scoped specifically to Apollo.io API rate limiting, which is a clear niche unlikely to conflict with other skills. The 'apollo' prefix on all trigger terms further reduces conflict risk. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, highly actionable skill with complete, executable TypeScript implementations covering rate limiting, backoff, queuing, and monitoring for Apollo.io's API. The workflow is well-sequenced and includes proper error recovery strategies. Main weaknesses are moderate verbosity (explaining concepts Claude already knows, time-sensitive rate limit tables) and a monolithic structure that could benefit from splitting detailed implementations into referenced bundle files.
Suggestions
Remove the Prerequisites section and trim the Overview to just the key differentiators (per-minute fixed-window, per-second burst) without explaining what 429 means.
Move the rate limit table to a separate reference file (e.g., RATE_LIMITS.md) to reduce main file length and make the table easier to update independently.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient with good code examples, but includes some unnecessary elements: the rate limit table with specific 2025 dates risks staleness, the 'Prerequisites' section is trivially obvious, and the 'Output' section restates what the code already demonstrates. The overview paragraph explaining what fixed-window rate limiting is and what HTTP 429 means is unnecessary for Claude. | 2 / 3 |
Actionability | Fully executable TypeScript code with complete implementations for rate limiting, backoff, queue management, and monitoring. Each code block is copy-paste ready with proper imports, types, and realistic configurations. The error handling table provides concrete strategies for each scenario. | 3 / 3 |
Workflow Clarity | The 5-step sequence is logically ordered from understanding limits → building limiter → adding backoff → queue control → monitoring. Each step builds on the previous one. The error handling table serves as a validation/recovery reference, and the rate monitor at 80% threshold provides an explicit feedback loop for approaching limits. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections, but it's a monolithic file with ~200 lines of code that could benefit from splitting implementation details into separate files. The references to external docs and p-queue are good, but there are no bundle files to offload the detailed implementations, and the 'Next Steps' reference to 'apollo-security-basics' is unverifiable. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- Commit
6e9558f
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.