Validate application performance against defined budgets to identify regressions early. Use when checking page load times, bundle sizes, or API response times against thresholds. Trigger with phrases like "validate performance budget", "check performance metrics", or "detect performance regression".
57
50%
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 ./plugins/performance/performance-budget-validator/skills/validating-performance-budgets/SKILL.mdQuality
Discovery
100%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-crafted skill description that clearly communicates its purpose, provides specific concrete actions, and includes explicit trigger phrases. It covers the what, when, and how-to-trigger dimensions comprehensively while maintaining a distinct niche around performance budget validation.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: validate application performance against budgets, check page load times, bundle sizes, API response times against thresholds, and detect performance regressions. | 3 / 3 |
Completeness | Clearly answers both 'what' (validate application performance against defined budgets to identify regressions) and 'when' (checking page load times, bundle sizes, API response times; explicit trigger phrases provided). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'validate performance budget', 'check performance metrics', 'detect performance regression', 'page load times', 'bundle sizes', 'API response times'. These cover common variations of how users would phrase performance-related requests. | 3 / 3 |
Distinctiveness Conflict Risk | Occupies a clear niche around performance budget validation with distinct triggers like 'performance budget', 'performance regression', and specific metrics (bundle sizes, page load times). Unlikely to conflict with general testing or monitoring skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
0%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is almost entirely descriptive rather than instructive—it explains what performance budget validation is and when to use it, but never shows Claude how to actually do it. There are no executable code examples, no configuration file schemas, no concrete tool commands, and no real workflow with validation checkpoints. The content is heavily padded with sections that explain concepts Claude already understands, wasting significant token budget.
Suggestions
Replace the abstract 'Examples' section with concrete, executable code: show a sample performance-budgets.json schema, actual Lighthouse CLI commands (e.g., `lighthouse --budget-path=budgets.json`), and a script for bundle size checking.
Remove the 'Overview', 'How It Works', 'When to Use This Skill', 'Best Practices', 'Integration', and 'Resources' sections entirely—they explain concepts Claude already knows and provide no actionable guidance.
Add explicit validation checkpoints to the workflow, e.g., 'After collecting metrics, verify the JSON output is valid before comparison; if any metric collection fails, report which metrics are missing and retry.'
Provide a concrete sample performance-budgets.json file and show the exact expected output format for the validation report, so Claude knows the input/output contract.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose with extensive sections explaining concepts Claude already knows (what performance budgets are, when to use them, best practices). The 'Overview', 'How It Works', 'When to Use This Skill', 'Best Practices', and 'Integration' sections are all filler that add no actionable value. The content could be reduced by 70%+ without losing useful information. | 1 / 3 |
Actionability | No concrete code, commands, or executable examples anywhere. The 'Examples' section describes what the skill 'will do' in abstract terms rather than showing actual commands, scripts, or configuration formats. There's no sample performance-budgets.json schema, no Lighthouse commands, no bundle analysis code—nothing copy-paste ready. | 1 / 3 |
Workflow Clarity | The 'Instructions' section lists 6 vague steps like 'Load performance budget configuration' and 'Collect current performance metrics' without specifying how to do any of them. No validation checkpoints, no feedback loops for handling violations, and no concrete sequencing of tool usage. The error handling section is a generic checklist with no actionable recovery steps. | 1 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files despite mentioning a performance-budgets.json config file. No bundle files are provided to support the content. Multiple sections (Best Practices, Integration, Resources) contain generic advice that could be removed entirely. The 'Resources' section lists topics with no actual links or file references. | 1 / 3 |
Total | 4 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
3a2d27d
Table of Contents
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.