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".
80
77%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/saas-packs/apollo-pack/skills/apollo-rate-limits/SKILL.mdQuality
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
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a highly actionable skill with executable, well-structured TypeScript code covering rate limiting, backoff, queuing, and monitoring for Apollo.io. Its main weaknesses are the lack of validation checkpoints in the workflow (important for operations that can burn API credits) and the monolithic structure that could benefit from splitting code into referenced bundle files. The content is slightly verbose in places but generally earns its token usage through concrete, specific guidance.
Suggestions
Add explicit validation checkpoints, e.g., 'Test with a single request to verify x-rate-limit-* headers are parsed correctly before running bulk operations'
Split the TypeScript modules into actual bundle files (rate-limiter.ts, backoff.ts, queue.ts, rate-monitor.ts) and reference them from SKILL.md to improve progressive disclosure
Remove the Prerequisites section and trim the Overview to just the key insight (per-minute fixed-window limits, 429 responses) since Claude can infer the rest
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient with executable code and useful tables, but includes some unnecessary elements like the Prerequisites section (Claude knows Node.js requirements), the verbose Overview explanation of fixed-window vs per-minute distinctions, and the 'Unreachable' throw comment. The rate limit table with specific numbers is valuable, but the overall document could be tightened by ~20%. | 2 / 3 |
Actionability | Fully executable TypeScript code with proper imports, concrete class implementations, and a complete end-to-end example showing bulk search with rate limiting. The code is copy-paste ready with real Apollo endpoint paths, specific limit values, and practical patterns like PQueue integration and Axios interceptors. | 3 / 3 |
Workflow Clarity | Steps are clearly sequenced (understand limits → build limiter → add backoff → add queue → monitor), but there are no explicit validation checkpoints. For a system involving rate limiting and retry logic—where misconfiguration can lead to API bans or credit waste—there should be verification steps (e.g., 'test with a single request and verify headers are being read correctly before running bulk operations'). | 2 / 3 |
Progressive Disclosure | The content is a monolithic file with ~150+ lines of inline code that could benefit from being split into referenced files (e.g., the rate limit table, the individual TypeScript modules). The Resources section links to external docs and there's a Next Steps reference, but the body itself is a wall of code blocks with no bundle files to offload detail into. | 2 / 3 |
Total | 9 / 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
3a2d27d
- 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.