throttling-apis
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".
71
66%
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.
The description is well-structured with explicit 'Use when' and trigger phrases, making it strong on completeness and distinctiveness. Its main weakness is that the 'what' portion is somewhat general—it describes the goal (throttling policies) without enumerating specific concrete actions like configuring rate windows, setting burst limits, or implementing retry-after headers.
Suggestions
Add more specific concrete actions, e.g., 'Configure rate limits, set burst thresholds, implement retry-after headers, define per-client quotas' to improve specificity.
| 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 configuring rate limits, setting burst limits, defining throttling tiers, or returning 429 responses. | 2 / 3 |
Completeness | Clearly answers both 'what' (implement API throttling policies to protect backend services) and 'when' (explicit 'Use when controlling API request rates' plus trigger phrases). The 'Use when...' clause is present and explicit. | 3 / 3 |
Trigger Term Quality | Includes natural trigger terms users would say: 'throttle API', 'control request rate', 'add throttling', plus 'API request rates' and 'throttling policies'. These cover the most common phrasings a user would use when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | API throttling is a clear, specific niche. The trigger terms ('throttle API', 'control request rate', 'add throttling') are distinct and unlikely to conflict with related but different skills like rate limiting at the network level or general API design. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill has good structural organization and progressive disclosure with clear references to supporting files, but critically lacks actionable, executable code examples—the core instructions read as high-level architectural guidance rather than concrete implementation steps. The content would benefit significantly from at least one complete, executable middleware example rather than deferring all implementation details to reference files.
Suggestions
Add at least one complete, executable code example for the core throttling middleware (e.g., an Express middleware with concurrency limiting) rather than deferring all code to implementation.md.
Include a concrete circuit breaker code snippet with configurable thresholds to make step 4 actionable rather than descriptive.
Add intermediate validation checkpoints between steps, such as verifying the concurrency limiter works before adding priority queues, to create feedback loops in the workflow.
Remove or condense the Prerequisites and Resources sections—Claude already knows about these frameworks and libraries—and use the saved tokens for actual code examples.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is moderately efficient but includes some unnecessary elaboration. The overview restates what the instructions cover, and some sections like Prerequisites and Resources explain things Claude would already know. The error handling table and examples section add useful but somewhat verbose context. | 2 / 3 |
Actionability | Despite listing 8 steps, the instructions are entirely descriptive with no executable code, no concrete commands, and no copy-paste ready examples. Steps like 'Implement a concurrency limiter middleware' and 'Build a circuit breaker' are abstract directions rather than actionable guidance. The actual implementation is deferred to a reference file. | 1 / 3 |
Workflow Clarity | Steps are sequenced logically from analysis through implementation to testing, and step 8 includes validation via load tests. However, there are no explicit validation checkpoints between steps, no feedback loops for error recovery during implementation, and the verification step comes only at the very end rather than being integrated throughout. | 2 / 3 |
Progressive Disclosure | Content is well-structured with clear sections and appropriately references external files (implementation.md, errors.md, examples.md) that are one level deep and clearly signaled. The main skill file serves as an overview with navigation to detailed materials. | 3 / 3 |
Total | 8 / 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
3e83543
- 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.