schema-markup-generator 是一个面向 SEO 结构化数据的技能，用于读取网页并生成与页面实际内容匹配的有效 JSON-LD schema 标记。它的定位是充当专注于结构化数据的 SEO 工程师。
用途 该技能在用户要求为网页生成 JSON-LD 或结构化数据标记时启用。它会检测页面适用的 schema 类型，例如 FAQPage、Article、Organization、Product 等，并据此生成标记。
核心原则 技能强调不得虚构数据。JSON-LD 中的每个字段都必须来自页面上真实存在的内容。如果某个必填字段未出现在页面上，应当将其标记为缺失，而不是用占位符或猜测数据填充。
输入方式 在接受任务前会先确认目标输入。支持的输入包括：使用 Chrome 爬取的在线 URL、本地 HTML 文件路径，或粘贴的 HTML 内容。如果未提供输入，技能会询问用户要为其生成 schema 标记的页面（URL、文件路径或 HTML）。
工作流程 技能定义了一套分步骤的工作流程。
第一步是环境检查：对于在线 URL，确认 Chrome 已启用远程调试，若 Chrome DevTools MCP 可用则继续，否则尝试用 curl 作为备选；对于本地文件或粘贴的 HTML，无需 Chrome，直接读取内容。如果用户希望在最后提交 PR，则检查 GITHUB_TOKEN。仅输出模式无需该令牌。
第二步是爬取页面并提取内容：可通过 Chrome DevTools MCP 导航并等待页面完全加载（包括 JavaScript 渲染内容），提取页面全文与可见 HTML 结构，捕获页面标题、meta 描述、标题（h1-h6）、正文文本、图片 URL 与 alt 文本、链接、可见价格、日期、作者名、公司名、地址、电话、FAQ 分区、编号步骤、评价与评分等；也可用 curl（带浏览器 User-Agent）抓取并解析同样的内容；本地文件或粘贴 HTML 则直接读取并解析相同字段。
第三步是检测所需 schema 类型：分析提取到的内容，识别页面需要的 schema 类型。一个页面通常需要多个类型。检测规则包括：FAQ 页面或 FAQ 分区（3 对及以上问答）对应 FAQPage；博客文章或文章（标题、作者、发布日期、正文）对应 Article 或 BlogPosting；公司或关于页面（公司名、描述、logo 或社交链接）对应 Organization；产品页面（产品名、价格、库存）对应 Product；首页（站点名、搜索功能）对应 WebSite；操作指南或教程（带描述的编号步骤）对应 HowTo；含面包屑导航的页面（可见面包屑路径）对应 BreadcrumbList；软件工具或应用（应用名、操作系统、价格、下载链接）对应 SoftwareApplication；本地商家（实体地址、电话、营业时间）对应 LocalBusiness。若页面符合多个类型，则应用多个类型。
第四步是读取规范与模板：阅读 references/json-ld-spec.md 获取各检测到的 schema 类型的必填与推荐字段；阅读 references/output-template.md 获取每种类型的确切 JSON 结构。对每个将生成的 schema 类型，记录页面内容中存在的必填字段、缺失的必填字段（标记而不虚构）、以及值得包含的推荐字段。
第五步是生成 JSON-LD：每个 schema 类型生成一个 script 标签块。规则包括：每个值都来自第二步提取的页面内容；使用模板作为结构；对缺失的必填字段，在 JSON 内添加注释标记（如 MISSING_fieldName: not found on page）以提示用户补充；对缺失的推荐字段则静默省略；所有日期和时长使用 ISO 8601；所有图片、页面和站点引用使用完整绝对 URL；正确嵌套对象（作者为 Person 对象，发布者为 Organization 对象等）；若适用多个 schema 类型，则每个类型输出为单独的 script 块；不得输出通用占位值，要么使用真实值，要么标记为 MISSING。
第六步是校验输出：在呈现输出前，对每个 JSON-LD 块运行检查清单，包括 JSON 语法有效、@context 为 https://schema.org、@type 匹配目标 schema 类型、必填字段均已填充或标记为 MISSING、所有 URL 为绝对地址、所有日期使用 ISO 8601、无虚构数据、无占位字符串残留。需在呈现前修复语法错误，并说明哪些必填字段已找到、哪些被标记为 MISSING。
第七步是输出与部署：清晰呈现输出。对每个 schema 块，说明 schema 类型及其所属页面；在代码块中展示完整的 script 标签块；说明在 HTML 中的放置位置（head 内、/head 之前）；列出用户需手动填写的 MISSING 字段。随后询问用户是希望开启 GitHub PR 注入代码库，还是手动添加。若用户确认 PR，则检查环境中的 GITHUB_TOKEN 与 GITHUB_REPO，检测框架以确定正确的注入点，在合适位置插入 script 块，并通过 GitHub CLI 或 API 开启 PR。框架特定注入点：Next.js（App Router）在页面组件内添加 Script，或在 pages router 使用 next/head；Astro 在页面布局或 front matter 的 head 内添加；HTML 在 head 内 /head 之前添加；Jekyll 添加到 _includes/head.html 或通过自定义 head include 添加到 front matter；Nuxt 通过 useHead() 组合式函数或 Head 组件添加。
输出质量要点 好的输出表现为：每个 JSON-LD 值都可直接追溯到可见页面内容；必填字段已填充或被明确标记为 MISSING；JSON 语法有效可被任意 JSON 校验器解析；URL 为绝对且正确；日期为 ISO 8601；放置说明匹配用户实际框架；用户清楚下一步该做什么。差的输出表现为：虚构页面上不存在的值；残留占位字符串；使用相对 URL；缺少 @context 或 @type；JSON 无效；schema 类型与页面内容不符；静默省略必填字段而未标记。
限制与未提供信息 关于该技能的具体收费、价格、平台支持范围、效果数据或使用步骤以外的细节，资料中暂未提供。