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