/wordpress-live-validation

name: wordpress-live-validation
description: "Validate published WordPress posts in browser via Playwright."
user-invocable: false
allowed-tools:
  - Read
  - Write
  - Bash
  - mcp__plugin_playwright_playwright__browser_navigate
  - mcp__plugin_playwright_playwright__browser_wait_for
  - mcp__plugin_playwright_playwright__browser_snapshot
  - mcp__plugin_playwright_playwright__browser_evaluate
  - mcp__plugin_playwright_playwright__browser_network_requests
  - mcp__plugin_playwright_playwright__browser_console_messages
  - mcp__plugin_playwright_playwright__browser_resize
  - mcp__plugin_playwright_playwright__browser_take_screenshot
  - mcp__chrome-devtools__navigate_page
  - mcp__chrome-devtools__take_screenshot
  - mcp__chrome-devtools__take_snapshot
  - mcp__chrome-devtools__list_console_messages
  - mcp__chrome-devtools__list_network_requests
  - mcp__chrome-devtools__lighthouse_audit
  - mcp__chrome-devtools__resize_page
routing:
  triggers:
    - validate wordpress post
    - check live post
    - verify published post
    - wordpress post looks right
    - check og tags live
    - responsive check wordpress
    - post rendering check
    - live site validation
  pairs_with:
    - publish
    - e2e-testing
  complexity: Medium
  category: content-publishing

WordPress Live Validation Skill

Overview

This skill loads a real WordPress post in a Playwright headless browser and verifies that what readers see matches what was uploaded. **The browser is the source of truth** -- REST API success does not guarantee correct rendering.

**Browser backend selection**: Playwright MCP (default) is used for automated validation and CI/CD. Use Chrome DevTools MCP when the user explicitly asks to "check in my browser" or "debug live", or when the task involves Lighthouse audits or performance profiling.

Reference Loading Table

| Signal | Load These Files | Why | |---|---|---| | check specifications: severities, edge cases, JS extraction | `validation-checks.md` | Loads detailed guidance from `validation-checks.md`. | | Playwright MCP tool signatures, pitfalls, availability detection | `playwright-tools.md` | Loads detailed guidance from `playwright-tools.md`. | | step-by-step NAVIGATE, VALIDATE, RESPONSIVE procedures | `phase-checks.md` | Loads detailed guidance from `phase-checks.md`. | | Phase 4 REPORT output format | `output-format.md` | Loads detailed guidance from `output-format.md`. | | post-upload validation walkthrough; wordpress-uploader integration | `examples.md` | Loads detailed guidance from `examples.md`. | | errors, error handling | `error-handling.md` | Loads detailed guidance from `error-handling.md`. |

Instructions

Constraints (Always Applied)

1. **Read-Only Observation Only**: Never click, type, fill forms, or modify anything on the WordPress site. This is observation-only validation—any write action risks mutating published content.

2. **Evidence-Based Reporting**: Every check result must reference a concrete artifact (DOM value, network response, screenshot path). "Looks fine" is not acceptable. Report what the browser shows, not assumptions.

3. **Non-Blocking Reports**: Failed validation produces a report but does not revert the upload or block the pipeline. The user decides how to act on findings.

4. **Severity Classification** (enforce strictly):

• **BLOCKER**: Readers see broken content (missing title, broken images, placeholder text, wrong H1)
• **WARNING**: Degraded quality but functional (missing OG tags, JS errors, responsive overflow)
• **INFO**: Informational only (rendered values without comparison baseline)
• Never inflate or deflate—alert fatigue and hidden problems are equal harms.

5. **Browser Availability**: Requires either Playwright MCP or Chrome DevTools MCP. If neither is available, exit in Phase 1 with a skip report. Do not retry.

6. **Default Behaviors** (ON):

• Run all check categories (content integrity, SEO/social, responsive)
• Test three breakpoints: mobile (375px), tablet (768px), desktop (1440px)
• Save screenshots at each breakpoint as evidence
• Exclude known benign console patterns: ad networks (doubleclick, googlesyndication), analytics (gtag, fbevents), consent managers (cookiebot, onetrust)
• Try content selectors in order: `article` → `.entry-content` → `.post-content` → `main`

7. **Optional Behaviors** (OFF unless enabled):

• Draft preview mode (requires authenticated WordPress session)
• Custom content selector override
• Strict mode (treat all WARNINGs as BLOCKERs)
• OG image fetch verification (navigates to og:image URL to check 200 response)

8. **Input Requirements**:

• WordPress post URL (from wordpress-uploader, direct user input, or `{WORDPRESS_SITE}/?p={post_id}&preview=true`)
• Optional: expected title (for title match comparison)
• Optional: expected H2 count (for structure comparison)
• Optional: custom content selector

---

Phase 1: NAVIGATE

**Goal**: Load the WordPress post and confirm the content area is present.

See `references/phase-checks.md` "Phase 1: NAVIGATE — Detailed Steps" for the 4-step procedure (verify browser MCP availability, navigate, wait for content area with selector chain, remove cookie/consent banners with the JS snippet).

**GATE**: Page loaded with HTTP 200 (or 30x redirect to 200), content selector found. If 4xx/5xx or no selector found: capture screenshot, report FAIL with HTTP status, STOP. Do not proceed to Phase 2.

---

Phase 2: VALIDATE

**Verification means execution, not reasoning.** Run the command. Do not reason about whether the command would pass. Do not summarize the expected output. Execute the check, paste the exit code, paste the relevant output. A verification phase that produces a verdict without an observed tool result is not a verification — it is a guess with a rigor aesthetic.

**Goal**: Inspect rendered DOM and network activity for content integrity and SEO completeness. Run all chec