dependabot-tooling-downgrade
Use a validated tooling downgrade when Dependabot flags an unpatchable transitive vulnerability in build-only dependencies.
62
73%
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/dependabot-tooling-downgrade/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 description is concise and well-targeted for a very specific scenario. It excels at distinctiveness and trigger term quality by using precise developer terminology that maps directly to the use case. Its main weakness is that it describes only a single action rather than listing the concrete steps or sub-actions involved in the tooling downgrade process.
Suggestions
Add more specific concrete actions involved in the process, e.g., 'pin dependency version, update lockfile, verify build integrity' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Dependabot, transitive vulnerabilities, build-only dependencies) and a single action ('tooling downgrade'), but doesn't list multiple concrete actions or steps involved in the process. | 2 / 3 |
Completeness | Clearly answers both 'what' (use a validated tooling downgrade) and 'when' (when Dependabot flags an unpatchable transitive vulnerability in build-only dependencies). The entire description functions as an explicit trigger condition. | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would actually use: 'Dependabot', 'unpatchable', 'transitive vulnerability', 'build-only dependencies', 'tooling downgrade'. These are specific terms a developer would mention when facing this exact scenario. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a very narrow niche: the intersection of Dependabot alerts, unpatchable transitive vulnerabilities, and build-only dependencies. Extremely unlikely to conflict with other skills. | 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 is a focused, domain-specific skill that addresses a real and recurring problem. Its strengths are clear scoping (dev-only transitive vulnerabilities) and concrete real-world examples. Its weaknesses are the lack of a truly executable, step-by-step workflow with validation checkpoints and the redundancy between the two examples which describe essentially the same scenario.
Suggestions
Restructure the Patterns section into a numbered step-by-step workflow with explicit validation checkpoints and a feedback loop (e.g., 'If npm audit still reports the vulnerability after downgrade, check whether the lockfile was fully regenerated').
Add a copy-paste-ready command sequence showing the exact steps: e.g., `npm install @vscode/vsce@^2.25.0 --save-dev`, `rm -rf node_modules package-lock.json`, `npm install`, `npm audit`, `npm run package`.
Consolidate the two examples into one, or make the second example illustrate a genuinely different scenario to avoid redundancy.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly efficient but has some redundancy. The two examples overlap significantly (both describe the same vsce downgrade scenario), and some pattern descriptions could be tighter. The anti-patterns section adds value but partially restates what the patterns already imply. | 2 / 3 |
Actionability | Provides concrete package names, version ranges, and validation commands (npm audit, npm run package), but lacks executable code snippets or copy-paste-ready command sequences. The guidance is specific enough to follow but stops short of fully actionable steps like exact npm install commands or package.json diffs. | 2 / 3 |
Workflow Clarity | The patterns section lists steps in a logical order (confirm chain → check replacement → make change → validate release command → keep it surgical), but they read more like principles than a sequenced workflow. There's no explicit validation checkpoint or feedback loop (e.g., 'if npm audit still fails, try X'). | 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, Patterns, Examples, Anti-Patterns) that are easy to scan and navigate. | 3 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- 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.