retire-legacy-distribution-surface
Pattern for safely removing an obsolete package/distribution surface without breaking the surviving release path.
40
37%
Does it follow best practices?
Impact
—
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 concrete actions involved. It lacks a 'Use when...' clause and natural trigger terms, 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 obsolete package'.
Replace abstract language like 'distribution surface' and 'surviving release path' with concrete terms (e.g., 'npm package', 'PyPI distribution', 'release branch') and list specific actions (e.g., 'update dependency references, remove build targets, clean up CI pipelines').
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
57%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a reasonably well-structured procedural skill that provides a clear mental model for safely removing obsolete package surfaces. Its main weaknesses are the lack of executable commands/code and the absence of explicit validation checkpoints between destructive steps. The 'Why' section adds modest value but could be trimmed.
Suggestions
Add explicit validation checkpoints between steps, e.g., 'After step 2, run the build/CI pipeline to confirm no references to deleted directories remain' — this is important for a workflow involving destructive changes.
Include concrete, executable commands or code snippets (e.g., `grep -r 'excel-skill' .github/` for finding stale references, or `rm -rf packages/excel-*-skill` for deletion) to make the pattern copy-paste actionable.
Trim or remove the 'Why' section — Claude can infer the rationale from the pattern itself, and the tokens would be better spent on validation steps.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'Why' section explains motivations that Claude can infer from the pattern itself, adding some unnecessary context. The 'Context' line is also somewhat redundant given the pattern is self-explanatory. However, the core pattern steps are reasonably lean. | 2 / 3 |
Actionability | The pattern provides a clear checklist of steps and a concrete example section with specific file/directory names, but lacks executable commands or code snippets. The guidance is specific enough to follow but not copy-paste ready — e.g., no actual shell commands for deletion, no grep patterns for finding stale references. | 2 / 3 |
Workflow Clarity | Steps are clearly sequenced (prove → remove artifacts → remove build logic → remove CI steps → remove hooks → re-validate → search for stale refs), and step 6 mentions re-validation. However, there are no explicit validation checkpoints or feedback loops between steps — e.g., no 'run CI to confirm nothing breaks after step 2' or 'verify the surviving path still works before proceeding.' | 2 / 3 |
Progressive Disclosure | For a simple, single-purpose skill under 50 lines with no need for external references, the content is well-organized into clear sections (Context, Pattern, Why, Example) that are easy to scan and navigate. | 3 / 3 |
Total | 9 / 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
e8764a6
- 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.