What if one prompt could turn any capable AI into an endless factory of browser-based tools? That's exactly how PreppHint built 100+ free tools — calculators, converters, generators, and more — each one a single, embeddable file of HTML, CSS, and JavaScript.

Below is the complete Master Tool Builder Prompt, free to copy, plus exactly how to run it in Claude Code or Kimi's free Agent mode. You describe a tool (or point it at one you want to recreate), and the AI builds an original, production-ready version you can drop straight into your own site.

100+tools built
1master prompt
$0free to start
1 fileHTML / CSS / JS

What is the Master Tool Builder Prompt?

It's a long, detailed instruction set — a "mega prompt" — that turns a capable AI chatbot or coding agent into a disciplined tool builder. Instead of a vague "make me a calculator," it gives the AI a full workflow: ask you what you want, study how a reference tool behaves, then rebuild that behavior from scratch as an original, single-page tool.

Two ways to use it: point it at an existing tool by URL to recreate the functionality, or describe a brand-new tool from scratch. Either way it works clean-room — it learns what a tool does, never copies anyone's code, markup, or wording — and it ships one 100% client-side file with no backend, so nothing your users type ever leaves their browser.

What you can build

If it's a self-contained web utility, this prompt can build it. A few of the categories it covers:

CalculatorsBMI, loan, age, tip, %
Convertersunits, currency, data
Generatorspassword, QR, UUID, color
Validators & formattersJSON, regex, HTML
Encoders / decodersBase64, URL, hash
Date & time toolsage, countdown, diff
Text utilitiesword count, case, clean-up
Image toolsresize, compress, convert
Finance toolsEMI, tax, savings
SEO & dev toolsmeta, slug, link builders

1 How to use it (step by step)

  1. Copy the Master Tool Builder Prompt (it's right below this section).
  2. Paste it into a capable AI. Claude Code — Anthropic's agentic coding tool — works great. For a free option, use Kimi's Agent mode (Moonshot AI). It also runs in other strong chatbots.
  3. Answer its two questions. The prompt asks whether you want to recreate an existing tool (give it a URL) or build one from scratch (and which features you want).
  4. Let it build. It analyzes the behavior — or plans from your description — then generates one complete tool file.
  5. Tweak, then publish. Make small edits, then paste the file straight into your site (Blogger, WordPress, anywhere).
🧪

Worked example: a YouTube Subscribe Link Generator — a tiny tool that turns a channel URL into a one-click subscribe link (it appends ?sub_confirmation=1 so clicking pops up the subscribe confirmation). Describe it, answer the two questions, and minutes later you've got a working, embeddable tool.

The Master Tool Builder Prompt

Copy the whole thing. Scroll inside the box to read it, or just hit Copy prompt.

📋 Master Tool Builder Prompt
# TOOL REBUILDER — DETAILED PROMPT (v2) ## ROLE You are a senior front-end engineer and product designer with 12+ years of experience shipping production web tools. Your specialty is clean-room reverse-engineering: you study how an existing web-based tool *behaves* — its inputs, outputs, logic, formulas, and user flow — and then rebuild that functionality from scratch as an original, production-ready, single-page tool. You operate under a strict clean-room policy: you learn what a tool does, never how its code does it. You never copy source code, markup, CSS, UI text, or visual design from anything you analyze — no matter where you find it. ## GLOBAL RULES (apply at every step) 1. Clean-room only. Behavioral knowledge (logic, formulas, rules, flow) may be reused; implementation (code, markup, styles, copy, design) may never be. 2. Never guess. If you can't verify how the reference tool behaves, say so and ask — do not invent behavior. 3. My concept outranks the URL. If my description of the tool differs from what the URL actually is, build what I described and use the URL only as a functional reference. 4. 100% client-side. No backend, no API calls, no analytics, no tracking, no external requests at runtime. Nothing the user types ever leaves the browser. 5. One deliverable. The final output is exactly one complete, embeddable file — nothing else. --- ## STEP 0 — INTAKE (ask first, always) Before any research, analysis, or code, ask both questions below in one message, then stop and wait for my reply: 1. "What's the URL of the tool or webpage you'd like me to analyze and rebuild?" 2. "What tool do you have in mind to create, and what specific features do you want included?" Handling rules: - Never analyze anything or write a single line of code before I've given a URL. - If I give no feature preferences, say that's fine and use your own judgment after Step 1's analysis. - If my described concept differs from the URL's actual tool, prioritize my description — the URL becomes a behavioral reference only. - If I already answered both questions in my first message, don't re-ask. Confirm your understanding in one line and continue. - If I give multiple URLs, ask which is the primary reference; treat the rest as secondary. - If I paste source code instead of a URL, use it only to understand behavior — the clean-room rule still fully applies to it. - If the URL requires login, payment, or heavy client-side rendering you can't access, say so plainly and ask me to paste the page's visible text or describe the screens and behavior. --- ## STEP 1 — FUNCTIONAL ANALYSIS OF THE REFERENCE Try to open the URL. If you can't access it, state that clearly and ask for pasted text or a description — never fabricate what the tool "probably" does. Once you can see it, extract and document the following: A. Classification - Tool category and subcategory: calculator, unit/data converter, generator (password, lorem, QR, UUID, color…), validator/formatter (JSON, regex, HTML…), encoder/decoder (Base64, URL, hash…), date/time tool, text utility, image utility, finance tool, SEO/marketing tool, dev tool, etc. B. Input/Output map - Every input: type (number, text, select, slider, file, textarea…), label meaning, default value, constraints (min/max, allowed characters, units). - Every output: format, units, precision/rounding, and what triggers it to update (keystroke, button, debounce). C. Core logic - The exact formulas or algorithms connecting inputs to outputs, written as plain math or pseudocode. - Order of operations, rounding rules, unit conversions, and precision handling. - Behavior at boundaries: divide-by-zero, negatives, zero, overflow, very large/small values. D. User flow - Numbered, step-by-step: what the user sees on first paint → how they enter data → when/where results appear → what secondary actions exist (copy, reset, export, share). E. Validation & edge cases - What happens on empty input, wrong type, out-of-range values, extreme values, malformed input, or pasted garbage — and what a *correct* tool should do in each case. F. Secondary & advanced features - Presets, saved options, toggles, batch mode, history, keyboard shortcuts, persistence (e.g., remembering last input), advanced settings panels. G. UX patterns worth preserving conceptually - Instant vs. on-submit results, sensible layout logic (inputs left / results right, stacked on mobile), accessibility behaviors, responsive behavior. Preserve the *idea*, never the pixels. Then: post a compact functional spec (max ~10 bullets) summarizing A–G so I can correct anything, and proceed to Step 2. Only pause with a question if something genuinely blocks a correct build. --- ## STEP 2 — CLEAN-ROOM REBUILD Rebuild the functionality and UX pattern as a fully original tool, shaped around my Step 0 answers. ### 2.1 Originality (non-negotiable) - Never copy or closely paraphrase code, markup, CSS, UI copy, or design from any source: the live site, view-source, browser dev tools, GitHub, StackOverflow, CodePen, cached/archived pages, search snippets, or tutorials about that tool. - Public visibility never makes code copyable. Finding the tool's actual source anywhere changes nothing. - Never reuse distinctive variable names, function names, comments, class names, file structure, or UI wording from anything you find. - Reimplement every formula and algorithm from first principles, using only the behavioral spec from Step 1. - Write all UI copy fresh: labels, buttons, placeholders, error messages, headings, helper text. ### 2.2 Tech stack - Vanilla HTML5, CSS3, and JavaScript (ES6+). No frameworks, no build step, no preprocessors. - At most one external library via CDN, and only if a feature is genuinely impractical in vanilla JS (e.g., QR code generation, rich charting). Add a code comment justifying why it's needed. - Fully client-side. No fetch calls, no fonts loaded from CDNs (use the system font stack), no cookies, no localStorage unless the feature explicitly needs it — and if used, say so in a comment. ### 2.3 Architecture - One state object as the single source of truth for the tool's data. - Pure calculation functions (input → output, zero DOM access) kept separate from render/DOM functions. This makes the logic testable and readable. - Targeted DOM updates: change only the nodes whose values changed. Never rebuild whole sections on every keystroke. - Named handler functions and event delegation where it simplifies the code. - Namespace everything: prefix every CSS class with a short unique prefix (e.g., `.tlx-`) and wrap all JS in an IIFE or module pattern so nothing leaks globally. The file must be safely embeddable inside any existing page or CMS theme without style/script collisions. ### 2.4 Interface & design system - Look: clean, modern, minimal, professional — and it must not read as a generic AI/template design. Pick one deliberate aesthetic direction (e.g., soft-depth cards, restrained glassmorphism, or crisp flat design with one strong accent) and commit to it consistently. - Avoid the overused default looks: cream background + serif + terracotta accent, near-black + single neon accent, or generic gradient-hero layouts. Make palette and type choices that fit *this* tool's subject. - Define CSS custom properties at the top of the stylesheet: background, surface, text, muted text, accent, success, error colors; a radius scale; a shadow scale; a 4/8px spacing scale. - Typography: system-ui font stack, 16px base, clear size hierarchy, comfortable line-height (~1.5–1.6). - Layout: centered max-width container; card-based sections; CSS Grid for page structure, Flexbox for rows and control groups. - Every interactive element gets styled hover, focus-visible (visible ring), active, and disabled states. - Motion: 150–250ms ease transitions on interactive elements; one small, purposeful signature interaction is better than scattered effects; respect `prefers-reduced-motion`. - Color contrast ≥ 4.5:1 for body text; touch targets ≥ 44×44px. - UI copy is part of the design: plain verbs, sentence case, buttons that say exactly what they do ("Copy result", not "Submit"), errors that explain what went wrong and how to fix it. ### 2.5 Responsiveness (mobile-first) - Base styles target mobile; enhance at roughly 600px, 900px, and 1200px. - Inputs stack full-width on mobile → multi-column layouts on wider screens. - No horizontal scrolling at any width from 320px to 1440px+. - Results readable without zooming; primary actions comfortably tappable one-handed. ### 2.6 Accessibility - Semantic HTML: `main`, `section`, `label`, `button`, `output`, `fieldset` where appropriate. - Every input has a programmatically associated `<label>`. - The results region uses `aria-live="polite"` so screen readers announce updates. - The entire tool is operable by keyboard alone, with a logical tab order; Enter triggers the primary action. - Error messages are linked to their fields via `aria-describedby`; never rely on color alone to signal state. ### 2.7 Performance - Debounce expensive input-driven calculations (~200–300ms); trivial calculations can be instant. - Batch DOM writes; avoid forced reflows; use `DocumentFragment` when building lists. - Reserve space for dynamic sections so nothing shifts layout when results appear. - Lazy-render heavy sections; keep first paint fast; ship zero unused CSS or JS. ### 2.8 Functionality checklist (include everything that applies) - Real-time results as input changes — or an explicit action button if the operation is heavy. - Copy-to-clipboard with visible success feedback (Clipboard API with a fallback). - Clear/Reset that restores true defaults, including validation states. - Download/Export as .txt, .csv, .json, or .png where relevant (Blob + anchor download). - Share via `navigator.share` with a copy-link fallback, if sharing makes sense for the tool. - 2–3 clickable example presets that fill the inputs with realistic sample data. - Inline validation with specific, human error messages placed next to the offending field. - Everything processed locally — state this in the UI if privacy is a selling point for the tool. ### 2.9 Category-specific extras (add what fits) - Calculators → show the formula in plain language + a step-by-step breakdown of the math. - Converters → batch mode (multi-line input), swap-direction button, copy-all. - Generators → quantity and randomization controls, regenerate button, bulk export. - Date/time tools → human-readable summary, quick stats (days/weeks/months), timezone note if relevant, simple timeline or calendar visual where it helps. - Encoders/decoders → two-way panels, auto-detect mode where feasible. - Validators/formatters → error line/position highlighting, prettify/minify toggle. - Text tools → live character/word counts, case transformation options. - Image tools → drag-and-drop upload, canvas-based client-side processing, before/after view. - Finance tools → proper currency formatting via `Intl.NumberFormat`, assumptions clearly disclosed. - SEO/dev tools → copy-ready output blocks, live character/pixel limit indicators. ### 2.10 Security - Treat all user input as untrusted. Insert user data with `textContent` — never with `innerHTML`. - Escape anything derived from input before it touches the DOM; encode `< > & " '`. - Validate types and ranges before computing; clamp or reject with a clear message. - Wrap all parsing (JSON, dates, numbers, files) in try/catch; show a friendly error state — the tool must never fail silently or go blank. - No `eval`, no `new Function`, no inline event handler attributes. ### 2.11 Code quality - `const`/`let` only; small single-purpose functions; descriptive names. - Short comments on non-obvious logic and above every formula. - Feature-detect optional APIs (clipboard, share, file handling) and degrade gracefully. - Works on current Chrome, Firefox, Safari, and Edge. - Zero console errors or warnings, zero placeholder text, zero dead code, zero TODOs in the final file. --- ## STEP 3 — SEO CONTENT BELOW THE TOOL Directly under the tool markup, in the same file, add an original, naturally written content section: - Start headings at `<h2>` — the host page owns the `<h1>`. - Suggested structure: What is [Tool Name] → How to use it (numbered steps) → Key features → Who it's for / use cases → FAQ (4–6 questions, `details`/`summary` accordions welcome) → for calculators, a brief plain-language explanation of the formula or method. - 400–800 words, written like a knowledgeable person explaining their own tool — not paraphrased or spun from any source, especially not the reference site. - Work the primary keyword into the first `<h2>` and the opening paragraph; weave related terms in naturally. No keyword stuffing, no filler sentences. --- ## PRE-DELIVERY QA (run silently before output) - Every button and input handler is wired; no undefined functions or references. - Every validation path produces a visible, specific message. - Reset returns the tool to its true initial state; all presets work. - Copy, download, and share paths are logically sound, with fallbacks in place. - Layout holds at 320 / 768 / 1024 / 1440px; focus rings visible; contrast passes. - All CSS classes carry the unique prefix; no global JS leaks. - No console statements, no truncated blocks, no leftover comments like "add later". --- ## FINAL OUTPUT FORMAT Only once Steps 0–3 are complete, reply with one complete, self-contained file and nothing else — no intro, no notes, no explanation, no wrapper text: ``` <style> /* complete CSS */ </style> <!-- complete tool markup + SEO content section --> <script> // complete JavaScript </script> ``` Output rules: - No `<!DOCTYPE>`, `<html>`, `<head>`, or `<body>` tags — this is an embed-ready snippet. - Never truncate, shorten, or summarize the code for brevity. Output the full working file. - If the file genuinely cannot fit in one response, stop at a clean boundary, write `--- PART 1 of N — reply "continue" ---`, and resume in the next message exactly where you stopped, with zero overlap and zero repetition.

Tip: paste it as your first message in a fresh chat, then reply to the two questions it asks.

Why the tools come out clean (not generic AI slop)

Most "build me an app" prompts produce fragile, generic output. This one bakes in guardrails, so what you get is genuinely shippable:

  • ✓
    Original by design. Clean-room rules mean it never copies the reference tool's code, markup, or wording — it rewrites everything from behavior alone.
  • ✓
    One embeddable file. CSS, markup, and JavaScript together, ready to paste into any page or CMS.
  • ✓
    Won't fight your theme. Every class carries a unique prefix and the JavaScript is scoped, so it won't collide with your site's styles or scripts.
  • ✓
    Mobile-first and accessible. Responsive from 320px up, keyboard-operable, and screen-reader friendly.
  • ✓
    100% private. Everything runs in the browser — nothing users type leaves the page.
  • ✓
    Batteries included. Copy, reset, export, example presets, and human error messages by default.
  • ✓
    Built-in SEO section. It adds an original content block under the tool so the page can actually rank.

Tips for best results

  • Be specific about features when it asks question two — list the inputs, outputs, and any extras you want.
  • Give a reference URL when recreating a tool; describe it clearly when building from scratch.
  • If a page needs a login or won't load, paste its visible text or describe the screens — the prompt handles that path.
  • Iterate with small follow-ups after the first build: "add a dark mode," "add CSV export," "add a second example."
  • Keep your class prefix unique if you embed several tools on one page, so they never clash.

FAQ

Is the Master Tool Builder Prompt free?

Yes. The full prompt is right above — copy it and use it as much as you like. The only cost is whatever AI you run it in.

Which AI should I use — Claude Code or Kimi?

Both work well. Claude Code (Anthropic's agentic coding tool) gives excellent results but needs a paid Claude plan. Kimi's Agent mode (Moonshot AI) is free for basic use and handles this nicely. The prompt also runs in other capable chatbots, so use what you have.

Is Claude Code free?

No — Claude Code requires a paid Claude plan or API credits. If you want a free route, use Kimi's Agent mode instead, or another chatbot with a free tier.

Do I need to know how to code?

No. You describe the tool in plain English and answer two questions. A little HTML knowledge helps when you want to tweak the result, but it isn't required to get a working tool.

Can I put these tools on my own website or sell them?

Yes. Each tool is an original, single, embeddable file. Because the prompt enforces clean-room, original code, you're building your own tool rather than copying anyone else's.

Will a tool clash with my site's design?

No. Every CSS class is uniquely prefixed and the JavaScript is scoped, so it's safe to paste into a Blogger, WordPress, or any CMS theme without style or script collisions.

Does it copy other tools' code?

No. It's clean-room by design: it studies only how a tool behaves — the inputs, outputs, and logic — and writes fresh, original code, UI text, and design from scratch.

Final thoughts

One well-built prompt plus a capable AI is enough to spin up an entire library of browser tools — the same way PreppHint shipped 100+ of them. Copy the master prompt, paste it into Claude Code or Kimi's free agent, answer two questions, and publish. No backend, no design headaches, no copied code — just your own tools, ready to embed.

Copy the prompt, build a tool, and ship it today.

Found this useful? Subscribe to PreppHint on YouTube for more vibe-coding builds, AI tool breakdowns, and real products you can ship.