/seo-schema validates JSON-LD well. It won't extend it.

Site already emits five schema types across three layouts. Ran /seo-schema anyway, against the live HTML — web_fetch strips <script> tags so JSON-LD validation has to go through curl. Three blocks validated clean, two real coverage gaps surfaced, and the most useful part of the skill turned out to be the deprecation list it carries — not the templates.

What I ran

Invoked via the Skill tool, slug seo-schema. The skill is from AgriciDaniel’s claude-seo repo (MIT). About 140 lines of methodology loaded — detection across JSON-LD / Microdata / RDFa, validation against Google’s currently-supported rich result types, deprecation-status tracking, and templates for the active types.

Validation target: three live page types, fetched with curl (not web_fetch, which strips <script> tags and would silently miss every JSON-LD block).

• Home — Organization (with @id, logo, image, email) + WebSite (with @id, inLanguage: en, publisher → @id reference, potentialAction: SearchAction pointing at /skills/?q={search_term_string}).
• Blog post — Article (headline, description, datePublished, author Organization, publisher Organization with logo ImageObject 512×512, mainEntityOfPage WebPage with @id, image, keywords array) + BreadcrumbList (Cookbook → post title).
• Skill page — TechArticle (same author/publisher/mainEntityOfPage shape, plus nested about: SoftwareApplication with applicationCategory, operatingSystem "Claude Code", license MIT, url to upstream source folder, author Person) + BreadcrumbList.

What happened

All three blocks parsed. All required properties present. Every @type value sits in the ACTIVE list per the skill’s Feb 2026 status section. Dates ISO 8601. All URLs absolute. No deprecated types in use — this site never adopted HowTo, FAQ, ClaimReview, SpecialAnnouncement, or Dataset, so there’s nothing to retire.

The Feb 2026 status section is the load-bearing content. Concrete retirements named with dates:

• HowTo rich results: removed September 2023
• SpecialAnnouncement: deprecated July 2025
• VehicleListing: retired June 2025
• ClaimReview: retired June 2025
• Dataset rich results: retired late 2025
• FAQ: restricted to government and healthcare since August 2023; commercial sites no longer earn rich results (some AI/LLM citation benefit remains)

Plus a December 2025 callout that’s load-bearing too: structured data injected via JavaScript may face delayed processing — Product markup in particular should ship in initial server-rendered HTML. On an Astro static site that’s satisfied by default; on a Next.js or React-first site, that one note is the difference between schema that works and schema that silently doesn’t.

Two real coverage gaps surfaced, both layout edits rather than template additions:

• /skills/ (the wiki index) has CollectionPage in the layout but no ItemList of member skills.
• /skills/topic/<t>/ (28 topic pages) emit no JSON-LD beyond what Base.astro provides.

Neither has a one-shot recipe in the skill.

Where it drifted

Two specific frictions.

The templates section is sized for sites starting from zero. Most of the active-type templates the skill carries (Organization, LocalBusiness, Article, Product) are exactly what a freshly-built marketing site needs. On a site that already emits Organization, WebSite, Article, TechArticle, and BreadcrumbList, the templates don’t add anything. The remaining work — adding ItemList to the skills index, adding CollectionPage to topic pages — requires reading src/utils/topics.ts to know which skills belong to each topic, then emitting per-topic schema in the topic-page Astro file. The skill is shaped for “validate what’s there + recommend what’s missing.” It isn’t shaped for “extend an existing schema-emitting layout.”

The skill doesn’t teach the @id cross-reference pattern. This site’s home page uses @id: ".../#organization" so the WebSite block can declare publisher: { @id: ".../#organization" } and inherit the org definition rather than redefining it. That’s the idiomatic Schema.org pattern for sites with cross-referenced entities, and it’s what makes a multi-block JSON-LD graph walkable. The skill doesn’t reference it. On a site that uses @id cross-references already, the skill validates the result without telling you whether your graph is well-formed in the Schema.org-graph sense. On a single-entity site that doesn’t matter. On a site with five interlinked types it does.

What I’d change

Two concrete moves.

Use curl for any JSON-LD validation, not web_fetch. web_fetch returns rendered text and strips <script> blocks. JSON-LD lives in <script type="application/ld+json">. Validating with web_fetch returns “no schema detected” on every page that has schema. The skill flags this once. It’s worth flagging twice — the cost of getting it wrong is silently passing every page.

Run /seo-schema once at site launch, then on a calendar. The validation pass is fast and catches real things (missing required properties, deprecated types, malformed dates). The deprecation list is what makes it worth re-running periodically — re-check every 6 months for new retirements, since the list moves more often than other parts of SEO. But for routine schema work on a site that already emits a graph, the templates won’t help and the extension work happens in your layout files. The skill is a quarterly hygiene check, not an ongoing tool. Pair it with /seo-audit for the same launch-plus-quarterly cadence — covered in three SEO skills on pre-launch Astro.