CtrlK
BlogDocsLog inGet started
Tessl Logo

third-party-scripts

Use when auditing slow page loads, heavy assets, or rendering delays related to Optimize third-party script loading. Verify the actual bottleneck in DevTools, Lighthouse, or field data before recommending changes.

56

Quality

63%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/third-party-scripts/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%Weight 40%Scale 1-5

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

A lean, well-organized body with a strong progressive-disclosure structure pointing to a real, useful reference file. The weaknesses are redundancy between the Fix section and Quick Reference, absent inline code, and a workflow that lacks an explicit validation loop after fixes are applied.

Suggestions

Merge the "## Fix" section into the Quick Reference (or make it the one place with the actual fix recipe) to remove the near-duplicate guidance.

Inline one small executable example (e.g. the good/bad <script async/defer> head snippet) so the most common fix is copy-paste ready without opening the reference.

Add a post-fix verification step such as "Re-run Lighthouse or the Network panel to confirm scripts no longer block parsing" to close the workflow's validation gap, and give the "## Check" step a concrete measurement method.

DimensionReasoningScore

Conciseness

The Quick Reference assumes competence and is lean, but the "## Fix" section ("Add async or defer attributes to third-party scripts and consider lazy loading non-critical scripts") nearly duplicates the Quick Reference bullets, and "## Explain" is a content-free directive. Mostly efficient with genuine trimming opportunities, which is more than the minor trimming of anchor 4.

3 / 5

Actionability

Concrete directives exist ("Use async for independent scripts (analytics, ads)", "Consider self-hosting critical third-party scripts") but the body contains no executable code or commands, and the "## Check" step ("Analyze third-party scripts on this page") names no measurement method — the executable examples live only in references/rule.md. This matches the incomplete-guidance anchor rather than the mostly-executable one.

3 / 5

Workflow Clarity

The Check → Fix → Explain → Code Review sections imply a sensible order, but the sequence is not explicit and there is no post-fix validation checkpoint (e.g. re-measure after changes). Steps are present but checkpoints are implicit, matching anchor 3; not a destructive/batch skill so no hard cap applies.

3 / 5

Progressive Disclosure

The body is short and well-sectioned, and defers cleanly with a clearly signaled one-level-deep reference — "For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`" — which exists and contains exactly that material. Per the simple-skill guidance, this fits the clear-overview anchor.

5 / 5

Total

14

/

20

Passed

Description

70%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, third-person description with an explicit "Use when…" trigger and concrete diagnostic actions including named tools (DevTools, Lighthouse, field data). Its main weakness is that the "what" only covers measurement/verification — the actual optimization strategies from the body (async/defer, lazy-loading, self-hosting) are not surfaced.

Suggestions

Add the skill's core capabilities to the description, e.g. "Add async/defer attributes, lazy-load non-critical scripts, or self-host critical third-party scripts" so the "what" is concrete rather than implied by the rule name.

Include common user phrasings such as "page speed" or "scripts blocking rendering" to broaden natural trigger coverage.

Keep the existing verification clause ("Verify the actual bottleneck… before recommending changes") as it usefully distinguishes this from generic performance-tuning skills.

DimensionReasoningScore

Specificity

The description names two concrete diagnostic actions — "auditing slow page loads, heavy assets, or rendering delays" and "Verify the actual bottleneck in DevTools, Lighthouse, or field data" — but omits the skill's fix-side capabilities (async/defer, lazy-loading, self-hosting) that the body actually covers, matching the 1-2-concrete-actions anchor. It is not a 4 because coverage of what the skill does is incomplete.

3 / 5

Completeness

It has an explicit "Use when auditing slow page loads, heavy assets, or rendering delays" trigger, but the "what" is only implied via the domain name "Optimize third-party script loading" plus one verification action rather than a clear capability statement. This matches the anchor where both are present but one could be more explicit.

4 / 5

Trigger Term Quality

Natural phrases users would say are present — "slow page loads", "heavy assets", "rendering delays", "third-party script" — giving good keyword coverage. It falls short of 5 because common synonyms like "page speed", "script blocking", or "Third-Party Web/RUM data" phrasing are missing.

4 / 5

Distinctiveness Conflict Risk

It carves out a clear niche (third-party script loading performance) with distinct triggers like DevTools/Lighthouse/field-data verification, so it is mostly distinct. Minor overlap risk remains with general page-performance skills that could also trigger on "slow page loads" or "heavy assets".

4 / 5

Total

15

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository
thedaviddias/Front-End-Checklist
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.