retire-legacy-distribution-surface
Pattern for safely removing an obsolete package/distribution surface without breaking the surviving release path.
43
29%
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 ./.squad/skills/retire-legacy-distribution-surface/SKILL.mdQuality
Discovery
17%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 too abstract and jargon-heavy, using phrases like 'distribution surface' and 'surviving release path' that obscure the skill's concrete purpose. It lacks a 'Use when...' clause, specific trigger terms users would naturally employ, and concrete action steps, making it difficult for Claude to reliably select this skill from a pool of alternatives.
Suggestions
Add a 'Use when...' clause with natural trigger terms such as 'deprecate package', 'remove module', 'sunset distribution', 'delete old package', or 'clean up unused release artifacts'.
Replace abstract phrases like 'distribution surface' and 'surviving release path' with concrete, plain-language terms (e.g., 'npm package', 'PyPI distribution', 'release pipeline') and list specific actions (e.g., 'update dependency references, remove build targets, update CI config').
Specify the ecosystem or tooling context (e.g., Python/PyPI, npm, monorepo) to improve distinctiveness and reduce conflict risk with generic refactoring or package management skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names a domain ('removing an obsolete package/distribution surface') and a general action ('safely removing'), but does not list multiple concrete actions or steps involved in the process. | 2 / 3 |
Completeness | It partially addresses 'what' (removing an obsolete package) but has no explicit 'when' clause or trigger guidance. The absence of a 'Use when...' clause caps this at 2 per the rubric, and the 'what' itself is vague enough to warrant a 1. | 1 / 3 |
Trigger Term Quality | The description uses abstract/technical phrases like 'distribution surface' and 'surviving release path' that users are unlikely to naturally say. It lacks common trigger terms like 'deprecate package', 'remove module', 'delete distribution', or specific tooling references. | 1 / 3 |
Distinctiveness Conflict Risk | The concept of removing an obsolete package/distribution is somewhat specific, but the vague phrasing ('distribution surface', 'release path') could overlap with general deprecation, refactoring, or package management skills. | 2 / 3 |
Total | 6 / 12 Passed |
Implementation
42%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 high-level checklist for removing obsolete package surfaces, with good structural organization. However, it lacks concrete, executable guidance—no actual commands, scripts, or code examples that Claude could directly use. The workflow sequence is present but missing validation checkpoints critical for destructive operations like removing package directories and CI steps.
Suggestions
Add concrete, executable commands or code snippets for key steps (e.g., `rm -rf packages/legacy-*`, `grep -r 'legacy-package' .github/` for finding stale references) to improve actionability.
Add explicit validation checkpoints between destructive steps, such as 'Run CI pipeline after removal to verify the surviving path still works' or 'git diff --stat to confirm only intended files were removed'.
Include a concrete verification step at the end, e.g., 'Run the full release workflow in dry-run mode to confirm the surviving distribution path is unbroken.'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'Why' section explains rationale that Claude could infer, and some bullet points are somewhat verbose. However, the pattern steps themselves are reasonably lean. The context section adds minor padding. | 2 / 3 |
Actionability | The guidance is entirely abstract and descriptive—no concrete commands, code snippets, or executable steps. Phrases like 'Prove the old surface is no longer the supported path' and 'Remove the legacy source artifacts' are vague directions without specific tooling or commands. The example section names specific files but provides no actual commands to execute. | 1 / 3 |
Workflow Clarity | The 7-step pattern provides a clear sequence, and step 6 mentions re-validation of the replacement path. However, there are no explicit validation checkpoints between steps, no feedback loops for error recovery, and no verification that removals haven't broken the surviving path before proceeding to the next step. For a destructive operation (removing package surfaces), this caps at 2. | 2 / 3 |
Progressive Disclosure | For a simple, single-purpose skill under 50 lines, the content is well-organized into clear sections (Context, Pattern, Why, Example) with no unnecessary nesting or references. The structure is easy to scan and navigate. | 3 / 3 |
Total | 8 / 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.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- sbroenne/mcp-server-excel
- Commit
468809e
- 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.