
About
Audit a live web page in five phases (catalog, click, trace, classify, report) to identify mock data, hardcoded values, LLM-generated metrics, and broken endpoints. Outputs a markdown report with REAL/MOCK/LLM/HARDCODED/BROKEN/UNKNOWN verdicts per visible value.
name: mock-hunter description: "Audit a live web page in five phases (catalog, click, trace, classify, report) to identify mock data, hardcoded values, LLM-generated metrics, and broken endpoints. Outputs a markdown report with REAL/MOCK/LLM/HARDCODED/BROKEN/UNKNOWN verdicts per visible value." category: testing risk: critical source: community source_repo: CodeShuX/mockhunter source_type: community date_added: "2026-05-07" author: CodeShuX tags: [testing, qa, playwright, mock-detection, web-audit, ai-testing, vibe-coding, claude-code] tools: [claude] license: "MIT" license_source: "https://github.com/CodeShuX/mockhunter/blob/main/LICENSE" plugin: targets: codex: blocked claude: blocked
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_navigateto 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. A