evernote-webhooks-events
Implement Evernote webhook notifications and sync events. Use when handling note changes, implementing real-time sync, or processing Evernote notifications. Trigger with phrases like "evernote webhook", "evernote events", "evernote sync", "evernote notifications".
77
73%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/saas-packs/evernote-pack/skills/evernote-webhooks-events/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, clearly specifying both what the skill does and when to use it. The main weakness is that the capability description could be more specific about the concrete actions performed (e.g., parsing webhook payloads, verifying webhook signatures, handling specific event types). Overall it performs well for skill selection purposes.
Suggestions
Add more specific concrete actions like 'parse webhook payloads, verify webhook signatures, handle note creation/update/deletion events' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Evernote webhooks) and some actions ('implement webhook notifications', 'sync events'), but doesn't list multiple concrete specific actions like parsing payloads, verifying signatures, handling specific event types, etc. | 2 / 3 |
Completeness | Clearly answers both 'what' (implement Evernote webhook notifications and sync events) and 'when' (handling note changes, implementing real-time sync, processing notifications) with explicit trigger phrases. | 3 / 3 |
Trigger Term Quality | Includes explicit natural trigger terms: 'evernote webhook', 'evernote events', 'evernote sync', 'evernote notifications', plus contextual phrases like 'note changes', 'real-time sync'. These are terms users would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Very specific niche targeting Evernote webhooks and sync events. The combination of 'Evernote' with 'webhook', 'sync', and 'notifications' creates a distinct trigger profile unlikely to conflict with other skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
57%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 reasonable overview of Evernote webhook implementation with good structure and progressive disclosure, but falls short on actionability—key steps like event routing, idempotency, and polling are described rather than demonstrated with code. The workflow is logically sequenced but lacks validation checkpoints for what is essentially a stateful sync operation where errors could cause missed data.
Suggestions
Add executable code for the polling fallback (Step 5) and event handler routing (Step 4) instead of just describing them, or explicitly state these are in the referenced implementation guide
Add a validation checkpoint after sync chunk retrieval to verify chunk completeness (e.g., check if chunk.chunkHighUSN matches expected state) before processing events
Trim Step 2 into a brief inline list or table rather than a separate step—the three reason types are already mentioned in Step 1's code comments and don't need their own step
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient but includes some unnecessary explanation (e.g., 'Understanding of Evernote sync API' as a prerequisite, explaining what webhook reasons mean when Claude would know). The prose around steps could be tighter—Step 2 is mostly descriptive without adding actionable value beyond what's in Step 1's code. | 2 / 3 |
Actionability | Provides two executable code snippets (webhook endpoint and sync chunk), but Steps 2, 4, and 5 are descriptive rather than providing concrete code. The event routing, idempotency tracking, and polling fallback are described abstractly without executable implementations, and the full implementation is deferred to a reference file. | 2 / 3 |
Workflow Clarity | Steps are clearly sequenced (receive webhook → handle reasons → sync state → process events → polling fallback), but there are no explicit validation checkpoints. For a webhook/sync workflow involving state management and potential data loss from missed events, there should be verification steps (e.g., validate sync chunk completeness, verify USN tracking is persisted). | 2 / 3 |
Progressive Disclosure | Good structure with a clear overview, stepped instructions, error handling table, and a single-level reference to the implementation guide. Resources and next steps are well-signaled. Content is appropriately split between the overview skill and the referenced implementation guide. | 3 / 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
70e9fa4
- 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.