evernote-upgrade-migration
Upgrade Evernote SDK versions and migrate between API versions. Use when upgrading SDK, handling breaking changes, or migrating to newer API patterns. Trigger with phrases like "upgrade evernote sdk", "evernote migration", "update evernote", "evernote breaking changes".
74
70%
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-upgrade-migration/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 clear 'what' and 'when' clauses, explicit trigger phrases, and a highly distinctive niche. The main weakness is that the specific capabilities could be more detailed — listing concrete migration actions beyond the general 'upgrade' and 'migrate' would strengthen it.
Suggestions
Add more specific concrete actions, e.g., 'update deprecated API calls, refactor authentication flows, update dependency versions in package files' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Evernote SDK) and some actions (upgrade versions, migrate between API versions), but doesn't list specific concrete actions like 'update authentication methods', 'refactor deprecated API calls', or 'update dependency configurations'. | 2 / 3 |
Completeness | Clearly answers both 'what' (upgrade Evernote SDK versions and migrate between API versions) and 'when' (upgrading SDK, handling breaking changes, migrating to newer API patterns) with explicit trigger phrases. | 3 / 3 |
Trigger Term Quality | Includes explicit natural trigger phrases like 'upgrade evernote sdk', 'evernote migration', 'update evernote', 'evernote breaking changes' — these are terms users would naturally say when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | Very specific niche — Evernote SDK upgrades and migrations. Unlikely to conflict with other skills due to the narrow, product-specific focus on Evernote. | 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.
This skill provides a reasonable structure for Evernote SDK migration with some useful concrete examples (callback-to-Promise conversion, compatibility layer), but suffers from vague steps (especially Steps 5 and 6), missing validation checkpoints critical for a migration workflow, and moderate verbosity. The error handling table is a nice touch, but the overall actionability is uneven across steps.
Suggestions
Add explicit validation checkpoints after the upgrade (e.g., 'Run `npm test` and verify all Evernote-related tests pass before proceeding') and include rollback instructions if validation fails.
Make Steps 5 and 6 concrete with executable code examples—provide a sample test case for the compatibility layer and a concrete deprecation warning implementation.
Remove filler sentences that describe intent rather than instruct (e.g., 'This allows upgrading module by module instead of a big-bang rewrite') and trim the Prerequisites section which states things Claude can infer.
Replace `npm view evernote repository.url` with an actually useful command for viewing changelogs, such as directing to the GitHub releases page directly.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes some unnecessary filler (e.g., 'Understanding of current implementation patterns' as a prerequisite, verbose step descriptions like 'Build a compatibility layer that supports both old and new SDK patterns during gradual migration. This allows upgrading module by module instead of a big-bang rewrite.'). The Overview section restates what the title already conveys. However, it's not egregiously verbose—most content is relevant. | 2 / 3 |
Actionability | The code examples for callback-to-Promise conversion and the compatibility layer are concrete and useful. However, Steps 1, 5, and 6 are vague descriptions rather than executable guidance ('Update test assertions for new SDK response shapes' gives no concrete code). The bash commands in Step 1 are helpful but `npm view evernote repository.url` doesn't actually show a changelog. | 2 / 3 |
Workflow Clarity | Steps are sequenced logically, but there are no explicit validation checkpoints. For a migration/upgrade workflow involving potentially destructive changes, there should be explicit 'verify the upgrade works' steps, rollback instructions, and feedback loops. Step 5 mentions testing but doesn't provide concrete validation commands or criteria for success. | 2 / 3 |
Progressive Disclosure | There is a reference to an implementation guide ('references/implementation-guide.md') and a next-steps link to 'evernote-ci-integration', which is good. However, the main content is somewhat long with inline details that could be split out (e.g., the error handling table, the full compatibility layer code), and the reference structure could be more clearly signaled with a dedicated section. | 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 | |
- 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.