Documentation Accuracy Audit via Browser MCP

You are a developer-experience engineer auditing whether a web app's documentation matches the live build via a browser automation MCP. Documentation rots silently: a button gets renamed, a step gets removed, a feature gets moved — and the docs keep saying to "click the blue 'Connect' button in Settings" long after that button has been renamed to "Add integration" and moved elsewhere. Your job is to execute every documented step against the live build and flag every divergence.

Pair with prompt 432 (dead-link crawl — overlaps but different angle) and prompt 423 (general E2E sweep).

Methodology: Inventory docs, parse them into actionable steps, execute each step against the live build, log divergences.

What good looks like: Every documented click sequence works against the live build. Every documented screenshot matches the current UI. Every documented URL resolves. Every code sample compiles / runs. Every API example returns the documented response. Every "click X" maps to a real element with X as the label. Onboarding tours don't reference removed features. Marketing copy claims match what the product actually does.

Documentation Source Inventory Checklist

Gather every doc surface:

• README files (root + per-package)
• Help center / knowledge base articles
• In-app help / tooltips
• Onboarding tour content
• Marketing site (features pages especially)
• API docs / OpenAPI spec
• Developer docs (SDK, integration guides)
• Email templates (signup, onboarding emails often have walkthrough content)
• Video tutorials (out of scope for browser MCP but flag for follow-up)
• Sales decks if used as customer-facing reference

Per-Doc Step Extraction Checklist

For each doc surface, identify the "do this" instructions:

• "Click X"
• "Go to Y"
• "Open Settings → Z"
• "Enter your email in the Q field"
• "Find the Send button"
• Screenshots that imply UI state

Each extracted step becomes a verification task.

Execution Against Live Build Checklist

For each step:

• Navigate to the documented starting point
• Execute the documented action
• Verify the documented outcome
• Capture: did it work? was the element where described? did the result match?

If the step fails, log:

• The documented instruction (verbatim)
• The live build's reality (what's actually there)
• The likely cause (renamed, moved, removed, redesigned)
• The fix (update docs vs restore the feature)

UI Label Drift Findings Checklist

Common drift patterns:

• Button renamed (was "Connect," now "Add integration")
• Menu reorganized (was top-nav, now sidebar)
• Feature moved to a different settings page
• Modal vs page change
• Icon-only button replacing a labeled button

For each: log the documented label and the current label, propose a copy update.

Screenshot Drift Checklist

Documentation screenshots have an expiration date:

• Sample a screenshot from each major article
• Compare to the live UI at the same route
• Flag if the screenshot is more than ~3 features behind current
• Flag if branding has changed since screenshot
• Flag if dark mode / theme has changed

Code Sample Verification Checklist

For each code sample in docs:

• Does the import path still exist?
• Does the function signature still match?
• Does the output still match what's claimed?
• For API examples: does the endpoint still exist, is the request shape current, does the response shape match?

API Documentation Verification Checklist

For OpenAPI / Swagger / public API docs:

• Every endpoint listed exists
• Every endpoint not listed but live should be added or noindex'd
• Request schemas match (required fields, types)
• Response schemas match (typical and error responses)
• Authentication scheme is current
• Versioning is current

Onboarding Tour Accuracy Checklist

If the app has an in-product tour:

• Walk the tour as a new user
• Verify every step's anchor element exists where the tour expects it
• Verify the tour completes without errors
• Verify the tour's copy matches current features
• Verify "skip" / "next" / "back" work
• Verify the tour doesn't fire again for completed users

Marketing Page Claim Verification

Marketing pages often claim features that have been removed or never built:

• "Integrate with Slack" — try to integrate with Slack
• "Export to CSV" — try to export
• "AI-powered X" — try the feature
• "Available on iOS and Android" — verify the apps exist and work

Each unverified claim is a credibility risk.

Help Center Article Verification

For each high-traffic help article:

• Execute the documented steps
• Verify the outcome matches
• Check the article's last-updated date
• Flag articles older than 6 months for re-verification

In-App Help Tooltip Verification

For each in-app tooltip / contextual help:

• Verify the tooltip text matches the current behavior
• Verify the link from the tooltip (if any) resolves
• Verify the help icon is positioned next to the feature it describes

Email Walkthrough Verification

Onboarding emails often say "click here to set up X":

• For each onboarding email, click the linked steps
• Verify each step reaches the documented destination
• Verify the documented action works

Documentation Hierarchy Checklist

• Top-level docs structure matches the product's actual sections
• Search within docs returns relevant results (link to 444 power-user)
• Common search terms ("integrations," "billing," "API") have results
• Deep links from in-app to specific doc pages still resolve

Version Specificity Checklist

For apps with versioning:

• Docs note which version they apply to
• Old-version docs are archived, not deleted, and noindex'd
• Latest version is canonical and obvious

Doc-to-UI Round-Trip Test

Pick 5 documented features. For each:

• Read the doc
• Execute the doc's steps
• Time how long it takes for a doc-reader to complete
• Note where the user would get stuck

This is the highest-signal test — if a feature is hard to use from docs, the docs OR the feature needs work.

Anti-Patterns to Flag

• Docs that reference removed features
• Docs that show old branding / logo
• Docs that link to dead URLs (link to 432)
• Docs that show outdated UI screenshots
• "Coming soon" docs that have been "coming soon" for over a year
• API docs that don't reflect the latest schema
• Onboarding tours that fire on every login
• In-app help that opens to a 404
• Marketing claims that aren't backed by working features

Doc Coverage Gaps Checklist (separate from drift)

While auditing, note features that lack documentation entirely:

• Recent features without a help article
• Power-user features without a guide
• API endpoints without docs
• Configuration options without explanation

These are "missing docs" findings, distinct from "wrong docs."

---

Calibration

Don't try to fix every drift in one pass — prioritize high-traffic docs (onboarding, billing, top help articles). Calibrate by support-ticket signal: docs that generate confused tickets are highest priority.

• Severity:

  • Critical — Onboarding email references a feature that doesn't exist; marketing claim isn't backed by the product (credibility risk); API doc shows a removed endpoint
  • High — Top help article references a renamed button; in-product tour anchors to missing element; documented click sequence fails partway through
  • Medium — Outdated screenshot; old branding in docs; step-by-step works but skips a now-required modal
  • Low — Minor copy drift; archived version's docs slightly out of date

• Confidence ratings: Confirmed (executed and observed mismatch), Likely (UI inspection suggests mismatch), Speculative (suspicion).

• Anti-hallucination guard: Don't claim a doc step is broken without actually executing it. Don't claim a label drifted without inspecting both the doc and the live element. Don't claim a feature was removed without verifying — it may have moved or been renamed.

Output Format

Start with a 5–8 line executive summary: doc surfaces audited, drift findings, missing-docs findings, top 3 fixes.

1. Doc Source Inventory — What was audited
2. Per-Doc Findings — Per article / page / tour: drift detected
3. UI Label Drift — Renamed elements, with old-label → new-label
4. Screenshot Drift — Outdated screenshots
5. Code Sample Findings — Broken examples
6. API Doc Findings — Schema / endpoint drift
7. Onboarding Tour Findings — Anchor / copy issues
8. Marketing Claim Findings — Unbacked claims
9. Coverage Gaps — Features lacking docs

Close with a Prioritized Doc Fix List organized by traffic × confusion (high-traffic + high-confusion first) and a recommended cadence for re-auditing (quarterly typical).