CtrlK
BlogDocsLog inGet started
Tessl Logo

deprecation-and-migration

Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when deciding whether to maintain or sunset existing code.

50

Quality

54%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/deprecation-and-migration/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

27%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This skill reads more like an engineering philosophy essay or handbook chapter than a concise, actionable skill for Claude. It extensively explains concepts Claude already understands (code as liability, Hyrum's Law, common design patterns) and spends significant tokens on rationalizations and principles rather than concrete, executable guidance. The strongest elements are the deprecation notice template, the verification checklist, and the migration step sequence, but these are buried in verbose surrounding content.

Suggestions

Cut the content by 60-70%: remove 'Core Principles', 'Common Rationalizations', and explanations of well-known patterns (Strangler, Adapter, Feature Flags). Keep only the decision framework, migration steps, templates, and verification checklist.

Make the deprecation decision framework a concrete, executable checklist or decision tree rather than prose questions with philosophical commentary.

Split detailed migration patterns and examples into a separate PATTERNS.md reference file, keeping SKILL.md as a concise overview with links.

Add specific tool commands or scripts Claude should use for verification steps (e.g., grep for references, dependency analysis commands) rather than abstract instructions like 'verify zero active usage'.

DimensionReasoningScore

Conciseness

Extremely verbose. Explains concepts Claude already knows well (Hyrum's Law, Strangler Pattern, Adapter Pattern, feature flags, what zombie code is). The 'Core Principles' section explains that code has maintenance cost — something Claude deeply understands. The 'Common Rationalizations' table, while potentially useful, is largely common sense. The entire document reads like a blog post or engineering handbook chapter rather than a concise skill instruction. At ~200+ lines, most content could be cut to under 50 lines of actionable guidance.

1 / 3

Actionability

There are some concrete elements — the deprecation notice template, the migration checklist, the adapter pattern code example, and the verification checklist are useful. However, much of the content is philosophical/advisory rather than executable. The code examples are illustrative but not tied to specific tool usage or commands Claude would actually run. The decision framework is presented as prose questions rather than a concrete decision tree or script.

2 / 3

Workflow Clarity

The 4-step migration process (Build → Announce → Migrate → Remove) provides a clear sequence, and Step 4 includes a verification step. However, the validation checkpoints are mostly checklists at the end rather than integrated feedback loops. The incremental migration steps mention 'verify behavior matches' but don't specify how. For destructive operations like removing code, the verification could be more explicit about what to do when checks fail.

2 / 3

Progressive Disclosure

The entire skill is a monolithic wall of text with no references to external files. Content like migration patterns, common rationalizations, and zombie code identification could be split into separate reference files. There's no bundle structure to support progressive disclosure, and the skill doesn't attempt to organize content into overview vs. detailed reference materials.

1 / 3

Total

6

/

12

Passed

Description

82%

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' triggers covering multiple scenarios, which is its strongest aspect. The trigger terms are natural and relevant. However, the specific capabilities could be more concrete—listing actual actions like 'create migration plans', 'write deprecation notices', or 'generate compatibility layers' would strengthen it and help distinguish it from adjacent skills.

Suggestions

Add more concrete actions beyond 'manages'—e.g., 'Creates migration plans, writes deprecation notices, identifies breaking changes, generates backward-compatible wrappers'

Sharpen distinctiveness by specifying what differentiates this from general refactoring or API design skills—e.g., mention versioning strategies, deprecation timelines, or user communication

DimensionReasoningScore

Specificity

Names the domain (deprecation and migration) and mentions some actions like 'removing old systems', 'migrating users', and 'deciding whether to maintain or sunset', but these are fairly high-level and not concrete specific actions (e.g., no mention of writing migration scripts, generating deprecation notices, versioning APIs, etc.).

2 / 3

Completeness

Clearly answers both 'what' (manages deprecation and migration) and 'when' with multiple explicit 'Use when...' clauses covering removing old systems, migrating users, and deciding on sunsetting code.

3 / 3

Trigger Term Quality

Includes strong natural keywords users would say: 'deprecation', 'migration', 'removing old systems', 'APIs', 'features', 'sunset', 'migrating users'. These cover common variations of how users would describe this need.

3 / 3

Distinctiveness Conflict Risk

The deprecation/migration niche is reasonably specific, but terms like 'APIs', 'features', and 'existing code' are broad enough to potentially overlap with API design skills, code refactoring skills, or general software architecture skills.

2 / 3

Total

10

/

12

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
addyosmani/agent-skills
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.