CtrlK
BlogDocsLog inGet started
Tessl Logo

anchor-text

Use when auditing metadata, crawlability, structured data, or indexability related to Use descriptive anchor text. Verify the rendered HTML and HTTP response rather than relying only on source files.

56

Quality

64%

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/anchor-text/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

63%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.

The body is a compact, well-structured audit skill with an appropriate pointer to a real one-level-deep reference file, so progressive disclosure is exemplary. Its weaknesses are redundant explanation of a concept Claude already knows and Check/Fix steps that lack the concrete execution details (commands, selectors, HTML examples) needed to act without opening the reference.

Suggestions

Delete the opening sentence explaining why descriptive anchor text matters and fold the 'Explain' section into references/rule.md — Claude already knows these SEO and accessibility benefits, so both are token overhead.

Add one executable step to the Check section, e.g. `grep -rEi '<a[^>]*>\s*(click here|read more|learn more)\s*</a>' templates/` or a DOM query against the rendered page, so the audit can be run without improvising a method.

Inline the single good/bad HTML example pair from references/rule.md into the Fix section so the correct fix pattern is visible in the body while keeping the bulk of the details in the reference.

DimensionReasoningScore

Conciseness

Mostly efficient, but it includes unnecessary explanation Claude already knows: the opening sentence ("Descriptive anchor text helps search engines understand the context of the linked page and significantly improves accessibility...") explains a basic concept, and the "Explain" section duplicates that same why-it-matters content. It is not 4 because the redundancy spans two places; not 2 because the rest is lean bullets with no padding or library background.

3 / 5

Actionability

Some concrete guidance exists — the Quick Reference names the specific generic phrases to avoid ('click here', 'read more') and the Fix gives a clear replacement direction — but execution details are missing: the Check says only to 'verify that all links use descriptive anchor text' with no command, selector, or code for enumerating links, and the good/bad HTML examples live only in references/rule.md. It is not 4 because the body's core steps are not executable on their own; not 2 because the guidance includes specific examples rather than pure high-level hints.

3 / 5

Workflow Clarity

The role-based sequence (Quick Reference → Check → Fix → Explain → Code Review) is clear and coherent, and verification of the final rendered output is addressed in the Code Review section ("describe how to verify the final page output") and detailed in references/rule.md. It is not 5 because the Check step never says how to inspect rendered output versus source files and there is no explicit verify-after-fix loop; not 3 because the sections are well-sequenced and verification is explicitly called out.

4 / 5

Progressive Disclosure

The body is a short overview and details (code examples, framework guidance, verification steps) are appropriately split into a single well-signaled, one-level-deep reference ("see `references/rule.md`"), which is a real file containing exactly that content. It is not 4 because there are no organization gaps: the split is clean and navigation is trivial.

5 / 5

Total

15

/

20

Passed

Description

66%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.

The description has an explicit 'Use when' trigger and two concrete actions, giving it acceptable completeness and keyword coverage. However, a templating artifact ('related to Use descriptive anchor text') garbles the phrasing, and its generic SEO-audit trigger terms create real conflict risk against sibling skills in the same rule family.

Suggestions

Rewrite to remove the template artifact and lead with the concrete action, e.g. "Audits link anchor text for generic phrases like 'click here' or 'read more' that hurt SEO and accessibility; flags exact routes or templates where search-facing HTML violates the rule."

Add distinguishing trigger synonyms such as "link text", "internal links", and "SEO" so this skill is selected over sibling metadata/crawlability rule skills sharing the same auditing trigger terms.

State the what more concretely (check rendered HTML for generic anchor text, verify against HTTP response) instead of the broad 'auditing metadata, crawlability, structured data, or indexability' list, which promises capabilities beyond this single rule.

DimensionReasoningScore

Specificity

The description names the domain and two concrete actions — "auditing metadata, crawlability, structured data, or indexability" and "Verify the rendered HTML and HTTP response rather than relying only on source files" — but coverage is not comprehensive (nothing about fixing or rewriting anchor text). It is not 4 because only two actions are listed and the mid-sentence artifact "related to Use descriptive anchor text" muddies the capability statement; not 2 because it goes well beyond merely naming the domain.

3 / 5

Completeness

Both parts are present: the 'what' (audit metadata/crawlability/structured data/indexability for anchor text, verify rendered HTML and HTTP response) and an explicit 'when' ("Use when auditing metadata, crawlability, structured data, or indexability related to..."). It is not 5 because the 'when' clause largely restates the 'what' and the garbled rule-name insertion weakens the concrete trigger phrasing; not 3 because the 'Use when' trigger is explicit rather than implied.

4 / 5

Trigger Term Quality

Good keyword coverage: "metadata", "crawlability", "structured data", "indexability", "anchor text", "rendered HTML", and "HTTP response" are all terms a user auditing SEO would say. It is not 5 because natural synonyms like "link text", "internal links", "SEO", or "click here" are missing; not 3 because coverage clearly exceeds 'some relevant keywords'.

4 / 5

Distinctiveness Conflict Risk

Anchor text is a specific niche, but the generic auditing triggers (metadata, crawlability, structured data, indexability) would fire identically for sibling frontendchecklist SEO skills built from the same template — only the embedded rule name distinguishes it. It is not 4 because the overlap risk with closely related skills in the same family is more than minor; not 2 because it would not conflict with unrelated skills.

3 / 5

Total

14

/

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.