CtrlK
BlogDocsLog inGet started
Tessl Logo

moai-ref-seo

Search-visibility and crawlability reference for web output: canonical URL discipline, per-page title and meta description uniqueness, robots.txt and sitemap.xml as host-derived artifacts, JSON-LD structured data with entity consistency, and the document-semantics rules that decide whether a machine can read a page at all. Agent-extending skill that amplifies web-output implementation and pre-ship review with production-grade indexing and structured-data patterns. NOT for: keyboard operability, visible focus indicators, and form-control labeling (accessibility owns those; delegated to the accessibility surface); generative-engine optimization, deliberately excluded as insufficiently settled; visual polish and interface detail (see moai-ref-ui-polish); API contract design (see moai-ref-api-patterns); security headers and hardening (see moai-ref-owasp-checklist and moai-ref-secops).

61

Quality

73%

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 ./.claude/skills/moai-ref-seo/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

71%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 disciplined, dense reference that stays at the decision-rule layer, avoids teaching known concepts, and backstops itself with a concrete evidence-based verification checklist. The two real weaknesses are the absence of any executable examples of the artifacts it governs (JSON-LD blocks, robots.txt, meta tags) and a single-file monolith that contradicts its own declared progressive-disclosure levels.

Suggestions

Split the 'Common Rationalizations', 'Red Flags', and 'Verification' sections into reference files (e.g., references/rationalizations.md, references/verification.md) so the declared progressive_disclosure levels (level2_tokens: 3000) actually exist as files.

Add one minimal copy-paste-ready artifact of each governed output — a sample JSON-LD block, a host-derived robots.txt, and a title/meta-description pair — to lift actionability to fully executable guidance.

Add brief error-recovery guidance to the Verification checklist (what to do when a check fails, e.g., how to reconcile a canonical declaration that redirects) to give the workflow explicit feedback loops.

DimensionReasoningScore

Conciseness

The body is dense, assumes Claude's competence (never explains what JSON-LD or robots.txt are), and delivers guidance almost entirely through tight rule tables — 'Normalize before serving. A parameter that does not change the response must not mint a second address'. Minor rhetorical flourishes ('Figures that engines publish and then quietly revise — truncation widths, ranking weights, crawl allowances — are deliberately absent') could be trimmed, so it fits anchor 4 ('efficient; minor instances that could be trimmed') rather than anchor 5, and is clearly above anchor 3 since there is no unnecessary explanation of known concepts.

4 / 5

Actionability

For an instruction-only reference, guidance is concrete and checkable: 'Count h1 elements in the rendered output of each page', 'scan the emitted output for the scaffold's own default strings and fail when one survives', 'give each a stable identifier, and cross-reference by identifier'. It stops short of anchor 5 because there are no copy-paste-ready artifacts — no example JSON-LD block, robots.txt, or meta tag — leaving the emitted form of the output to be inferred.

4 / 5

Workflow Clarity

There is no numbered procedure, but the material is a reference, not a multi-step process; it is organized into a coherent progression (semantics → identity → metadata → structured data → crawl artifacts → delivery) and closes with an explicit Verification checklist demanding observed evidence ('report the counts observed, not the intent', 'quote the address set observed'). That matches anchor 4's 'clear sequence with most checkpoints present'; it falls short of anchor 5 because there are no error-recovery/feedback loops for failed checks.

4 / 5

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are absent) and all ~170 lines of content — including the rationalizations, red-flags, and verification sections — are inline in a single SKILL.md, despite frontmatter declaring 'progressive_disclosure: enabled: true' with a level2_tokens budget. That matches anchor 3 ('some structure... content that should be separate is inline'): section structure is good, but nothing is split out and the declared progressive-disclosure levels have no corresponding files. It is above anchor 2 because the inline content is well-organized rather than a wall of text, and below anchor 4 because no content is actually placed in separate files.

3 / 5

Total

15

/

20

Passed

Description

75%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 highly specific, well-bounded description with excellent explicit disambiguation against neighboring skills. Its main gap is that the explicit 'when to use' triggers are placed in a separate when_to_use frontmatter field rather than in the description text itself, which caps completeness and leaves the single most common user term ('SEO') unstated.

Suggestions

Fold a compact 'Use when...' clause into the description text itself (e.g., 'Use when a project emits pages a search engine will fetch or when the user mentions SEO, canonical URLs, robots.txt, sitemap.xml, or JSON-LD') rather than relying solely on the separate when_to_use field.

Include the term 'SEO' (and 'search engine optimization') explicitly — it is the phrase users most naturally say, and currently only 'search-visibility' appears.

Consider naming 'heading structure' and 'image alt text' in the when-to-use triggers, since users auditing those often reach for this skill via accessibility vocabulary.

DimensionReasoningScore

Specificity

The description enumerates concrete, distinct capabilities — 'canonical URL discipline, per-page title and meta description uniqueness, robots.txt and sitemap.xml as host-derived artifacts, JSON-LD structured data with entity consistency, and the document-semantics rules' — which is comprehensive and specific coverage of the domain. It matches the anchor 'lists multiple specific concrete actions; comprehensive coverage' and is above anchor 4 because there are no notable coverage gaps; it cannot be vaguer since no phrase is generic like 'helps with documents'.

5 / 5

Completeness

The 'what' is clearly and concretely stated, but the description field itself contains no 'Use when...' clause or equivalent explicit trigger guidance — that guidance lives in a separate frontmatter field (when_to_use) rather than in the description. Per the rubric guideline, a missing 'Use when' clause caps completeness at 3, which this description matches ('has a clear what but when is missing'); it is above anchor 2 because the what is specific and the NOT-for list partially implies scope.

3 / 5

Trigger Term Quality

Natural terms a user would say are present — 'canonical URL', 'meta description', 'robots.txt', 'sitemap.xml', 'JSON-LD', 'structured data', 'crawlability' — giving good keyword coverage. A few common natural terms are missing, most notably 'SEO' itself (only the less colloquial 'search-visibility' appears), so it fits anchor 4 rather than anchor 5's comprehensive synonym/extension coverage.

4 / 5

Distinctiveness Conflict Risk

The description carves out a clear niche (machine-readable web output: indexing, structured data, crawl artifacts) and explicitly disambiguates adjacent skills by name — 'NOT for: keyboard operability, visible focus indicators, and form-control labeling (accessibility owns those...)', 'see moai-ref-ui-polish', 'see moai-ref-api-patterns', 'see moai-ref-owasp-checklist and moai-ref-secops'. This is minimal conflict risk, matching anchor 5 and exceeding anchor 4's 'minor overlap risk' since boundaries are explicit rather than implied.

5 / 5

Total

17

/

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

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
modu-ai/moai-adk
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.