06-core-prototype-ui-live-in-the-real-site-with-mock-datalisted

CORE — never delete. HARD MANDATE: this is THE default way to prototype/mock/show ANY UI or UX idea. Trigger the moment a task is 'mock this up', 'show me how X would look', 'design a screen', 'what if the layout was…', 'make me a bento', or any look-and-feel iteration. NEVER build a throwaway HTML file, a separate standalone app, or reach for v0/Lovable/bolt/Figma — those lose fidelity and get thrown away. Instead scaffold the screen INSIDE the real running app using its existing shared components + theme tokens, feed it MOCK DATA behind a flag so it renders instantly with no DB/auth, run it locally, and show the user via the chrome-devtools MCP (Chrome) so they can iterate by voice ('smaller', 'move that', 'make it a bento') against the actual site. The prototype IS the product — zero translation step at the end.
markkennethbadilla/public-agent-provisioning · ★ 0 · AI & Automation · score 72

Install: claude install-skill markkennethbadilla/public-agent-provisioning

# Prototype UI Live, In The Real Site, With Mock Data (CORE) **Why (the user's reasoning, 2026-06-24):** A mockup is only useful if it shows how a change *actually looks in the real site* — same theme, same components, same spacing, same screen. Recreating the site in throwaway HTML or a standalone AI builder (v0/Lovable/bolt) never reflects the true look, so you can't tell if a change fits, and you throw the result away and rebuild it for real anyway. Editing the REAL running site with MOCK data collapses that: the prototype and the product are the same object. The user iterates by voice ("make that smaller, move it here, make a bento") and sees it become real in the actual site. The only cost is a compile/reload per tweak — paid back 10x because there is NO handoff/rebuild at the end; once the user likes it, it's already ~90% shippable code. **This is a WORKFLOW, not a library.** Do NOT install or reach for an external prototyping tool. Confirmed superior to v0/Lovable/bolt/Figma for this use case because those generate a fresh generic-looking app you must re-implement in the real site — the exact "recreate the site first" trap this avoids. ## The mandate (default for EVERY mockup/UX request) 1. **Scaffold INSIDE the real app.** A real route/page in the actual repo, built from the existing shared components + theme tokens (rule 5d/5m — never raw hex, never a separate HTML file, never a standalone app). Reuse the patterns already in the codebase (lo