mock-hunter

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 enprojectnment, 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

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

Phase 2: Navigate & Catalog

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

Phase 3: Test Interactivity

1. For every tab: click only after the user has approved navigation-style interactions, then snapshot, scroll to bottom, re-catalog
2. 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