Handle Evernote API rate limits effectively. Use when implementing rate limit handling, optimizing API usage, or troubleshooting rate limit errors. Trigger with phrases like "evernote rate limit", "evernote throttling", "api quota evernote", "rate limit exceeded".
74
70%
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/evernote-pack/skills/evernote-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 solid skill description with excellent trigger terms and completeness. Its main weakness is that the capability description could be more specific about what concrete actions or strategies it provides (e.g., retry logic, exponential backoff, quota tracking). The narrow Evernote + rate limiting focus makes it highly distinctive.
Suggestions
Add more specific concrete actions like 'implement exponential backoff, track quota usage, configure retry strategies' to improve specificity beyond the general 'handle' and 'optimize' language.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (Evernote API rate limits) and mentions some actions ('implementing rate limit handling, optimizing API usage, troubleshooting rate limit errors'), but these are somewhat generic and don't list concrete specific actions like retry strategies, backoff algorithms, or quota monitoring. | 2 / 3 |
Completeness | Clearly answers both 'what' (handle Evernote API rate limits, implement handling, optimize usage, troubleshoot errors) and 'when' (explicit 'Use when...' clause and 'Trigger with phrases like...' providing clear activation guidance). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms that users would actually say: 'evernote rate limit', 'evernote throttling', 'api quota evernote', 'rate limit exceeded'. These cover common variations of how users would describe this problem. | 3 / 3 |
Distinctiveness Conflict Risk | Very specific niche combining Evernote + API rate limits. Unlikely to conflict with other skills due to the narrow, well-defined scope and Evernote-specific trigger terms. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides a reasonable structure for handling Evernote rate limits with two solid executable code examples, but falls short by leaving three of five steps as prose descriptions without code. The error handling table and external references add value, but the overall content is uneven — half actionable, half descriptive — and includes some unnecessary explanation that Claude wouldn't need.
Suggestions
Add executable code for Steps 3 (batch operations), 4 (caching example), and 5 (monitoring) — or remove the prose descriptions and consolidate them into the referenced implementation guide with a clear pointer.
Remove the Prerequisites section entirely — Claude already understands async/await and error handling patterns.
Trim the descriptive sentences before each code block (e.g., 'Catch EDAMSystemException and check for rateLimitDuration') since the code itself demonstrates the approach clearly.
Provide the referenced `references/implementation-guide.md` bundle file or remove the reference to avoid a dead link.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill has some unnecessary padding — the Prerequisites section lists things Claude already knows (async/await, error handling), and Steps 3-5 describe concepts without providing executable code, adding bulk without proportional value. The prose before code blocks often restates what the code already shows. | 2 / 3 |
Actionability | Steps 1 and 2 provide executable JavaScript code, but Steps 3, 4, and 5 are purely descriptive with no concrete code. The Examples section describes scenarios in prose rather than showing executable implementations. This creates an uneven mix of actionable and vague guidance. | 2 / 3 |
Workflow Clarity | The steps are sequenced logically and the error handling table is a nice addition, but Steps 3-5 lack concrete validation checkpoints. There's no explicit feedback loop for verifying that rate limiting is working correctly (e.g., checking logs, testing with a dry run), and the transition from retry handler to client wrapper to batch operations lacks integration guidance. | 2 / 3 |
Progressive Disclosure | The skill references an implementation guide at `references/implementation-guide.md` and a related skill `evernote-security-basics`, which is good structure. However, no bundle files are provided, so the reference is unverifiable. Steps 3-5 contain inline descriptive content that would be better served as executable code either inline or in the referenced file, creating an awkward middle ground. | 2 / 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 | |
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.