Back to Details

wordpress-live-validation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

WordPress Live Validation Skill

WordPress 在线验证 Skill

Operator Context

操作场景

This skill operates as an operator for post-publish browser validation, configuring Claude's behavior for read-only inspection of rendered WordPress pages. It uses the Playwright MCP server to load a real browser, extract DOM state, capture screenshots, and verify that what the reader sees matches what was uploaded. The browser is the source of truth -- REST API success does not guarantee correct rendering.
本技能作为发布后浏览器验证的操作工具，配置Claude的行为以只读方式检查渲染后的WordPress页面。它使用Playwright MCP服务器加载真实浏览器，提取DOM状态，捕获截图，并验证读者看到的内容与上传的内容一致。浏览器是唯一可信源——REST API调用成功并不保证渲染正确。

Hardcoded Behaviors (Always Apply)

硬编码行为（始终生效）

  • CLAUDE.md Compliance: Read and follow repository CLAUDE.md before validation
  • Read-Only: Never click, type, fill forms, or modify anything on the WordPress site. This is observation-only validation. Why: any write action risks mutating published content or triggering unintended side effects.
  • Evidence-Based Reporting: Every check result must reference a concrete artifact (DOM value, network response, screenshot path). Why: "looks fine" is not a validation result -- the report consumer needs verifiable evidence.
  • Non-Blocking by Default: Failed validation produces a report but does not revert the upload or block the pipeline. Why: the user decides how to act on findings; automated rollback is a separate, riskier concern.
  • Severity Accuracy: BLOCKER means readers see broken content. WARNING means degraded quality. INFO means informational. Never inflate or deflate severity. Why: inflated severity causes alert fatigue; deflated severity hides real problems.
  • CLAUDE.md 合规性：验证前请阅读并遵循仓库中的CLAUDE.md
  • 只读模式：绝不点击、输入、填写表单或修改WordPress站点的任何内容。仅进行观察式验证。原因：任何写入操作都可能修改已发布内容或触发意外副作用。
  • 基于证据的报告：每个检查结果必须引用具体的工件（DOM值、网络响应、截图路径）。原因：「看起来正常」不是有效的验证结果——报告使用者需要可核实的证据。
  • 默认非阻塞：验证失败会生成报告，但不会回滚上传或阻塞流程。原因：由用户决定如何处理发现的问题；自动回滚是独立的高风险操作。
  • 准确的严重程度分级：BLOCKER表示读者会看到损坏的内容。WARNING表示质量下降。INFO表示仅为信息性内容。绝不夸大或降低严重程度。原因：夸大严重程度会导致警报疲劳；降低严重程度会掩盖真实问题。

Browser Backend Selection

浏览器后端选择

This skill supports two browser backends:
BackendWhen to UseHow
Playwright MCP (default)Automated validation, repeatable checks, CI/CDHeadless browser, deterministic
Chrome DevTools MCP (alternative)Live debugging, user watching the browser, performance profilingUser's real Chrome browser
Selection logic: Use Chrome DevTools MCP when:
  1. The user explicitly asks to "check in my browser" or "debug live"
  2. The task involves Lighthouse audits or performance profiling
  3. The user has Chrome DevTools MCP connected AND is actively debugging
Otherwise, default to Playwright MCP for deterministic, repeatable validation.
本技能支持两种浏览器后端：
后端工具使用场景实现方式
Playwright MCP（默认）自动化验证、可重复检查、CI/CD流程无头浏览器，结果可预测
Chrome DevTools MCP（备选）实时调试、用户观察浏览器、性能分析用户的真实Chrome浏览器
选择逻辑：在以下情况使用Chrome DevTools MCP：
  1. 用户明确要求「在我的浏览器中检查」或「实时调试」
  2. 任务涉及Lighthouse审计或性能分析
  3. 用户已连接Chrome DevTools MCP且正在进行主动调试
否则，默认使用Playwright MCP以获得可预测、可重复的验证结果。

Default Behaviors (ON unless disabled)

默认行为（除非禁用否则启用）

  • Full Validation: Run all check categories (content integrity, SEO/social, responsive)
  • Three Breakpoints: Test mobile (375px), tablet (768px), desktop (1440px)
  • Screenshot Capture: Save screenshots at each breakpoint as evidence artifacts
  • Console Error Filtering: Exclude known benign patterns (ad-network noise, analytics warnings) from JS error count
  • Content Selector Fallback: Try 
    article
    , 
    .entry-content
    , 
    .post-content
    , 
    main
    in order if no selector is specified
  • 完整验证：运行所有检查类别（内容完整性、SEO/社交标签、响应式布局）
  • 三个断点测试：测试移动端（375px）、平板端（768px）、桌面端（1440px）
  • 截图捕获：在每个断点保存截图作为证据工件
  • 控制台错误过滤：从JS错误计数中排除已知的良性模式（广告网络噪音、分析警告）
  • 内容选择器降级：如果未指定选择器，依次尝试
    article
    、
    .entry-content
    、
    .post-content
    、
    main

Optional Behaviors (OFF unless enabled)

可选行为（除非启用否则禁用）

  • Draft Preview Mode: Navigate to 
    ?preview=true
    URL with authentication (requires WordPress session)
  • Custom Content Selector: Override the default content area selector chain
  • Strict Mode: Treat all WARNINGs as BLOCKERs
  • OG Image Fetch Verification: Navigate to the og:image URL to confirm it returns 200 (adds an extra navigation step)
  • 草稿预览模式：导航到带身份验证的
    ?preview=true
    URL（需要WordPress会话）
  • 自定义内容选择器：覆盖默认的内容区域选择器链
  • 严格模式：将所有WARNING视为BLOCKER
  • OG图片获取验证：导航到og:image URL以确认返回200状态码（会增加额外的导航步骤）

What This Skill CAN Do

本技能可实现的功能

  • Load a published WordPress post in a headless browser and verify it renders
  • Extract and compare the rendered title against the uploaded title
  • Verify H2 heading structure survived the theme rendering pipeline
  • Detect broken images (4xx/5xx responses) via network request inspection
  • Extract OG tags (og:title, og:description, og:image, og:url, twitter:card) from rendered 
    <head>
  • Detect JavaScript console errors that may affect reader experience
  • Capture responsive screenshots at mobile, tablet, and desktop breakpoints
  • Detect horizontal overflow at each viewport width
  • Detect placeholder/draft text that should not be visible to readers
  • Produce a structured pass/fail report with evidence artifacts
  • 在无头浏览器中加载已发布的WordPress文章并验证其渲染情况
  • 提取渲染后的标题并与上传的标题进行比较
  • 验证H2标题结构在主题渲染流程中是否保持完整
  • 通过网络请求检查检测损坏的图片（4xx/5xx响应）
  • 从渲染后的
    <head>
    中提取OG标签（og:title、og:description、og:image、og:url、twitter:card）
  • 检测可能影响读者体验的JavaScript控制台错误
  • 在移动端、平板端和桌面端断点捕获响应式截图
  • 在每个视口宽度检测水平溢出
  • 检测不应向读者显示的占位符/草稿文本
  • 生成包含证据工件的结构化通过/失败报告

What This Skill CANNOT Do

本技能无法实现的功能

  • Modify WordPress content: Read-only inspection; use wordpress-uploader for edits
  • Validate source markdown: Use pre-publish-checker for pre-upload validation
  • Visual regression testing: No pixel-level comparison against golden baselines
  • Performance testing: Lighthouse audits available via Chrome DevTools MCP; no load time benchmarking or Core Web Vitals tracking
  • Cross-browser testing: Playwright runs Chromium only; Chrome DevTools MCP runs Chrome only
  • Authenticate to wp-admin: Draft preview requires the user to provide an authenticated session or use published posts
  • Work without a browser MCP: Requires either Playwright MCP or Chrome DevTools MCP. If neither is available, the skill exits with a skip report
  • 修改WordPress内容：仅支持只读检查；如需编辑请使用wordpress-uploader
  • 验证源markdown：如需上传前验证请使用pre-publish-checker
  • 视觉回归测试：不支持与黄金基线进行像素级比较
  • 性能测试：通过Chrome DevTools MCP可进行Lighthouse审计；不支持加载时间基准测试或Core Web Vitals跟踪
  • 跨浏览器测试：Playwright仅运行Chromium；Chrome DevTools MCP仅运行Chrome
  • 认证到wp-admin：草稿预览需要用户提供已认证的会话或使用已发布的文章
  • 无浏览器MCP时运行：需要Playwright MCP或Chrome DevTools MCP中的任意一个。如果两者都不可用，技能将生成跳过报告并退出

Instructions

操作说明

Input

输入

The skill requires a WordPress post URL. This comes from one of:
  1. wordpress-uploader output: The 
    post_url
    from a successful upload (primary integration path)
  2. User-provided URL: Any WordPress post URL provided directly
  3. Constructed preview URL: 
    {WORDPRESS_SITE}/?p={post_id}&preview=true
    for draft validation
Optional inputs:
  • Expected title: The title passed to 
    wordpress-upload.py
    -- used for title match comparison. If not provided, the title check reports the rendered title without comparison.
  • Expected H2 count: Number of H2 headings in the source markdown. If not provided, the H2 check reports the rendered count without comparison.
  • Content selector: CSS selector for the main content area (default: tries 
    article
    , 
    .entry-content
    , 
    .post-content
    , 
    main
    in order).
本技能需要一个WordPress文章URL，来源包括：
  1. wordpress-uploader输出：成功上传后的
    post_url
    （主要集成路径）
  2. 用户提供的URL：任何直接提供的WordPress文章URL
  3. 构造的预览URL：用于草稿验证的
    {WORDPRESS_SITE}/?p={post_id}&preview=true
可选输入：
  • 预期标题：传递给
    wordpress-upload.py
    的
    --title
    值或提取的H1，用于标题匹配比较。如果未提供，标题检查将仅报告渲染后的标题作为INFO。
  • 预期H2数量：源markdown中的H2标题数量。如果未提供，H2检查将仅报告渲染后的H2文本供人工检查。
  • 内容选择器：主内容区域的CSS选择器（默认：依次尝试
    article
    、
    .entry-content
    、
    .post-content
    、
    main
    ）

Phase 1: NAVIGATE

阶段1：导航

Goal: Load the WordPress post in a browser and confirm the content area is present.
Step 1: Check Playwright availability
Before any browser operation, verify the Playwright MCP tools are accessible by attempting a simple navigation. If the tools are unavailable, exit immediately with a skip report rather than failing cryptically in later phases.
Step 2: Navigate to the post URL
Use 
browser_navigate
to load the target URL. The URL must be a full HTTPS URL.
Step 3: Wait for content area
Use 
browser_wait_for
with the content selector. Try selectors in order until one matches:
  1. article
    (most WordPress themes)
  2. .entry-content
    (classic themes)
  3. .post-content
    (some premium themes)
  4. main
    (fallback)
If a custom selector was provided, use that instead of the default chain.
Step 4: Dismiss cookie/consent banners (if present)
Some WordPress sites show cookie consent overlays that obscure content. Use 
browser_evaluate
to check for common consent banner selectors and dismiss them:
javascript
// Common cookie banner selectors
const banners = document.querySelectorAll(
  '[class*="cookie"], [class*="consent"], [id*="cookie"], [id*="consent"], .gdpr-banner'
);
banners.forEach(b => b.remove());
This is DOM removal, not clicking -- it does not interact with the site's consent tracking, it just clears the visual overlay for screenshot accuracy.
GATE: Page loaded with HTTP 200 (or 30x redirect to 200), content selector found. If the page returns 4xx/5xx or the content selector is not found after waiting, capture a screenshot of the current state, report FAIL with the HTTP status and screenshot path, and STOP. Do not proceed to Phase 2.
目标：在浏览器中加载WordPress文章并确认内容区域存在。
步骤1：检查Playwright可用性
在进行任何浏览器操作前，通过尝试简单导航来验证Playwright MCP工具是否可访问。如果工具不可用，立即生成跳过报告退出，而非在后续阶段出现模糊的失败。
步骤2：导航到文章URL
使用
browser_navigate
加载目标URL。URL必须是完整的HTTPS地址。
步骤3：等待内容区域加载
使用
browser_wait_for
配合内容选择器。按顺序尝试选择器直到匹配：
  1. article
    （大多数WordPress主题）
  2. .entry-content
    （经典主题）
  3. .post-content
    （部分高级主题）
  4. main
    （降级方案）
如果提供了自定义选择器，则使用该选择器而非默认链。
步骤4：关闭Cookie/同意横幅（如果存在）
部分WordPress站点会显示Cookie同意覆盖层遮挡内容。使用
browser_evaluate
检查常见的同意横幅选择器并移除：
javascript
// Common cookie banner selectors
const banners = document.querySelectorAll(
  '[class*="cookie"], [class*="consent"], [id*="cookie"], [id*="consent"], .gdpr-banner'
);
banners.forEach(b => b.remove());
这是DOM级别的移除操作，而非点击——不会与站点的同意跟踪系统交互，仅为了截图准确性清除视觉覆盖层。
关卡：页面加载返回HTTP 200（或30x重定向到200），且找到内容选择器。如果页面返回4xx/5xx或等待后仍未找到内容选择器，捕获当前状态的截图，报告FAIL并附上HTTP状态码和截图路径，然后停止。不进入阶段2。

Phase 2: VALIDATE

阶段2：验证

Goal: Inspect the rendered DOM and network activity for content integrity and SEO completeness.
Run all checks and collect results. Do not stop on individual failures -- collect everything and report in Phase 4.
Check 1: Title Match (Severity: BLOCKER)
javascript
// Extract rendered title
const titleEl = document.querySelector('h1, .entry-title, .post-title');
titleEl ? titleEl.textContent.trim() : null;
If an expected title was provided, compare (case-insensitive, trimmed). Mark PASS if they match, BLOCKER if they differ or no title element is found.
If no expected title was provided, report the rendered title as INFO.
Check 2: H2 Structure (Severity: WARNING)
javascript
// Extract all H2 headings
const h2s = Array.from(document.querySelectorAll('h2')).map(h => h.textContent.trim());
JSON.stringify(h2s);
If an expected H2 count was provided, compare. Mark PASS if counts match, WARNING if they differ. Always report the rendered H2 texts for manual inspection.
Check 3: Image Loading (Severity: BLOCKER)
Use 
browser_network_requests
and filter for image requests (URLs ending in common image extensions or with image MIME types). Check each response status:
  • 2xx: loaded successfully
  • 4xx/5xx: BLOCKER -- image is broken for readers
Report total images, loaded count, and failed count with URLs of any failures.
Check 4: JavaScript Console Errors (Severity: WARNING)
Use 
browser_console_messages
and filter to 
error
level. Exclude known benign patterns:
  • Ad network errors (doubleclick, googlesyndication, adsbygoogle)
  • Analytics warnings (gtag, analytics, fbevents)
  • Consent manager noise (cookiebot, onetrust, quantcast)
  • Browser extension artifacts
Report count of genuine errors and their messages.
Check 5: OG Tags (Severity: WARNING)
javascript
// Extract OG and social meta tags
const getMeta = (sel) => {
  const el = document.querySelector(sel);
  return el ? el.getAttribute('content') : null;
};
JSON.stringify({
  'og:title': getMeta('meta[property="og:title"]'),
  'og:description': getMeta('meta[property="og:description"]'),
  'og:image': getMeta('meta[property="og:image"]'),
  'og:url': getMeta('meta[property="og:url"]'),
  'twitter:card': getMeta('meta[name="twitter:card"]')
});
Mark WARNING for any missing OG tag. Report each tag's value and character count.
Check 6: Meta Description (Severity: WARNING)
javascript
const desc = document.querySelector('meta[name="description"]');
desc ? desc.getAttribute('content') : null;
Mark PASS if present and non-empty, WARNING if missing or empty. Report value and character count.
Check 7: Placeholder/Draft Text (Severity: BLOCKER)
javascript
// Search visible text for placeholder patterns
const body = document.body.innerText;
const patterns = ['[TBD]', '[TODO]', 'PLACEHOLDER', 'Lorem ipsum', '[insert', '[FIXME]'];
const found = patterns.filter(p => body.toLowerCase().includes(p.toLowerCase()));
JSON.stringify(found);
Mark BLOCKER if any placeholder patterns are found in the visible page text. Mark PASS if none found.
GATE: All 7 checks executed. Each has a severity classification and evidence value. Proceed to Phase 3.
目标：检查渲染后的DOM和网络活动，确保内容完整性和SEO完整性。
运行所有检查并收集结果。不因单个失败而停止——收集所有结果并在阶段4中报告。
检查1：标题匹配（严重程度：BLOCKER）
javascript
// Extract rendered title
const titleEl = document.querySelector('h1, .entry-title, .post-title');
titleEl ? titleEl.textContent.trim() : null;
如果提供了预期标题，进行比较（不区分大小写，去除首尾空格）。匹配则标记为PASS，不匹配或未找到标题元素则标记为BLOCKER。
如果未提供预期标题，将渲染后的标题作为INFO报告。
检查2：H2结构（严重程度：WARNING）
javascript
// Extract all H2 headings
const h2s = Array.from(document.querySelectorAll('h2')).map(h => h.textContent.trim());
JSON.stringify(h2s);
如果提供了预期H2数量，进行比较。数量匹配则标记为PASS，不匹配则标记为WARNING。始终报告渲染后的H2文本供人工检查。
检查3：图片加载（严重程度：BLOCKER）
使用
browser_network_requests
并过滤图片请求（URL以常见图片扩展名结尾或带有图片MIME类型）。检查每个响应状态：
  • 2xx：加载成功
  • 4xx/5xx：BLOCKER——图片对读者来说已损坏
报告图片总数、加载成功数量、失败数量及任何失败图片的URL。
检查4：JavaScript控制台错误（严重程度：WARNING）
使用
browser_console_messages
并过滤为
error
级别。排除已知的良性模式：
  • 广告网络错误（doubleclick、googlesyndication、adsbygoogle）
  • 分析警告（gtag、analytics、fbevents）
  • 同意管理器噪音（cookiebot、onetrust、quantcast）
  • 浏览器扩展 artifacts
报告真实错误的数量及其消息。
检查5：OG标签（严重程度：WARNING）
javascript
// Extract OG and social meta tags
const getMeta = (sel) => {
  const el = document.querySelector(sel);
  return el ? el.getAttribute('content') : null;
};
JSON.stringify({
  'og:title': getMeta('meta[property="og:title"]'),
  'og:description': getMeta('meta[property="og:description"]'),
  'og:image': getMeta('meta[property="og:image"]'),
  'og:url': getMeta('meta[property="og:url"]'),
  'twitter:card': getMeta('meta[name="twitter:card"]')
});
任何缺失的OG标签标记为WARNING。报告每个标签的值和字符数。
检查6：元描述（严重程度：WARNING）
javascript
const desc = document.querySelector('meta[name="description"]');
desc ? desc.getAttribute('content') : null;
存在且非空则标记为PASS，缺失或为空则标记为WARNING。报告值和字符数。
检查7：占位符/草稿文本（严重程度：BLOCKER）
javascript
// Search visible text for placeholder patterns
const body = document.body.innerText;
const patterns = ['[TBD]', '[TODO]', 'PLACEHOLDER', 'Lorem ipsum', '[insert', '[FIXME]'];
const found = patterns.filter(p => body.toLowerCase().includes(p.toLowerCase()));
JSON.stringify(found);
如果在页面可见文本中找到任何占位符模式，标记为BLOCKER。未找到则标记为PASS。
关卡：完成所有7项检查。每项检查都有严重程度分类和证据值。进入阶段3。

Phase 3: RESPONSIVE CHECK

阶段3：响应式检查

Goal: Verify the post renders correctly at three standard breakpoints. Capture visual evidence.
Test each viewport in sequence:
ViewportWidthHeightRepresents
Mobile375812iPhone-class
Tablet7681024iPad-class
Desktop1440900Standard laptop
For each viewport:
Step 1: Use 
browser_resize
to set the viewport dimensions.
Step 2: Use 
browser_take_screenshot
to capture the rendered page. Save to a known path for the report.
Step 3: Check for horizontal overflow:
javascript
document.documentElement.scrollWidth > document.documentElement.clientWidth;
Mark WARNING if overflow detected -- content extends beyond the viewport, which usually means a table, image, or code block is not responsive.
Step 4: Verify content container is visible and has dimensions:
javascript
const content = document.querySelector('article, .entry-content, .post-content, main');
if (content) {
  const rect = content.getBoundingClientRect();
  JSON.stringify({ visible: rect.width > 0 && rect.height > 0, width: rect.width, height: rect.height });
} else {
  JSON.stringify({ visible: false });
}
Mark WARNING if the content container is not visible or has zero dimensions at any breakpoint.
GATE: Screenshots captured at all three viewports. Overflow status and visibility recorded for each. Proceed to Phase 4.
目标：验证文章在三个标准断点下的渲染是否正确。捕获视觉证据。
按顺序测试每个视口：
视口宽度高度代表设备
移动端375812iPhone级别
平板端7681024iPad级别
桌面端1440900标准笔记本
对于每个视口：
步骤1：使用
browser_resize
设置视口尺寸。
步骤2：使用
browser_take_screenshot
捕获渲染后的页面。保存到报告指定路径。
步骤3：检查水平溢出：
javascript
document.documentElement.scrollWidth > document.documentElement.clientWidth;
如果检测到溢出则标记为WARNING——内容超出视口范围，通常意味着表格、图片或代码块不具备响应式特性。
步骤4：验证内容容器可见且有尺寸：
javascript
const content = document.querySelector('article, .entry-content, .post-content, main');
if (content) {
  const rect = content.getBoundingClientRect();
  JSON.stringify({ visible: rect.width > 0 && rect.height > 0, width: rect.width, height: rect.height });
} else {
  JSON.stringify({ visible: false });
}
如果在任何断点下内容容器不可见或尺寸为0，标记为WARNING。
关卡：在所有三个视口捕获截图。记录每个视口的溢出状态和可见性。进入阶段4。

Phase 4: REPORT

阶段4：报告

Goal: Produce a structured pass/fail report with severity counts and evidence artifacts.
Step 1: Classify results
Count BLOCKERs, WARNINGs, and INFO items from Phase 2 and Phase 3.
Step 2: Generate report
===============================================================
 LIVE VALIDATION: {post_url}
===============================================================

 CONTENT INTEGRITY:
   [{status}] Title match: "{rendered_title}" vs "{uploaded_title}"
   [{status}] H2 structure: {rendered_count} rendered / {source_count} expected
   [{status}] Images: {loaded}/{total} loaded, {failed} failed
   [{status}] JS errors: {count} errors detected
   [{status}] Placeholder text: {found_patterns or "none"}

 SEO / SOCIAL:
   [{status}] og:title: "{value}" ({chars} chars)
   [{status}] og:description: "{value}" ({chars} chars)
   [{status}] og:image: {url}
   [{status}] og:url: {url}
   [{status}] twitter:card: {value}
   [{status}] meta description: "{value}" ({chars} chars)

 RESPONSIVE:
   [{status}] Mobile (375px): overflow: {yes/no} — screenshot: {path}
   [{status}] Tablet (768px): overflow: {yes/no} — screenshot: {path}
   [{status}] Desktop (1440px): overflow: {yes/no} — screenshot: {path}

===============================================================
 RESULT: {PASS | FAIL - N blockers, M warnings}
===============================================================

 Screenshots:
   - {mobile_screenshot_path}
   - {tablet_screenshot_path}
   - {desktop_screenshot_path}
Status markers:
  • [PASS]
    -- check passed
  • [FAIL]
    -- BLOCKER severity, readers see broken content
  • [WARN]
    -- WARNING severity, degraded but not broken
  • [INFO]
    -- informational, no action needed
  • [SKIP]
    -- check could not be performed (explain why)
Result classification:
  • PASS: Zero BLOCKERs. WARNINGs may be present but do not constitute failure.
  • FAIL: One or more BLOCKERs. List all BLOCKERs after the result line.
GATE: Report generated with accurate severity counts. Screenshots saved. Result matches the blocker tally.
目标：生成包含严重程度计数和证据工件的结构化通过/失败报告。
步骤1：分类结果
统计阶段2和阶段3中的BLOCKER、WARNING和INFO项数量。
步骤2：生成报告
===============================================================
 在线验证: {post_url}
===============================================================

 内容完整性:
   [{状态}] 标题匹配: "{渲染后的标题}" vs "{上传的标题}"
   [{状态}] H2结构: {渲染数量}个已渲染 / {预期数量}个预期
   [{状态}] 图片: {加载成功数}/{总数}已加载, {失败数}个失败
   [{状态}] JS错误: 检测到{数量}个错误
   [{状态}] 占位符文本: {找到的模式或"无"}

 SEO / 社交标签:
   [{状态}] og:title: "{值}" ({字符数}字符)
   [{状态}] og:description: "{值}" ({字符数}字符)
   [{状态}] og:image: {URL}
   [{状态}] og:url: {URL}
   [{状态}] twitter:card: {值}
   [{状态}] 元描述: "{值}" ({字符数}字符)

 响应式布局:
   [{状态}] 移动端(375px): 溢出: {是/否} — 截图: {路径}
   [{状态}] 平板端(768px): 溢出: {是/否} — 截图: {路径}
   [{状态}] 桌面端(1440px): 溢出: {是/否} — 截图: {路径}

===============================================================
 结果: {通过 | 失败 - N个blocker, M个warning}
===============================================================

 截图:
   - {移动端截图路径}
   - {平板端截图路径}
   - {桌面端截图路径}
状态标记:
  • [通过]
    -- 检查通过
  • [失败]
    -- BLOCKER严重程度，读者会看到损坏的内容
  • [警告]
    -- WARNING严重程度，质量下降但未损坏
  • [信息]
    -- 仅为信息性内容，无需操作
  • [跳过]
    -- 无法执行检查（说明原因）
结果分类:
  • 通过: 无BLOCKER。可能存在WARNING，但不构成失败。
  • 失败: 存在一个或多个BLOCKER。在结果行后列出所有BLOCKER。
关卡：生成的报告包含准确的严重程度计数。截图已保存。结果与blocker数量一致。

Integration with wordpress-uploader

与wordpress-uploader的集成

When invoked after 
wordpress-uploader
, this skill acts as an optional Phase 5: POST-PUBLISH VALIDATION. The wordpress-uploader output provides:
  • post_url
    -- the navigation target
  • post_id
    -- for constructing draft preview URLs (
    {WORDPRESS_SITE}/?p={post_id}&preview=true
    )
  • The 
    --title
    value or extracted H1 -- the expected title for comparison
The validation is non-blocking by default: a FAIL result produces a report for the user but does not revert the upload. The user decides whether to act on findings.
Example integration flow:
wordpress-uploader Phase 4 completes
  -> post_url = "https://example.com/my-post/"
  -> post_title = "My Post Title"
  -> invoke wordpress-live-validation with post_url and expected title
  -> report generated
  -> user reviews and decides next action
当在
wordpress-uploader
之后调用时，本技能作为可选的阶段5：发布后验证。wordpress-uploader的输出提供：
  • post_url
    -- 导航目标
  • post_id
    -- 用于构造草稿预览URL (
    {WORDPRESS_SITE}/?p={post_id}&preview=true
    )
  • --title
    值或提取的H1 -- 用于比较的预期标题
默认情况下验证是非阻塞的：失败结果会生成报告供用户查看，但不会回滚上传。由用户决定是否根据发现的问题采取行动。
示例集成流程:
wordpress-uploader阶段4完成
  -> post_url = "https://example.com/my-post/"
  -> post_title = "My Post Title"
  -> 使用post_url和预期标题调用wordpress-live-validation
  -> 生成报告
  -> 用户查看报告并决定下一步操作

Examples

示例

Example 1: Post-Upload Validation

示例1：上传后验证

User says: "Upload this article and check if it looks right" Actions:
  1. wordpress-uploader creates the post, returns post_url
  2. NAVIGATE: Load post_url, wait for content area
  3. VALIDATE: Run all 7 checks against rendered page
  4. RESPONSIVE: Screenshots at 375/768/1440px
  5. REPORT: Structured output with pass/fail and screenshots
用户说: "上传这篇文章并检查显示是否正常" 操作:
  1. wordpress-uploader创建文章，返回post_url
  2. 导航: 加载post_url，等待内容区域
  3. 验证: 对渲染后的页面运行所有7项检查
  4. 响应式检查: 在375/768/1440px断点捕获截图
  5. 报告: 生成包含通过/失败结果和截图的结构化输出

Example 2: Standalone Live Check

示例2：独立在线检查

User says: "Check if https://your-blog.com/posts/my-latest/ looks right" Actions:
  1. NAVIGATE: Load the URL directly
  2. VALIDATE: All checks run without expected title/H2 comparison (reports rendered values as INFO)
  3. RESPONSIVE: Screenshots at all breakpoints
  4. REPORT: Structured output
用户说: "检查https://your-blog.com/posts/my-latest/显示是否正常" 操作:
  1. 导航: 直接加载URL
  2. 验证: 运行所有检查，不进行预期标题/H2比较（将渲染值作为INFO报告）
  3. 响应式检查: 在所有断点捕获截图
  4. 报告: 生成结构化输出

Example 3: OG Tag Verification

示例3：OG标签验证

User says: "Check the OG tags on my latest post" Actions:
  1. NAVIGATE: Load the URL
  2. VALIDATE: Full check suite, but user is primarily interested in OG results
  3. RESPONSIVE: Still run for completeness
  4. REPORT: Full report, user focuses on SEO/SOCIAL section
用户说: "检查我最新文章的OG标签" 操作:
  1. 导航: 加载URL
  2. 验证: 运行完整检查套件，但用户主要关注OG结果
  3. 响应式检查: 仍会执行以保证完整性
  4. 报告: 生成完整报告，用户重点查看SEO/社交标签部分

Error Handling

错误处理

Error: Playwright MCP Not Available

错误：Playwright MCP不可用

Cause: Playwright MCP server is not running or not configured in the Claude Code session Solution:
  1. The skill detects this in Phase 1 when the first browser tool call fails
  2. Exit immediately with a skip report: "Playwright MCP not available. Skipping live validation."
  3. Do not retry or attempt workarounds -- browser validation requires Playwright
原因: Playwright MCP服务器未运行或未在Claude Code会话中配置 解决方案:
  1. 技能在阶段1检测到第一个浏览器工具调用失败
  2. 立即退出并生成跳过报告: "Playwright MCP不可用。跳过在线验证。"
  3. 不重试或尝试变通方法——浏览器验证需要Playwright

Error: Page Returns 4xx/5xx

错误：页面返回4xx/5xx

Cause: Post URL is wrong, post was deleted, or WordPress is down Solution:
  1. Capture a screenshot of whatever the browser shows
  2. Report the HTTP status code
  3. STOP at Phase 1 gate -- do not proceed to validation
  4. If this was a draft preview URL, suggest the user check that the post exists and is accessible
原因: 文章URL错误、文章已删除或WordPress服务中断 解决方案:
  1. 捕获浏览器显示的内容截图
  2. 报告HTTP状态码
  3. 在阶段1关卡停止——不进入验证阶段
  4. 如果是草稿预览URL，建议用户检查文章是否存在且可访问

Error: Content Selector Not Found

错误：未找到内容选择器

Cause: Theme uses a non-standard content container, or page loaded but content area is empty Solution:
  1. The selector chain (article -> .entry-content -> .post-content -> main) covers most themes
  2. If none match, capture a screenshot and DOM snapshot for manual inspection
  3. Report as FAIL with suggestion: "Content area not found. Try specifying a custom selector."
  4. Still attempt Phase 2 checks against the full page (some checks like OG tags work without a content selector)
原因: 主题使用非标准内容容器，或页面加载但内容区域为空 解决方案:
  1. 选择器链（article -> .entry-content -> .post-content -> main）覆盖了大多数主题
  2. 如果均不匹配，捕获截图和DOM快照供人工检查
  3. 报告为失败并建议: "未找到内容区域。尝试指定自定义选择器。"
  4. 仍会尝试对整个页面执行阶段2检查（部分检查如OG标签无需内容选择器即可工作）

Error: Network Timeout on Image Checks

错误：图片检查时网络超时

Cause: CDN slow, image URLs resolve but download slowly, or intermittent network issues Solution:
  1. browser_network_requests reports what the browser observed -- timeout images appear as failed
  2. If all images fail, this likely indicates a network issue rather than broken images
  3. Report the failure but note the pattern: "All {N} images failed -- possible network/CDN issue rather than broken content"
原因: CDN缓慢、图片URL解析但下载缓慢，或间歇性网络问题 解决方案:
  1. browser_network_requests报告浏览器观察到的结果——超时图片会显示为失败
  2. 如果所有图片都失败，这更可能是网络问题而非图片损坏
  3. 报告失败但注明模式: "所有{N}张图片均失败——可能是网络/CDN问题而非内容损坏"

Error: Cookie Banner Blocks Content

错误：Cookie横幅遮挡内容

Cause: GDPR/consent overlay covers the content area, affecting screenshots Solution:
  1. Phase 1 Step 4 attempts to remove common cookie banners via DOM manipulation
  2. If the banner persists (non-standard selector), screenshots may show the overlay
  3. The DOM-level checks (title, H2s, OG tags) still work because they query elements directly
  4. Note in the report if a consent overlay was detected but could not be dismissed
原因: GDPR/同意覆盖层遮挡内容区域，影响截图 解决方案:
  1. 阶段1步骤4尝试通过DOM操作移除常见的Cookie横幅
  2. 如果横幅仍然存在（非标准选择器），截图可能会显示覆盖层
  3. DOM级别的检查（标题、H2、OG标签）仍然有效，因为它们直接查询元素
  4. 如果检测到同意覆盖层但无法关闭，在报告中注明

Anti-Patterns

反模式

Anti-Pattern 1: Clicking Consent Banners Instead of Removing

反模式1：点击同意横幅而非移除

What it looks like: Using browser_click to accept cookie consent Why wrong: Clicking "Accept" activates cookie tracking, modifies the site's consent state for this session, and may trigger additional scripts that affect validation results. This skill is read-only. Do instead: Remove the banner DOM element with browser_evaluate. This clears the visual overlay without interacting with the consent system.
表现: 使用browser_click接受Cookie同意 错误原因: 点击「接受」会激活Cookie跟踪，修改本次会话的站点同意状态，并可能触发影响验证结果的额外脚本。本技能是只读的。 正确做法: 使用browser_evaluate移除横幅DOM元素。这会清除视觉覆盖层而不与同意系统交互。

Anti-Pattern 2: Treating All Warnings as Blockers

反模式2：将所有警告视为阻塞

What it looks like: Reporting FAIL because OG tags are missing or H2 count differs Why wrong: Missing OG tags degrade social sharing but do not break the reader experience. Severity inflation causes the user to ignore the report. Do instead: Classify accurately. BLOCKERs = readers see broken content (missing images, wrong title, placeholder text). WARNINGs = degraded quality (missing OG, JS errors, overflow).
表现: 因OG标签缺失或H2数量不匹配而报告失败 错误原因: 缺失OG标签会降低社交分享效果，但不会破坏读者体验。夸大严重程度会导致用户忽略报告。 正确做法: 准确分类。BLOCKER=读者看到损坏的内容（图片缺失、标题错误、占位符文本）。WARNING=质量下降（缺失OG、JS错误、溢出）。

Anti-Pattern 3: Skipping Responsive Checks

反模式3：跳过响应式检查

What it looks like: "Content looks fine at desktop, skipping mobile/tablet" Why wrong: Mobile is often 50%+ of traffic. A table that overflows at 375px is invisible at 1440px. Do instead: Always run all three breakpoints. The screenshots are cheap and the overflow check catches layout bugs that only manifest at narrow widths.
表现: "桌面端显示正常，跳过移动端/平板端检查" 错误原因: 移动端流量通常占50%以上。在375px下溢出的表格在1440px下是不可见的。 正确做法: 始终测试所有三个断点。截图成本低，溢出检查能捕获仅在窄宽度下出现的布局问题。

Anti-Pattern 4: Validating Draft Preview Without Authentication

反模式4：无认证验证草稿预览

What it looks like: Navigating to 
?preview=true
URL expecting it to render the draft Why wrong: WordPress draft previews require an authenticated session. Without auth cookies, the URL either redirects to login or shows a 404. Do instead: For draft validation, either authenticate first (if the user provides credentials) or wait until the post is published. Report clearly if the preview URL is inaccessible.
表现: 导航到
?preview=true
URL期望渲染草稿 错误原因: WordPress草稿预览需要已认证的会话。没有认证Cookie的话，URL会重定向到登录页面或显示404。 正确做法: 对于草稿验证，要么先认证（如果用户提供凭据），要么等待文章发布。如果预览URL无法访问，清晰地报告。

Anti-Pattern 5: Retrying Indefinitely on Playwright Failure

反模式5：Playwright失败时无限重试

What it looks like: Attempting browser operations 5+ times when the Playwright server is down Why wrong: If Playwright MCP is not available, no number of retries will fix it. This wastes time and context. Do instead: Try once in Phase 1. If it fails, emit a skip report and exit. The user needs to fix their Playwright MCP configuration, not wait for retries.
表现: Playwright服务器宕机时尝试浏览器操作5次以上 错误原因: 如果Playwright MCP不可用，重试多少次都无法解决问题。这会浪费时间和上下文。 正确做法: 在阶段1尝试一次。如果失败，生成跳过报告并退出。用户需要修复Playwright MCP配置，而非等待重试。

Anti-Rationalization

反合理化

Domain-Specific Rationalizations

领域特定的合理化借口

Rationalization AttemptWhy It's WrongRequired Action
"The upload succeeded, so the page is fine"REST API 201 says nothing about rendered HTML, theme CSS, or CDN deliveryRun the browser validation
"OG tags are a nice-to-have"Missing og:image means social shares show a generic placeholder or broken thumbnailReport as WARNING with the actual rendered values
"Mobile overflow is minor"Mobile may be the majority of the audience; overflow breaks reading experienceAlways test at 375px and flag overflow
"Console errors are just ad noise"Some console errors indicate broken rendering, blocked resources, or failed lazy-loadingFilter known benign patterns but report genuine errors
"Screenshots are enough evidence"Screenshots show what it looks like, not what the DOM contains; both are neededCapture screenshots AND extract DOM values
"One breakpoint is representative"Desktop, tablet, and mobile have fundamentally different CSS layoutsTest all three breakpoints
"Playwright is probably available"Tool availability should be verified, not assumedCheck in Phase 1 before doing any work
合理化尝试错误原因要求的操作
"上传成功了，所以页面肯定没问题"REST API 201响应无法说明渲染后的HTML、主题CSS或CDN交付情况运行浏览器验证
"OG标签是可有可无的"缺失og:image意味着社交分享会显示通用占位符或损坏的缩略图作为WARNING报告实际渲染的值
"移动端溢出是小问题"移动端可能是主要受众；溢出会破坏阅读体验始终在375px下测试并标记溢出
"控制台错误只是广告噪音"部分控制台错误表示渲染失败、资源被阻止或懒加载失败过滤已知的良性模式，但报告真实错误
"截图足够作为证据"截图显示外观，但不包含DOM内容；两者都需要捕获截图并提取DOM值
"一个断点就足够有代表性"桌面、平板和移动端有根本不同的CSS布局测试所有三个断点
"Playwright应该是可用的"工具可用性应该被验证，而非假设在阶段1检查可用性后再进行任何操作

Blocker Criteria

阻塞准则

STOP and ask the user (do NOT proceed autonomously) when:
SituationWhy StopAsk This
URL requires authenticationCannot validate without credentials"This URL requires login. Can you provide an authenticated session, or should I validate after publish?"
All images fail simultaneouslyLikely network issue, not content issue"All {N} images returned errors. This may be a CDN/network issue rather than broken content. Proceed with report or retry?"
Playwright MCP unavailableCannot perform any browser checks"Playwright MCP is not available. Live validation requires browser access. Skip validation?"
在以下情况停止并询问用户（请勿自主继续）:
情况停止原因询问内容
URL需要认证无凭据无法验证"该URL需要登录。您能提供已认证的会话，还是我应该在发布后再验证？"
所有图片同时失败可能是网络问题，而非内容问题"所有{N}张图片均返回错误。这可能是CDN/网络问题而非内容损坏。继续生成报告还是重试？"
Playwright MCP不可用无法执行任何浏览器检查"Playwright MCP不可用。在线验证需要浏览器访问。是否跳过验证？"

Never Guess On

绝不猜测

  • Whether a page is publicly accessible vs requiring authentication
  • Whether console errors are benign (use the filter list, report the rest)
  • Whether overflow at a breakpoint is "acceptable" (always report it, let the user decide)
  • 页面是公开可访问还是需要认证
  • 控制台错误是否良性（使用过滤列表，报告其余错误）
  • 断点处的溢出是否「可接受」（始终报告，由用户决定）

References

参考资料

For detailed check specifications and Playwright tool usage:
  • Validation Checks: references/validation-checks.md -- severity rationale, edge cases, and extended check specifications
  • Playwright Tools: references/playwright-tools.md -- MCP tool signatures, usage patterns, and common pitfalls
有关详细的检查规范和Playwright工具使用方法:
  • 验证检查: references/validation-checks.md -- 严重程度依据、边缘情况和扩展检查规范
  • Playwright工具: references/playwright-tools.md -- MCP工具签名、使用模式和常见陷阱

Complementary Skills

互补技能

  • pre-publish-checker -- validates source markdown before upload (complementary, not overlapping)
  • wordpress-uploader -- uploads content to WordPress (upstream integration)
  • seo-optimizer -- validates SEO properties against source (data consumer of this skill's output)
  • endpoint-validator -- similar validation pattern for API endpoints
  • pre-publish-checker -- 上传前验证源markdown（互补，无重叠）
  • wordpress-uploader -- 向WordPress上传内容（上游集成）
  • seo-optimizer -- 针对源内容验证SEO属性（本技能输出的数据消费者）
  • endpoint-validator -- 针对API端点的类似验证模式

Shared Patterns

共享模式

  • Anti-Rationalization -- prevents shortcut rationalizations
  • Verification Checklist -- pre-completion checks
  • Anti-Rationalization -- 防止捷径式合理化
  • Verification Checklist -- 完成前检查