clay-upgrade-migration
Analyze, plan, and execute Clay SDK upgrades with breaking change detection. Use when upgrading Clay SDK versions, detecting deprecations, or migrating to new API versions. Trigger with phrases like "upgrade clay", "clay migration", "clay breaking changes", "update clay SDK", "analyze clay version".
Install with Tessl CLI
npx tessl i github:jeremylongshore/claude-code-plugins-plus-skills --skill clay-upgrade-migration74
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
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 well-structured skill description with excellent trigger term coverage and clear when/what guidance. The main weakness is that the specific capabilities could be more detailed - what exactly does 'analyze' or 'plan' entail? The explicit trigger phrases and Clay-specific focus make it highly distinctive and unlikely to conflict with other skills.
Suggestions
Expand specificity by listing concrete actions like 'generates migration scripts', 'identifies deprecated API calls', or 'creates upgrade checklists'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Clay SDK upgrades) and some actions (analyze, plan, execute, detect breaking changes), but lacks comprehensive specific actions like what analysis entails or what migration steps are performed. | 2 / 3 |
Completeness | Clearly answers both what (analyze, plan, execute upgrades with breaking change detection) and when (explicit 'Use when...' clause plus 'Trigger with phrases like...' providing concrete activation scenarios). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would say: 'upgrade clay', 'clay migration', 'clay breaking changes', 'update clay SDK', 'analyze clay version', plus mentions deprecations and API versions. | 3 / 3 |
Distinctiveness Conflict Risk | Very specific niche targeting Clay SDK specifically, with distinct triggers unlikely to conflict with generic upgrade or migration skills due to the 'Clay' qualifier throughout. | 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 framework for Clay SDK upgrades with good structure and some executable examples. However, it falls short on the critical Step 4 which is vague, lacks validation checkpoints between steps, and includes some mislabeled/unnecessary content (the compatibility table under 'Error Handling'). The deprecation handling code is generic Node.js rather than Clay-specific.
Suggestions
Expand Step 4 with concrete guidance: how to identify breaking changes (e.g., 'grep for deprecated imports', specific patterns to search for), and add a validation step after fixing changes
Add explicit validation checkpoint after Step 4: 'Run npm test again to verify all breaking changes are resolved. If tests fail, review error messages and repeat Step 4'
Rename 'Error Handling' section to 'Version Compatibility' since it's a compatibility matrix, not error handling guidance
Remove or condense the generic deprecation warning code - Claude knows how to handle Node.js warnings; focus on Clay-specific deprecation patterns instead
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient but includes some unnecessary sections like the compatibility table under 'Error Handling' (mislabeled) and the deprecation handling code which is generic Node.js knowledge rather than Clay-specific guidance. | 2 / 3 |
Actionability | Provides executable bash and TypeScript examples, but Step 4 'Handle Breaking Changes' is vague ('Update import statements, configuration, and method signatures as needed') without concrete guidance on how to identify what needs changing. | 2 / 3 |
Workflow Clarity | Steps are numbered and sequenced, but lacks explicit validation checkpoints between steps. No feedback loop for when 'npm test' fails in Step 3, and no verification that breaking changes were properly addressed before proceeding. | 2 / 3 |
Progressive Disclosure | Well-organized with clear sections, appropriate length for a SKILL.md, and properly signals external resources and next steps with links to related documentation and skills. | 3 / 3 |
Total | 9 / 12 Passed |
Validation
75%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 12 / 16 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
metadata_version | 'metadata' field is not a dictionary | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
body_steps | No step-by-step structure detected (no ordered list); consider adding a simple workflow | Warning |
Total | 12 / 16 Passed | |
- 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.