Skip to content
Skillpedia
Analysis & spreadsheets48k · #4670

mock-hunter

Lets your agent audit web pages to find fake or broken data. It helps ensure the quality and reliability of information.

What it does

This tool checks a live website to find out if the data you see is real, mocked, AI-generated, hardcoded, or broken. It generates a report to help you understand the source of each piece of information.

When to use it

  • ✓When auditing an AI-generated UI to see if data is actually connected.
  • ✓Before signing off on someone else's work.
  • ✓Before showing a prototype to clients or investors.

Example of what to ask your AI

“Audit the website https://mysite.com and tell me where the data comes from.”

Want more? Open the sections below.

How to use

The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.

Skill link

https://github.com/sickn33/agentic-awesome-skills/blob/main/skills/mock-hunter/SKILL.md

Ready-to-paste message

Use this skill to help me: https://github.com/sickn33/agentic-awesome-skills/blob/main/skills/mock-hunter/SKILL.md Read the SKILL.md file at that link and follow its instructions for my task.
How it works

The tool navigates the website like a user, clicking buttons and filling forms (with your permission). It then analyzes the displayed information to determine its origin.

Installation

Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.

In the terminal (Claude Code, Codex, Cursor), in your project folder:

npx skills add sickn33/agentic-awesome-skills --skill mock-hunter

Or download just the file:

curl -L https://raw.githubusercontent.com/sickn33/agentic-awesome-skills/main/skills/mock-hunter/SKILL.md -o SKILL.md
Technical content (original SKILL.md)

Original text by the author, straight from GitHub.

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

  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 environment, 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
  3. 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
  4. 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.

…
FAQ

What does 'mock data' mean?

It's fake data used for testing or to simulate real information when the actual data isn't available yet.

What are 'hardcoded values'?

These are texts or numbers that were written directly into the website's code, instead of being fetched from a database or another source.

Can I use this on any website?

Yes, but be careful when interacting with sites you don't own. The tool might click buttons or fill forms, which could change information on the site.

Details

Original description by the author

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.

repo: sickn33/agentic-awesome-skills

Popularity

GitHub stars
48k
Ranking position
#4670
License
MIT
Updated
10/15/2026

Is this skill useful?

0

Sign in to vote.

Comments

  • …

More skills from this repository

Similar skills