Implement API throttling policies to protect backend services from overload. Use when controlling API request rates. Trigger with phrases like "throttle API", "control request rate", or "add throttling".
68
62%
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/api-development/api-throttling-manager/skills/throttling-apis/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 solid description with clear trigger terms and explicit 'when' guidance, making it easy for Claude to select appropriately. Its main weakness is that the 'what' portion is somewhat general—it describes the goal (implement throttling policies) without listing specific concrete actions or techniques involved. Adding more specific capabilities would strengthen it.
Suggestions
Expand the capability description with specific concrete actions, e.g., 'Configure rate limits, set burst allowances, implement token bucket or sliding window algorithms, define retry-after headers, and set up per-client quotas.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (API throttling) and a general action ('implement API throttling policies to protect backend services from overload'), but does not list multiple specific concrete actions like setting rate limits, configuring burst allowances, implementing token buckets, or defining retry-after headers. | 2 / 3 |
Completeness | Clearly answers both 'what' (implement API throttling policies to protect backend services) and 'when' (use when controlling API request rates, with explicit trigger phrases). The 'Use when...' clause and trigger phrases are explicitly stated. | 3 / 3 |
Trigger Term Quality | Includes natural trigger phrases users would say: 'throttle API', 'control request rate', 'add throttling', plus related terms like 'API request rates' and 'throttling policies'. These cover common variations well. | 3 / 3 |
Distinctiveness Conflict Risk | API throttling is a clear, specific niche distinct from general API development, rate limiting at the infrastructure level, or load balancing. The trigger terms ('throttle API', 'add throttling') are unlikely to conflict with other skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a well-organized overview of API throttling implementation with clear structure and error handling, but critically lacks any executable code or concrete implementation examples—making it more of a design document than an actionable skill. The instructions describe what to build at a high level without showing how, which significantly limits Claude's ability to act on them directly.
Suggestions
Add executable code examples for at least the core concurrency limiter middleware (e.g., a complete Express middleware with in-memory counter) and the circuit breaker pattern—these are the minimum for actionability.
Include a validation checkpoint after step 2 (e.g., 'Test with `curl` to verify 503 responses when limit is exceeded') and after step 4 (verify circuit breaker trips correctly) to create feedback loops.
Provide the referenced bundle files (implementation.md, errors.md, examples.md) or inline the critical implementation details, since without them the skill delegates all actionable content to nonexistent files.
Trim the overview and prerequisites sections—Claude doesn't need explanations of what throttling is or what Redis does; focus on the specific configuration choices and constraints unique to this skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is reasonably structured but includes some unnecessary verbosity—the overview restates concepts Claude already understands (what backpressure is, what circuit breakers do), and the examples section describes scenarios in prose rather than providing executable code. The prerequisites section lists things Claude can infer from context. | 2 / 3 |
Actionability | Despite listing 8 steps, the instructions are entirely descriptive with zero executable code, no concrete configuration snippets, no middleware implementation examples, and no copy-paste ready commands. Every step reads as a high-level description rather than actionable guidance Claude can directly execute. | 1 / 3 |
Workflow Clarity | Steps are sequenced logically from analysis through implementation to testing, but there are no validation checkpoints between steps—no 'verify the middleware works before adding priority queues' or feedback loops for error recovery during implementation. Step 8 mentions load tests but doesn't integrate validation into the workflow itself. | 2 / 3 |
Progressive Disclosure | References to implementation.md, errors.md, and examples.md are well-signaled and one level deep, which is good structure. However, no bundle files are provided, meaning these references point to nonexistent files, and the main SKILL.md itself contains substantial inline content (error table, output listing) that could benefit from better organization. | 2 / 3 |
Total | 7 / 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 | |
3a2d27d
Table of Contents
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.