MockHunter — Live Page Reality Check

Overview

MockHunter is a Claude Code skill that audits a live web page and tells you, for every visible value, whether it is real, mocked, LLM-generated, hardcoded, broken, or unknown. It is built for vibe-coded apps (Lovable, Bolt, v0, Replit, AI Studio, Cursor Composer) where the UI may look complete but the data layer often is not. It uses Playwright MCP to drive a real browser, then traces each visible value through the network and DOM to its source.

This skill adapts the upstream CodeShuX/mockhunter project (community source).

Because this workflow drives a real browser against live pages, treat it as an interactive audit tool, not a plugin-safe read-only helper. Default to observation-only until the user confirms the target is theirs, identifies a safe test account or environment, and explicitly approves any click, submit, or authenticated action that can mutate state.

When to Use This Skill

Use when auditing an AI-generated UI to find out which values are actually wired up
Use when reviewing a contractor or teammate's deliverable before sign-off
Use before showing a vibe-coded MVP to a customer or investor
Use when a dashboard "looks too clean" — every metric uniformly round, all timestamps clustered, no variance — and you suspect seeded data

How It Works

Phase 1: Setup & Smart Questions

Greet the user, ask for the target URL
Auto-detect the stack from the URL (*.lovable.app, *.bolt.new, *.v0.app, *.replit.app, aistudio.google.com, otherwise Custom)
Ask 3-5 targeted questions: auth mode (public / localhost / form / skip), DB access (optional), suspicions, page goal
Confirm the audit plan, ownership/permission, target environment, and allowed action classes before proceeding

Phase 2: Navigate & Catalog

browser_navigate to the target URL
Handle auth per chosen mode (form-login: fill fields, click submit)
Wait for network idle (max 10s)
Take full-page screenshot, capture accessibility snapshot
Inventory every: heading, button, link, input, card, badge, stat, table cell, empty state, image
Capture initial console errors and network requests

Phase 3: Test Interactivity

For every tab: click only after the user has approved navigation-style interactions, then snapshot, scroll to bottom, re-catalog
For every button: click only user-approved, allowlisted controls that are clearly non-destructive by role, accessible name, nearby text, icon, URL/action target, and expected network side effect; skip destructive or ambiguous controls rather than relying on a label regex alone
For every form: identify required fields and prefer empty-submit validation; submit throwaway data only when the user explicitly approved the exact form, target environment, and test account
Record per-element behavior

Phase 4: Trace Provenance

For every visible value, run this decision tree:

Did any network request return this value?
├── YES — found in a response:
│   ├── Status 4xx/5xx → BROKEN
│   ├── Endpoint matches /ai|openai|generate|llm|chat → LLM
│   ├── Response shape matches mock library (faker, MSW, mockoon) → MOCK
│   ├── Uniformity flags trigger → MOCK or LLM (review)
│   ├── DB connection provided?
│   │   ├── Run read-only SELECT, value matches DB row → REAL
│   │   └── Value not in DB → MOCK
│   └── No DB → UNKNOWN (best-guess)
└── NO — value not in any network response:
    ├── String literal in DOM source → HARDCODED
    ├── Computed from Math.random / Date.now / faker → MOCK
    └── Cannot determine → UNKNOWN

Uniformity heuristics flag suspicious data:

All numeric values identical across rows
All percentages round (50%, 75%, 90%)
All timestamps cluster within a single minute
< 3 unique values across 10+ rows

Phase 5: Report

Generate mockhunter-report.md with:

Summary table (verdict counts)
Findings per section/tab (element / value / verdict / source / severity / action)
Console errors and network failures
NO-OP buttons
Suspicious patterns
Smart follow-up questions for the user

Examples

Example 1: Auditing a Lovable admin dashboard

User: /mockhunter audit https://my-app.lovable.app/admin
Skill: [Phase 1] Stack detected: Lovable. Auth: skip. DB: no.
       [Phase 2] Catalog: 6 stat cards, 4 verification queues, 8 activity items.
       [Phase 3] Search box: NO-OP (zero network requests). Activity link → 404.
       [Phase 4] Bundle 2.7 MB. Zero /api/, zero supabase, zero axios.
                 "$42,850" → string literal in JSX → HARDCODED.
                 "+12% vs last month" → string literal → HARDCODED.
       [Phase 5] Verdict: 23 HARDCODED, 1 BROKEN, 1 NO-OP, 0 REAL.
                 Report written to ./mockhunter-report.md

Example 2: Public marketing site (mostly real)

User: /mockhunter audit https://example-saas.com
Skill: ...
       [Phase 5] Verdict: 8 REAL, 18 HARDCODED (intentional marketing copy),
                 0 MOCK, 0 BROKEN, 2 UNKNOWN.
                 No console errors, no broken endpoints.

Best Practices

✅ Provide DB access when available — lifts UNKNOWN verdicts to REAL or MOCK
✅ Use a dedicated test account for form-login auth
✅ Run cold-start tests (zero data) — many vibe-coded apps fail there
✅ Tell the skill if specific sections are intentionally AI-generated, so it doesn't false-flag them
❌ Don't run active interaction on apps you don't own without permission — live clicks and form submissions can mutate state
❌ Don't trust a destructive-button exclusion list by itself — localized labels, icons, aria text, and backend routes can hide mutating actions
❌ Don't trust the audit if the page failed to load — check console first

Limitations

Single-page audit per run — no multi-page crawl in v0.1.0
Form-login only for auth — no OAuth, magic-link, or 2FA in v0.1.0
Caps at ~30 most-prominent buttons per page
Markdown report only — no JSON output yet
DB verification supports any DB reachable via shell command (psql, mysql, mongosh, wrangler, supabase REST), but not Firestore directly

Security & Safety Notes

The skill runs read-only DB SELECTs only, never INSERT/UPDATE/DELETE
Skips destructive-looking, ambiguous, icon-only, localized, or external-write controls unless the user has explicitly allowlisted the exact control and environment
Never submits forms that look like payment, account deletion, external write operations, account changes, invites, publishing, deployment, messaging, or money movement
Uses placeholder credentials ([email protected]) for any throwaway form tests, never the user's real credentials
All Playwright actions happen in a controlled MCP browser context — no headless escalation

Mock Hunter